Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

I think the idea of adding getChildInfos to NodeInfo was to cut down on individual calls to the SPI. In a call to getItemInfos an implementation may choose to return any number of ItemInfos in one single batch. By making the ChildInfos directly available for those nodes having its child nodes in t

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

i.e. RepositoryService.getChildInfos() returns NodeInfos instead of ChildInfos. I'd favour such a solution. We might even want to further generalize it to RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId) returning an Iterator of NodeInfo. Or am I missing something he

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId) returning an Iterator of NodeInfo. Or am I missing something here? +1 for getting many NodeInfos in one call. However -- is your proposal for the calls passed in as parameter, or for their child nodes? I missed somethi

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

I missed something... the nodeId's are not available to jcr2spi (that is what getChildInfos was/is for). So +1 for Marcel's original suggestion for adding RepositoryService.getChildInfos(). ...the one for which Marcel already agreed it doesn't help for the problem we are trying to solve :-)?

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

...we may want to rename it to getNodeInfos() then :-) Actually I'd prefer something along the line of getChildNodeInfos() to be more explicit and to clearly differentiate it from getNodeInfo(). Michael BR, Julian

Re: [VOTE] Release Apache Jackrabbit 1.5.4

Probably a bit late, but here is my [X] +1 Release this package as Apache Jackrabbit 1.5.4 - signature OK - checksums OK - licence, notice, header, readme and release-notes files OK - maven build OK with both Java 1.4 and 1.5 Michael On Tue, Mar 31, 2009 at 5:21 PM, Jukka Zitting wrote: > Hi,

Re: Jackrabbit 1.5.5 release plan

Hi, I'd like to have https://issues.apache.org/jira/browse/JCR-2070 fixed for 1.5.5. Are there any objections? If not I would apply the patch attached to the issue. Michael Jukka Zitting wrote: Hi, On Thu, Mar 12, 2009 at 12:07 PM, Jukka Zitting wrote: Any other changes should wait fo

Re: Jackrabbit 1.5.5 release plan

Jukka Zitting wrote: > JCR-2070 is still open, but I'm not sure if we should include it in 1.5.5. Michael's second patch looks nice, but perhaps it's better to schedule it for 1.5.6? That's fine with me. The fix is less urgent than I initially thought. Michael Unless anyone objects, I'l

Re: [VOTE] Release Apache Jackrabbit 1.5.5

Please vote on releasing this package as Apache Jackrabbit 1.5.5. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit 1.5.5 [ ] -1 Do not release this package because... +1 R

Re: Developing the TCK for JCR 2.0

But what I was really thinking of were test cases that have been collected since 2006, independently of JSR-283. I think there are some provided by Angela within the SPI projects; so are there more places like that? jackrabbit-jcr2spi contains some more tests which might be generally applic

Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)

I've some problems developing with jackrabbit in Eclipse. Where can I find some info about this? There are many ways to do this, but I'm pretty happy with the m2eclipse plugin from http://m2eclipse.sonatype.org/. The plugin installs cleanly from the update site at http://m2eclipse.sonatype.org/

Re: Jackrabbit 1.5.7 release plan

Jukka, I'm still testing the patch for JCR-1797. I'll let you know when I'm thorough. Michael Jukka Zitting wrote: Hi, We have some need for a new 1.5.x patch release, so I'm going to cut it later this week. Let me know if you have any specific fixes you'd like to see ported back to the re

Re: Jackrabbit 1.5.7 release plan

https://issues.apache.org/jira/browse/JCR-1797 is fixed now at revision: 794012. However the newly added test (org.apache.jackrabbit.jcr2spi.GetItemsTest) doesn't seem to run during the Maven build. It runs fine however when started by its own. Michael Jukka Zitting wrote: Hi, We have som

Re: [VOTE] Release Apache Jackrabbit 1.5.7

+1 Release this package as Apache Jackrabbit 1.5.7 given the missing license header on GetItemsTest.java is not a blocker. - checksums and signatures ok - build with JDK 1.5 on Windows XP ok - license, readme and release notes ok - license headers ok except for jackrabbit-jcr2spi/src/test/jav

Re: JCR to SPI performance improvment

An instanceof test on the childInfo object to see if it's already a nodeInfo could avoid the call to getNodeInfo (and all name resolver operations, path parsing and so on). Johann, While this approach might work, the preferred way to achieve this kind of batch reading is to implement Repos

