[jira] Commented: (JCR-256) Improve jcr decorator in jcr-ext

["Jukka Zitting (JIRA)" <ji...@apache.org>]

    [ 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira