jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: RepositoryAdapter
Date Wed, 21 Mar 2012 15:58:07 GMT

On Wed, Mar 21, 2012 at 4:42 PM, Angela Schreiber <anchela@adobe.com> wrote:
> 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...

Assuming the set of features in oak-core is fixed, there should be no
need for oak-jcr to query it for the descriptors. Unlike jcr2spi,
oak-jcr knows the underlying repository implementation.

>> 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.

It shouldn't. Calling repository.login().getRepository() should return
the same repository instance as was used for the login() call.

>> 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.

Agreed. In practice the only reasonable way to deal with name and path
values in repository descriptors is to interpret namespace prefixes
according to the namespace registry, not to any given session.


Jukka Zitting

View raw message