Re: Jackrabbit management API

[C] == Shutdown using Factory.getRepositoryManager(Repository).shutdown == 1) Properties parameters = ... 2) String factoryClass = parameters.remove("factory").toString(); 3) RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); 4) Repository rep = factory.get

Re: [VOTE] Release jackrabbit-core 1.4.11

+1 - Signatures/checksums ok - Builds fine on Windows XP/Java 5 Michael Jukka Zitting wrote: Hi, I have posted a candidate for the jackrabbit-core 1.4.11 release at: http://people.apache.org/~jukka/jackrabbit/core-1.4.11/ The staged Maven repository is at: https://repository.apa

Re: Remoting and future of JCR-RMI

If webdav is the way to get for remote access, could you please give us some documentation on how to configure the client and server for this communication ? For Jackrabbit 2 and assuming the server is running at localhost port 8080: HashMap params = new HashMap(); params.put(GenericRepository

Re: [VOTE] Release Apache Jackrabbit 2.0.0

Please vote on releasing this package as Apache Jackrabbit 2.0.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. - checksums OK - signature OK - license, notice, readme files OK - license headers OK (with the minor issue of ja

SPI implementation for CMIS is sandbox

Hi, I just committed an initial version of an spi2cmis module to the sandbox: https://svn.apache.org/repos/asf/jackrabbit/sandbox/jackrabbit-spi2cmis Michael Jackrabbit SPI to CMIS -- spi2cmis Introduction This is an experimental implementation of a bridge from JCR to the emerg

Re: [jr3] SPI-based transient layer

we'll probaly have to review the design of the SPI layer should it become the j3 core interface. Maybe not so much. IMO a nice approach would be to have a micro kernel for the 'new' core. On top of that micro kernel one could implement the (probably somewhat revised) SPI interface which toget

Re: [jr3] Plugin architecture

+1 To the plugin architecture in general. I think we should make it very clear from the beginning what constitutes a plugin and clearly distinguish it from a 'module' (or library). IMO a plugin provides some clearly defined, self contained functionality which the *user* can/should care about

Re: [jr3] EventJournal / who merges changes

Thomas, == Proposed Solution == When adding/changing/removing a property or node, the logical operation should be recorded on a high level ("this node was added", "this node was moved from here to there", "this property was added"), first in memory, but when there are changes, it needs to be p

Re: [jr3] EventJournal / who merges changes

Alexander Klimetschek wrote: On Thu, Feb 25, 2010 at 13:28, Michael Dürig wrote: I like this approach. In general I think merging is very difficult if not impossible at all to get right and will always be based on some assumptions (intended semantics). I think we should not put this burden

Re: [jr3] Exception Handling

== Use Error Codes == What about using something like a hash code (for example of the current stack trace) as error code? These would then automatically serve as hash tags for Google searches. That is, errors pasted into a discussion forum would be indexed by Google. Searching for 'Error 6df

Re: [jr3] Exception Handling

ng cryptic for error codes. To see what I mean try Googling for "error 1" and "error 0x800cccff". The second query gives much more precise results. OTOH it needn't be the error code. We could also include it just at what it is, a hash tag. Michael Dominique On Mo

Re: how to load test content for the jcr-tests suite

Justin, Have a look at the test suite of the jackrabbit-jcr2dav module (ConformanceTest.java). There is the 'integration' Maven profile for running these tests. Also the pom.xml contains a list of the currently know issues. Michael On 3/12/10 11:02 PM, Justin Edelson wrote: As I mentione

Re: Hudson build is still unstable: Jackr abbit-trunk » Jackrabbit JCR to WebDAV #1092

This is https://issues.apache.org/jira/browse/JCR-2548 It doesn't seem to be always reproducible. Michael On 22.03.2010 23:48, Apache Hudson Server wrote: See

Re: Hudson build is still unstable: Jackr abbit-trunk » Jackrabbit Core #1094

These test failures seem to be caused by the changes done in JCR-2582. Michael On 3/24/10 3:00 PM, Apache Hudson Server wrote: See

Re: Hudson build is still unstable: Jackrabbit-trunk » Jackrabbit Core #1094

old. regards, toby On Thu, Mar 25, 2010 at 2:21 PM, Tobias Bocanegra wrote: i'll have a look at it. regards, toby On Thu, Mar 25, 2010 at 12:36 PM, Michael Dürig wrote: These test failures seem to be caused by the changes done in JCR-2582. Michael On 3/24/10 3:00 PM, Apache Hudson S

Re: Diagram of Jackrabbit remoting options

This looks good to me. It would be nice to have something like this on the Wiki: http://wiki.apache.org/jackrabbit/RemoteAccess. Michael On 20.7.10 14:00, Marc Herbert wrote: Hi, I tried to summarize Jackrabbit remoting options on a PDF diagram posted here: http://wiki.apache.org/jackra

Re: [jr3] Clustering: Scalable Writes / Asynchronous Change Merging

we could leverage a virtual time algorithm I read the paper, but I don't actually understand how to implement it. See section 7 "Vector Time". Also see [1] from slide 14 onwards for a more approachable reference. Michael [1] http://www.cambridge.org/resources/0521876346/6334_Chapter3.pdf

Re: unable to build trunk: missing dependency

That dependency seems to come from Tika. See https://fisheye6.atlassian.com/changelog/jackrabbit/trunk/jackrabbit-core/pom.xml?cs=1043618 Michael On 9.12.10 13:49, Stefan Guggisberg wrote: hi, i am unable to build jackrabbit trunk (r1043943). maven is complaining about some missing dependen

Re: Fwd: Re: [VOTE] Release Apache Jackrabbit 2.2.0

least Michael Dürig never received this vote (we had some problems with Apache mails reaching Adobe mailboxes earlier), so I'm resending. See below. BR, Jukka Zitting Hi, A candidate for the Jackrabbit 2.2.0 release is available at: http://people.apache.org/~jukka/jackr

Re: [jr3] Sequential Node Ids

Hi Thomas, I think these are interesting graphs and they show that we do not exploit locality sufficiently when persisting nodes. However, your results base on the underlying assumption that sequential node ids lead to better locality than random node ids do. In general this will depends on

Re: ids and locality

I think we should leverage the locality information that is available in the path of an item and use this information also in the persistence layer. while sequential ids give you a hint when nodes were created, paths provide you a much better hint on locality. access patterns I've seen so far in

Re: ids and locality

On 11.1.11 11:35, Thomas Mueller wrote: Hi, This exposes another implicit assumption underlying 'sequential node ids': temporal locality implies spacial locality. This is not necessarily correct however. It's also not necessarily incorrect :-) ... which means it won't always work Michael

Lucene upgrade to Version 3.0.3Lucene upgrade to Version 3.0.3

Hi, In JCR-2415 [1] Sébastien and I are working towards upgrading Lucene to Version 3.0.3. I invite everyone to review our work in the Jackrabbit sandbox [2] and comment on the bug. The current revision (1063730) uses Lucene 3.0.3, the build works and all test cases pass. The upgrade was don

Re: Lucene upgrade to Version 3.0.3Lucene upgrade to Version 3.0.3

On 26.1.11 16:01, Jukka Zitting wrote: Hi, On 26.01.2011 15:51, Michael Dürig wrote: If there are no objections I suggest to merge the sandbox branch back into trunk in a few weeks. I suggest to merge it already now to reduce the likelihood of merge conflicts. There's no big reason to

Security of token base authentication

Hi, Token based authentication as implemented with JCR-2851 seems to exhibit a security issue: the token returned by the server consists of the identifier of a (newly created) node in the repository. An attacker who is able to guess (or acquire by other means i.e. via log files) that identifi

Re: Session.clone()

Why do you want to clone the session in the first place? Wouldn't it be better to prevent the session from timing out? Probably by pinging it somehow? Michael On 24.3.11 16:03, Thomas Mueller wrote: Hi, Use case: a) I have a web application where a user can login to Jackrabbit. b) There

Re: Session.clone()

Wouldn't it be better to prevent the session from timing out? Probably by pinging it somehow? Yes, pinging is an option (it's the current workaround). Timeout is actually not the only problem: sharing a session for distinct operations is generally a problem. Ok this is a different problem wh

Re: [j3] Repository MicroKernel API draft

Hi, Another question: Why would we ever want to build our own JSON parsing and serialization code? Just use one of the existing libraries out there. One of the reasons is that we are not strictly JSON. i.e. order of the items is of importance. Michael

Re: [j3] Repository MicroKernel API draft

why JSON strings? - easy portability - remoting-friendly - leads to very compact API - JSON parsing/generating overhead is IMO minimal and probably more effecient than creating (and collecting) tons of small java objects on the heap I doubt this. In fact I think the situation with the s

Re: [j3] Repository MicroKernel API draft

agreed. since the audience of the MicroKernel API is pretty small programmer-friendliness has admittedly not been a top priority ;) I think programmer-friendliness should have a higher priority then. Where did this priorities come from btw? Programmer unfriendly api's lead to programmers de

