Hi,
On Tue, Feb 19, 2013 at 11:14 AM, Alex Parvulescu
alex.parvule...@gmail.com 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
+1
Michael
On Feb 19, 2013 9:20 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Tue, Feb 19, 2013 at 11:14 AM, Alex Parvulescu
alex.parvule...@gmail.com 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
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
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
Hi,
On Tue, Feb 19, 2013 at 11:59 AM, build...@apache.org wrote:
Blamelist: jukka
Oops, my bad. Fixing it now.
BR,
Jukka Zitting
Hi,
On Tue, Feb 19, 2013 at 12:02 PM, Felix Meschberger fmesc...@adobe.com 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
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
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
Hi,
On Tue, Feb 19, 2013 at 3:17 PM, Alex Parvulescu
alex.parvule...@gmail.com 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
Hi,
On Tue, Feb 19, 2013 at 5:18 PM, Alex Parvulescu
alex.parvule...@gmail.com 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
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
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 SessionOperationPropertyImpl() {
@Override
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:
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
14 matches
Mail list logo
