On 21.3.12 15:58, Jukka Zitting wrote:
Hi,On Wed, Mar 21, 2012 at 4:42 PM, Angela Schreiber<[email protected]> 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.
Agreed. Currently
repository.equals(repository.login().getRepository)
returns false which is wrong IMO.
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.Exactly.
Ack again ;-) We should only use (and consider legal) descriptor values which do not depend on a session. Then we could use a respective value factory (i.e. SimpleValueFactory) to provide these values.
Michael
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. BR, Jukka Zitting