Re: [j3] Repository MicroKernel API draft

On 20.6.11 12:36, Stefan Guggisberg wrote: On Mon, Jun 20, 2011 at 12:21 PM, Michael Dürig wrote: why JSON strings? - easy portability - remoting-friendly - leads to very compact API - JSON parsing/generating overhead is IMO minimal and probably more effecient than creating (and

Re: [j3] Repository MicroKernel API draft

2) The complexity of the API: this is a *a lot* simpler than the SPI. You are mixing things up here. The SPI interfaces cope with versioning, access rights, search, workspaces, name spaces, node types, import, locking and observation. All of which is not present in the micro kernel. That's wh

Re: [j3] Repository MicroKernel API draft

I did implement low level 'value' and 'bundle' classes, which could be used by both the client and the MicroKernel: org.apache.jackrabbit.j3.mc.Val org.apache.jackrabbit.j3.mc.Bundle This is actually the way I's prefer to go. Define representations of commonly used entities (Value, Node, Pro

Re: [j3] Repository MicroKernel API draft

What I do worry though, and why I did bring this up in the first place, is that the API being defined ends up being as easy and straightforward to use for key clients, as that's a major part in deciding whether the API is successful or not. Personally, with the assumption that I'll be writing nota

[jr3] MicroKernel API: Provide means for commit message

