buildbot success in ASF Buildbot on oak-trunk

The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/1628 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stam

Re: buildbot failure in ASF Buildbot on oak-trunk

Hi, On Wed, Feb 20, 2013 at 9:20 AM, wrote: > BUILD FAILED: failed compile Oops, didn't notice the extra guava.version entry in the integration tests. Fixed in revision 1448018. BR, Jukka Zitting

buildbot failure in ASF Buildbot on oak-trunk

The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/1627 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp:

Re: enter() method for JCR implementation classes

On 19.2.13 15:51, Jukka Zitting wrote: So, to simplify things I propose that we refactor the above code to something like this: public Something getSomething() { enter("doSomething"); return ...; } The problem is that SessionDelegate.needsRefresh() requires clean

enter() method for JCR implementation classes

Hi, The current boilerplate for most of the methods in our JCR implementation classes looks something like this: public Something getSomething() { checkStatus(); return sessionDelegate.perform( new SessionOperation() { @Override publ

Re: AbstractNodeState strange loop

hi, > I don't believe we'll be seeing too many new NodeState implementations anymore. I could have said the same thing a few weeks ago, but then the segmentmk was born :) I'll followup with an issue to drop the getChildNodeEntries method - that seems easiest. thanks, alex On Tue, Feb 19, 2013

Re: AbstractNodeState strange loop

Hi, On Tue, Feb 19, 2013 at 5:18 PM, Alex Parvulescu wrote: > Dropping the one that I suggested (#getChildNodeEntries) has a really low > footprint as all subclasses have already implemented it. > Future NodeState implementations that extend from ANS need to be aware of > this tiny gem in the cod

Re: AbstractNodeState strange loop

I see. > Dropping one of the default implementations will force all subclasses to implement that method, even if they'd have an easier time implementing just the other one. Dropping the one that I suggested (#getChildNodeEntries) has a really low footprint as all subclasses have already implement

Re: AbstractNodeState strange loop

Hi, On Tue, Feb 19, 2013 at 3:17 PM, Alex Parvulescu wrote: > I came across this funny looking bit in the AbstractNodeState class [0]: Yeah, that's actually intentional... My goal for ANS was to make it as easy as possible to write new draft NodeState implementations without worrying about havin

[OAK-533] code review for pull request

Hello, Could someone please review the pull request I created [1] for OAK-533 [2]? I've tried to take into account what Jukka has suggested in his comment [3] on the JIRA issue with the second commit. Thanks, Radu [1] - https://github.com/apache/jackrabbit-oak/pull/8 [2] - https://issues.apach

Re: How should the current Tree and NodeState apis behave in the case of a null child name?

> Null doesn't make any sense there, so I'd consider it invalid Perfect, see attached patch on OAK-635. I used a combo of @Nonnull and checkNotNull to enforce this constraint. alex On Tue, Feb 19, 2013 at 10:22 AM, Michael Dürig wrote: > +1 > Michael > On Feb 19, 2013 9:20 AM, "Jukka Zitting"

Tracing the calls made to Mongo

Hi, To get a better understanding about the nature of remote calls being made to Mongo from Oak code I have modified the mongo java driver [1] to log details of calls being made through it along with time taken. To make use of that following steps would be required A. Build forked driver code ---

Re: Time for jackrabbit-jcr-auth?

hi felix as explained in my reply to jukka the oak authentication doesn't make use of JCR API but only uses OAK API and some additional oak level pluggins. you may want to follow OAK-608 that covers runtime pluggability of the authentication setup as well as the various subtasks of OAK-17 for th

Re: Time for jackrabbit-jcr-auth?

hi jukka honestly, i fail to see the duplication apart from the fact the there is a certain structure and flow of control given by the java LoginModule base class. the authentication in jackrabbit core was heavily depending on jackrabbit core internals while the rewrite in oak doesn't make use o

buildbot success in ASF Buildbot on oak-trunk

The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/1611 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stam

Re: Time for jackrabbit-jcr-auth?

Hi, If that's all, that is required, I am fine. Regards Felix PS: DefaultLoginModule uses SessionImpl, NodeImpl, and UserImpl. That would have to be fixed, I would assume ? Am 19.02.2013 um 11:08 schrieb Jukka Zitting: > Hi, > > On Tue, Feb 19, 2013 at 12:02 PM, Felix Meschberger > wrote:

Re: Time for jackrabbit-jcr-auth?

Hi, On Tue, Feb 19, 2013 at 12:02 PM, Felix Meschberger wrote: > Can you separate API from implementation in the same step ? The way I see it, the APIs used by such a component should ultimately be just JAAS and JCR. BR, Jukka Zitting

Re: buildbot failure in ASF Buildbot on oak-trunk

Hi, On Tue, Feb 19, 2013 at 11:59 AM, wrote: > Blamelist: jukka Oops, my bad. Fixing it now. BR, Jukka Zitting

Re: Time for jackrabbit-jcr-auth?

Hi Can you separate API from implementation in the same step ? Currently API and implementation is "nicely" mixed, which makes it close to impossible to properly use in an OSGi context. Regards Felix Am 19.02.2013 um 10:52 schrieb Jukka Zitting: > Hi, > > When looking at the login() code for

buildbot failure in ASF Buildbot on oak-trunk

The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/1608 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp:

Time for jackrabbit-jcr-auth?

Hi, When looking at the login() code for OAK-634 I realized that there's a a lot of duplication between jackrabbit-core and oak-core in this area. Would it make sense to split out the authentication code to something like jackrabbit-jcr-auth that could be used by both jackrabbit-core and oak-core

Re: How should the current Tree and NodeState apis behave in the case of a null child name?

+1 Michael On Feb 19, 2013 9:20 AM, "Jukka Zitting" wrote: > Hi, > > On Tue, Feb 19, 2013 at 11:14 AM, Alex Parvulescu > wrote: > > I'm looking at the Tree and the NodeState interfaces, I see a lot of api > > docs about the returned value but no constraints about the input child > name. > > Is n

Re: How should the current Tree and NodeState apis behave in the case of a null child name?

Hi, On Tue, Feb 19, 2013 at 11:14 AM, Alex Parvulescu wrote: > I'm looking at the Tree and the NodeState interfaces, I see a lot of api > docs about the returned value but no constraints about the input child name. > Is null considered a valid input? Null doesn't make any sense there, so I'd con

How should the current Tree and NodeState apis behave in the case of a null child name?

hi, apologies if this has been discussed already and I missed it. I ran into this via some tets in the AccessControlManagerImplTest that trigger a NPE in the Segment MK impl [0]. I'm looking at the Tree and the NodeState interfaces, I see a lot of api docs about the returned value but no constra