jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: svn commit: r1387062 - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/name/ oak-core/src/test/java/org/apache/jackrabbit/oak/plugins/name/ oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/
Date Wed, 19 Sep 2012 14:30:56 GMT


On 18.9.12 10:44, Jukka Zitting wrote:
> Hi,
>
> On Tue, Sep 18, 2012 at 11:40 AM, Michael Dürig <mduerig@apache.org> wrote:
>> I think we should unify the approach and extend it to other areas where
>> applicable. The advantages are that there is no code duplication for
>> functionality required in oak-jcr and oak-core and that these classes can be
>> instantiated ad hoc without the need for passing instances of these around.
>
> +1 This approach already opened up a chance to simplify some of the
> name validation code in .oak.plugins.name (no need for the extra
> Namespaces utility class), on which I'm just now working.

Taking this further, the alignment could probably also be extended to 
AbstractNameMapper, which follows a similar pattern. Currently there is 
only one implementation, which is 'session based'. Providing an 
implementation based on a read tree, NameMapper and NamePathMapper 
instances could also be used from within oak-core.

Even further this decouples ValueImple, ValueFactoryImpl and related 
from the session. So we could move these also to oak-core. Now while we 
are at it, is there then still a reason for having a CoreValue 
implementations and ValueImpl? Why not just make CoreValue extend 
javax.jcr.Value?

BTW: javax.jcr.Value is indeed required in oak-core for checking value 
constraints on node types. Currently this is solved by introducing (yet 
another) value implementation: JcrValue implements javax.jcr.Value which 
we could get rid off at the same time also.

Thoughts?


Michael

Mime
View raw message