Hi, I think we should provide means for having a commit message. That message should also go to the journal such that it can be retrieved by calling getRevisions(). See attached patch for details. The rational for this change is that implementing the User Data functionality [1] is not feasi

Re: Jenkins build became unstable: Jackrabbit-trunk » Jackrabbit Core #1611

This seems to be happening from time to time and seems to be a timing issue. Giving the lock a bit more time to time out fixed it on my machine. Should we change the test case accordingly? Michael junit.framework.AssertionFailedError: A released lock must return a negative number of seconds

Re: Jenkins build became unstable: Jackrabbit-trunk » Jackrabbit Core #1611

On Fri, Aug 12, 2011 at 1:46 PM, Michael Dürig wrote: This seems to be happening from time to time and seems to be a timing issue. Giving the lock a bit more time to time out fixed it on my machine. Should we change the test case accordingly? I guess we should do that. The downside is some

Re: Update on j3

Hi, The level of activity on the j3 sandbox has been pretty nice in the past few weeks. Would someone working on the code care to give a short update on the latest developments? The commit messages have been rather terse for now... the goal is to have a working spi-based stack with the microk

Re: [VOTE] Release Apache Jackrabbit 2.3.0

[x] +1 Release this package as Apache Jackrabbit 2.3.0 [ ] -1 Do not release this package because... Checked with check-release.sh Michael

Re: [VOTE] Release Apache Jackrabbit 2.2.9

[x] +1 Release this package as Apache Jackrabbit 2.2.9 [ ] -1 Do not release this package because... Checked with check-release.sh. Michael

Re: [VOTE] Release Apache Jackrabbit 2.1.6

[x] +1 Release this package as Apache Jackrabbit 2.1.6 [ ] -1 Do not release this package because... Checked with check-release.sh Michael

Re: [VOTE] Release Apache Jackrabbit 2.0.5

[x] +1 Release this package as Apache Jackrabbit 2.0.5 [ ] -1 Do not release this package because... Checked with check-release.sh. Michael

Re: Curious method definition

The else branch should probably be defs.add(new QPropertyDefinitionImpl(pd)); I created JCR-3110 [1] for this. Michael [1] https://issues.apache.org/jira/browse/JCR-3110 On 12.10.11 6:34, Dave Brosius wrote: The following method in class / / /org.apache.jackrabbit.spi.commons.QNodeTyp

Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig

