jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: RepositoryAdapter
Date Wed, 21 Mar 2012 15:42:05 GMT
hi julian

> The sole reason we have this seems to be that repository descriptors are
> JCR values (as of JCR 2.0),

not really. actually jukka was proposing to just expose an adapter
in the JCR layer instead of the actual repository implementation.
that used to be cumbersome in jackrabbit-core.

the second issue was that in jcr2spi the desciptors needed to
be retrieved from the spi and i suspect that we want to do
the same with the oak-api... however, that turned out to be
problematic as the Repository itself had - in the past - no
way to authenticate on the spi layer.

that was the reason for starting with the adapter, not the

> However, this seems to cause different behavior depending on whether you
> get the descriptors directly on the repo, or through
> session.getRepository(). This seems to be a bad idea.

not sure if that shouldn't even be the case.

> Can't we simply all of this by having a session-independant
> ValueFactory, and use it from within the RepositoryImpl?

sure that's perfectly feasible if we can define the set of
descriptors in jcr-oak. in that case just use the simplevaluefactory
from jcr-commons... see my comments above.

> Also, is there a bug to be raised for JSR-333?

basically i consider it a bug that the repository exposes
values... but at the end i don't consider the descriptors a
very important feature of the jcr-specification.
in other words: i am fine with any other approach as well as
long as it does cause problems as the former getRepositoryDescriptor
method did.


View raw message