jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-256) Improve jcr decorator in jcr-ext
Date Tue, 18 Oct 2005 17:48:45 GMT
    [ http://issues.apache.org/jira/browse/JCR-256?page=comments#action_12332381 ] 

Jukka Zitting commented on JCR-256:

Very nice, thanks!

The main reason for chaining the decorators (especially the Item subinterfaces) is to make
it easier to decorate just some aspect of a base interface. For example I might want to decorate
Item.save() to do some special processing (like sending an email of all changes to some content
tree). Without decorator chaining, I'd need to subclass all the ItemDecorator descendants
instead of just overriding the ItemDecorator.save() method.

Other than that I'm very happy about your patch. Feel free to commit it even as it is. I can
return to the chaining issue later when I run into a problem that needs that feature.

About the name clashes: You are right, they should be resolved, preferably by removing the
conflicting names from jcr-ext. I haven't yet done this as I have some private projects that
depend on the pre-jackrabbit-commons qualified name implementation in jcr-ext. I'll take a
look at this on Thursday when I return back from a trip. Feel free to rename or remove the
offending packages if you want to do it before that. 

> Improve jcr decorator in jcr-ext
> --------------------------------
>          Key: JCR-256
>          URL: http://issues.apache.org/jira/browse/JCR-256
>      Project: Jackrabbit
>         Type: Improvement
>     Reporter: Marcel Reutegger
>     Priority: Minor
>  Attachments: jcr-decorator.patch
> The jcr decorator in jcr-ext does not cover all the necessary interfaces of the jcr api.
It may happen that a client loses the decoration layer when accessing properties.
> I've added decoration for several jcr interfaces to ensure that the decoration layer
is never left.
> The attached patch also removes the classes related to decorator chaining. I found it
hard to understand the purpose of those classes and decided to remove them from the default
implementation. If we want to keep those classes they should be less intrusive.
> I've also noticed that there are class name clashes, specifically the package org.apache.jackrabbit.name
contains classes that are also present in the jackrabbit and jackrabbit-commons jar file.
I propose to move the respective classes in jcr-ext to a different package or remove them
in favor of the jackrabbit-commons classes.
> Let me know if I should commit the the patch.
> Thanks

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message