On 21.3.12 15:58, Jukka Zitting wrote:
> Hi,
>
> 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.

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