On 2.11.11 16:07, Felix Meschberger wrote: Hi, Thanks Thomas and Michael for documenting your JSOP use. I have one comment: + DIFFS::= (ADD | SET | REMOVE | MOVE)* + ADD ::= "+" STRING ":" (OBJECT | ATOM) + SET ::= "^" STRING ":" ATOM + REMOVE ::= "-" STRING I see there is

Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig

The intended use is not only for HTTP calls but rather also for HTTP replies. In the case of a HTTP reply carrying a change log, how would you distinguish setProperty from adProperty? I.e. generate the correct JCR observation events from that change log? Right. I wonder, why this would be of

Re: [VOTE] Release Apache Jackrabbit 2.2.10

+1 Michael On 16.11.11 19:19, Jukka Zitting wrote: Hi, A candidate for the Jackrabbit 2.2.10 release is available at: http://people.apache.org/~jukka/jackrabbit/2.2.10/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/jackrabbit/tags/2.2.10/ T

[jr3 Microkernel] NPE on conflicting commits

There is another case where conflicting commits cause an NPE. This time its a conflict between add and remove. See testcase in forwarded commit message. Michael Original Message Subject: svn commit: r1206008 - /jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/sr

Re: Jackrabbit-trunk - Build # 1754 - Still Unstable

Ok just started it. Michael On 25.11.11 9:29, Alex Parvulescu wrote: can somebody run the build again? I don't have sufficient rights to do so. I'm trying to look at the sql related issues from the latest build (#1754) but I keep running into the JCA Resource Adapter test failures from the pre

[jr3 microkernel] Move overwrites target node

Hi, I just discovered that the move operation does not fail when the target nodes already exists. Is that expected? When node 'b' exists already, the following commit will overwrite it with node 'a': mk.commit("/", ">\"a\" : \"b\" ", head, ""); In contrast adding a node 'b' in the sam

Re: [VOTE] Release Apache Jackrabbit 2.3.4

Hmm I get test failures while the check-release build the tag: Failed tests: testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest): expected:<1> but was:<0> Michael On 24.11.11 16:39, Jukka Zitting wrote: Hi, A candidate for the Jackrabbit 2.3.4 release is ava

Re: [jr3 Microkernel] NPE on conflicting commits

Works great, thanks. Michael On 25.11.11 14:17, Stefan Guggisberg wrote: fixed in svn r1206183. thanks stefan On Fri, Nov 25, 2011 at 11:29 AM, Stefan Guggisberg wrote: On Thu, Nov 24, 2011 at 11:50 PM, Michael Dürig wrote: There is another case where conflicting commits cause an NPE

Re: [jr3 microkernel] Move overwrites target node

I just discovered that the move operation does not fail when the target nodes already exists. Is that expected? no :) fixed in svn r1206201. Works now. Thanks. Michael

[jr3 microkernel] CLustering the Microkernel

Hi, I put up a wiki page [1] which gives a very high level overview re. clustering the microkernel. Michael [1] http://wiki.apache.org/jackrabbit/Clustering%20the%20Microkernel

Re: Jackrabbit-trunk - Build # 1755 - Still Unstable

