On Wed, Mar 7, 2012 at 9:45 PM, Michael Dürig wrote:
Regarding equals in the abstract base classes: I'd make the equals methods
in the abstract base classes final.
No, the current non-final implementation is by design.
See the followup patch I attached to OAK-3 for what I'm aiming at
here.
On 03/07/2012 10:55 PM, Jukka Zitting wrote:
Hi,
On Wed, Mar 7, 2012 at 10:47 PM, Ate Douma wrote:
Right now discussions and replies on oak specific issues and commit messages
still end up on the main dev@ so IMO not serving the intent.
Correct. I switched the OAK notifications to go to oak-
Runnable jar packaging
--
Key: OAK-4
URL: https://issues.apache.org/jira/browse/OAK-4
Project: Jackrabbit Oak
Issue Type: New Feature
Reporter: Jukka Zitting
Fix For: 0.1
We should have a simple
Hi,
On Wed, Mar 7, 2012 at 10:47 PM, Ate Douma wrote:
> Right now discussions and replies on oak specific issues and commit messages
> still end up on the main dev@ so IMO not serving the intent.
Correct. I switched the OAK notifications to go to oak-dev@ just now
(didn't want to do so earlier t
On 03/07/2012 09:25 AM, Jukka Zitting wrote:
Hi,
On Tue, Mar 6, 2012 at 1:00 PM, Jukka Zitting wrote:
The oak-dev@ mailing list should follow up shortly, see INFRA-4514 [1].
The list is ready now, you can subscribe by sending a message to
oak-dev-subscr...@jackrabbit.apache.org. I suggest we
Hi,
On Wed, Mar 7, 2012 at 9:45 PM, Michael Dürig wrote:
> Regarding equals in the abstract base classes: I'd make the equals methods
> in the abstract base classes final.
No, the current non-final implementation is by design.
See the followup patch I attached to OAK-3 for what I'm aiming at
he
Hi,
Regarding equals in the abstract base classes: I'd make the equals
methods in the abstract base classes final. Overriding them in a
concrete subclass will most likely break symmetry. Furthermore, since
these classes are immutable, the result of equals can be cached safely.
Michael
On 7
Hi,
Regarding equals in the abstract base classes: I'd make the equals
methods in the abstract base classes final. Overriding them in a
concrete subclass will most likely break symmetry. Furthermore, since
these classes are immutable, the result of equals can be cached safely.
Michael
On 7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
while implementing the jackalope php jsop client for the jackrabbit
backend, i stumbled over a problem with the json returned when a
property and a child node have the same name:
the repository is something like this:
to create it, i do
[
https://issues.apache.org/jira/browse/OAK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-3:
Attachment: OAK-3.2.patch
Attached a new patch that implements diffing and related operations
(CommitBuilder, e
Set omit term freq positions flag on parent field in the index
--
Key: JCR-3253
URL: https://issues.apache.org/jira/browse/JCR-3253
Project: Jackrabbit Content Repository
Issue Type
hallo chregu
ok. looking forward to your comments.
angela
ps: 'simple webdav' is not referring to version 1 of the jcr-remoting
that purely relied on (extended) webdav functionality but to a
regular file-folder-based webdav view to a JCR repository...
yet something completely differe
[
https://issues.apache.org/jira/browse/JCR-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224262#comment-13224262
]
David Buchmann commented on JCR-1616:
-
additionally, the json returned for a node that h
Hi
Thanks. I will read the JCR specs again about that part, but your
explanations helped a lot already. I think we might find a way for our
needs with this
greetings
chregu
On 07.03.12 13:05, Angela Schreiber wrote:
> hi chregu
>
> if you mean 'a bunch of transient modifications' when speaking
[
https://issues.apache.org/jira/browse/JCR-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224222#comment-13224222
]
angela commented on JCR-3249:
-
i don't think this is intentional but it would definitely be
hi chregu
if you mean 'a bunch of transient modifications' when speaking
about transactions that everything works as expected:
you have 2 possibilities to transport a set of transient JCR
modifications to the server:
a) LOCK (special lockscope)
your requests that reflect your transient modif
Hi angela
If I understand you correctly, we should implement transactions on the
client side and only send the jsop diff, when we actually commit the
transaction? We send it now on each save(), but that may be wrong then.
Could be a solution for our problem :)
I guess all the operations which are
[
https://issues.apache.org/jira/browse/JCR-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-1616:
Affects Version/s: 2.0
2.1
2.2
2.3
Hi Angela
Thanks a lot for the answer. I will make a jira issue about it. It's not
a critical thing for us right now, we can circumvent it (and we don't
work with same-name-siblings anyway, the problem is just when we want to
delete accidental same name siblings to have a clean repo)
Greetings
c
[
https://issues.apache.org/jira/browse/JCR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-3251.
-
Resolution: Duplicate
duplicate of JCR-1616
> NullPointerException on property with same name as n
hi chregu
the transaction type you are referring to aren't transactions s.str. but
were the first version of my jcr-remoting to indentify a set of
transient modifications that are transported to the server and are
'saved' at the end (or reverted with Session.refresh(false)).
at that time we tho
hi chregu
the problem is multifolded having one part in jackrabbit-core
and a second one in the way sms are reflected over the SPI.
as a general summary i would say that having volatile index
both in jcr2spi and jackrabbit-core is pretty troublesome.
without having a close look at it, i would su
[
https://issues.apache.org/jira/browse/OAK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224207#comment-13224207
]
Jukka Zitting commented on OAK-3:
-
Patch applied in revision 1297932. Renamed the package to .o
[
https://issues.apache.org/jira/browse/OAK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224109#comment-13224109
]
Stefan Guggisberg commented on OAK-3:
-
+1 for the patch, i agree that .oak.model would be b
Hi,
On Tue, Mar 6, 2012 at 1:00 PM, Jukka Zitting wrote:
> The oak-dev@ mailing list should follow up shortly, see INFRA-4514 [1].
The list is ready now, you can subscribe by sending a message to
oak-dev-subscr...@jackrabbit.apache.org. I suggest we move discussion
about Oak to the new list grad
25 matches
Mail list logo