It seems to be always protected: private static QNodeDefinition createRootNodeDef() { QNodeDefinitionBuilder def = new QNodeDefinitionBuilder(); // FIXME need a fake declaring node type: // rep:root is not quite correct but better than a non-existing node type def.setDeclaring

Re: JSOP

Taking to the dev list: Set currently is: SET ::= "^" STRING ":" ATOM | ARRAY which seems to be the subset needed for setting JCR property values. Shouldn't we be able to overwrite nodes as well? Best regards, Julian This is as intended: it is modeled after the JCR API: set is for se

Re: JSOP

Set currently is: SET ::= "^" STRING ":" ATOM | ARRAY which seems to be the subset needed for setting JCR property values. Shouldn't we be able to overwrite nodes as well? Best regards, Julian This is as intended: it is modeled after the JCR API: set is for setting property values and ad

Re: JSOP

Internally, SET can always be implemented as atomic variant of REMOVE-then-ADD. In general yes. However for the Jackrabbit Microkernel use case this becomes troublesome wrt. observation. The diff format makes no promises about the observable events, so I wouldn't worry about that. What I'

Re: JSOP

On 29.11.11 17:46, Julian Reschke wrote: Internally, SET can always be implemented as atomic variant of REMOVE-then-ADD. In general yes. However for the Jackrabbit Microkernel use case this becomes troublesome wrt. observation. The diff format makes no promises about the observable events,

[jr3 microkernel] Write skew

Hi, As documented earlier [1] new Mircokernel based JCR implementations will most likely introduce snapshot isolation for sessions. While I think this is a good thing in general, it also introduces potentially troublesome write skew: application level constraints might hold locally (i.e. per

Re: JSOP

We still suffer from an agreed-upon set of design goals and constraints. Ack. That's probably why we have several incompatible ad-hoc implementation. If we want to *standardize* something, we need to abstract away things specific to JCR. Also, we need either to get the features we need into

Re: [jr3 microkernel] Write skew

uence inherent to snapshot isolation. [1] http://dl.acm.org/citation.cfm?id=1376690 Regards Felix Am 30.11.2011 um 13:38 schrieb Michael Dürig: Hi, As documented earlier [1] new Mircokernel based JCR implementations will most likely introduce snapshot isolation for sessions. While I think

Re: [jr3 microkernel] Write skew

n in JR2. Michael Regards Felix Am 30.11.2011 um 14:02 schrieb Michael Dürig: This kind of scares me a bit: What could session3 possibly do about this here ? It looks like session3 is created after everything is set and done, thus it is expected that p1==p2==-1 and thus p1-p2==0. session3

Re: [jr3 microkernel] Write skew

On 30.11.11 13:27, Felix Meschberger wrote: That's a different story for a different thread ;-) In a nutshell: under snapshot isolation sessions will see ADD events for items which do not exist for them. OTHO when they get an DELETE event the item will still exist for them. Note how this is rev

Re: [jr3 microkernel] Write skew

On 30.11.11 13:57, Alexander Klimetschek wrote: I expect there is a lot of code outside that relies on the copy-on-write nature of JR 2 - i.e. that anything the session did not touch yet is always "live". Introducing snapshot isolation (which would be copy-on-read IIUC) would break those cases

Re: [jr3 microkernel] Write skew

On 30.11.11 17:13, Stefan Guggisberg wrote: Good catch! Two points: 1) Does visible mean immediately visible on next access or visible after refresh? The second case would work with snapshot isolation. 2) Event though I'd like it to be different, spec. compliance hasn't been a top priority on

Re: [jr3 microkernel] Write skew

On 30.11.11 20:53, Jukka Zitting wrote: 1) Does visible mean immediately visible on next access or visible after refresh? The second case would work with snapshot isolation. That's up the implementation. Section 10.11.1 of JSR 283 [1] explicitly allows changes to become visible only after a

Re: [jr3 microkernel] Write skew

On 1.12.11 12:05, Jukka Zitting wrote: Hi, On Thu, Dec 1, 2011 at 11:07 AM, Michael Dürig wrote: Note however, that for the same reason we are currently not able to guarantee node type consistency: [...] Both sessions will successfully complete since for each of them the consistency

Re: [jr3 microkernel] Write skew

So we (thinking of Sling amongst other things) might have to adapt our event listeners to do a Session.refresh at the beginning of the onEvent method (in case long lived sessions are used). For obvious reasons a snapshot-based implementation would need to implicitly call refresh(true) on a se

Re: [jr3 microkernel] Write skew

On 1.12.11 12:26, Felix Meschberger wrote: So we (thinking of Sling amongst other things) might have to adapt our event listeners to do a Session.refresh at the beginning of the onEvent method (in case long lived sessions are used). For obvious reasons a snapshot-based implementation would ne

Re: [jr3 microkernel] Write skew

On 1.12.11 13:01, Jukka Zitting wrote: Hi, On Thu, Dec 1, 2011 at 1:13 PM, Michael Dürig wrote: But this will introduce a race condition. With other words: this only make the time window during which such a inconsistency could slip in smaller. I think what we'd really need is an atomic

Re: [jr3 microkernel] Write skew

On 1.12.11 13:21, Jukka Zitting wrote: IIUC you want to "auto-refresh" all sessions each time observation events are being delivered? Only those sessions to which events are being delivered, i.e. ones that have explicitly registered an observation listener. Hmm I remain skeptical ;-) Why

Re: [jr3 microkernel] Write skew

Currently the microkernel does nothing about this. That's what this whole discussion is about after all ;-) and please bear in mind that the microkernel project in the jackrabbit sandbox is a prototype and represents WIP... ;) I do. That's exactly why we should challenge it: to discover poss

Re: [jr3 microkernel] Write skew

On 1.12.11 14:25, Jukka Zitting wrote: Eventually consistent approaches are IMO very hard to get right with JCR since most operation are assumed to be persisted after dispatch. One solution I see is to have changes caused by conflict resolution (i.e. during convergence) to appear as normal chan

Re: [jr3 microkernel] Write skew

On 1.12.11 14:25, Jukka Zitting wrote: For the current problem I'd rather have the microkernel to expose some test-and-set semantics as Tom describes in [2]. A test-and-set operation necessarily requires at least some level of atomicity which can quickly become a bottleneck for a clustered se

Re: [jr3 microkernel] Write skew

On 1.12.11 14:25, Jukka Zitting wrote: A third and most general solution which puts away with write skew for good is described in [3]. This requires examining the commit log for certain read-write conflicts on save. If I understand the paper correctly, also this approach requires synchronizat

Re: [jr3 microkernel] Write skew

On 1.12.11 15:10, Jukka Zitting wrote: If I understand the paper correctly, also this approach requires synchronization to establish the serialization order of transactions. No I don't think so. What it does is, it cancels problematic transactions. Detecting these requires finding certain rea

Re: [jr3 microkernel] Write skew

On 1.12.11 15:24, Bart van der Schans wrote: I think the toughest question here is how to merge conflicting commits. There are some quite pathological cases [1]: consider the case where a node x is moved such that it becomes a child of node y in one session and at them same time node y is moved

Re: [jr3 microkernel] Write skew

On 1.12.11 15:34, Jukka Zitting wrote: But I don't think we should try to increase concurrency of write operations within the *same* repository [...] That's a valid solution, but it means that we explicitly drop the idea of being able to scale concurrent writes linearly by adding new cluster

Re: [jr3 microkernel] Write skew

On 1.12.11 14:25, Jukka Zitting wrote: For the current problem I'd rather have the microkernel to expose some test-and-set semantics as Tom describes in [2]. A test-and-set operation necessarily requires at least some level of atomicity which can quickly become a bottleneck for a clustered set

Re: JSOP extension points, was: JSOP

On 5.12.11 13:35, Julian Reschke wrote: This highlights a general problem with the compact syntax; it lacks an extension point. Unless I'm missing something, a today's JSOP parsers will be unable to parse future messages that contain an extension defined like the above, as they won't know how

Re: JSOP extension points, was: JSOP

On 5.12.11 13:35, Julian Reschke wrote: This highlights a general problem with the compact syntax; it lacks an extension point. Unless I'm missing something, a today's JSOP parsers will be unable to parse future messages that contain an extension defined like the above, as they won't know how

Re: JSOP extension points, was: JSOP

On 5.12.11 14:54, Michael Dürig wrote: Unless I'm missing something, a today's JSOP parsers will be unable to parse future messages that contain an extension defined like the above, as they won't know how to skip over it. We could add an extension point to the compact syn

Re: [VOTE] Release Apache Jackrabbit 2.3.5

+1 Michael On 6.12.11 17:29, Jukka Zitting wrote: Hi, A candidate for the Jackrabbit 2.3.5 release is available at: http://people.apache.org/~jukka/jackrabbit/2.3.5/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/jackrabbit/tags/2.3.5/ The S

[jr3 microkernel] prototype (Re: svn commit: r1212018 [1/7] - in /jackrabbit/sandbox/jackrabbit-microkernel: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java

Hi, I just committed a prototype implementation of a JCR repository based on the Microkernel into the sandbox [1]. In contrast to the SPI based prototype [2], this is direct implementation not relying on an existing stack. This is very much work in progress still and many (if not most) thing

Re: [Jackrabbit Wiki] Update of "Jsop" by ThomasMueller

On 9.12.11 9:06, Apache Wiki wrote: Comment: Preserve order of child nodes '''addNodeDiff:''' * + pathString: object + The added node may contain child nodes. The order of child node is preserved, that means, when requesting the object, the child nodes will appear in the same order a

  1   2   3   4   5   >