You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2005/10/18 17:16:47 UTC
[jira] Created: (JCR-256) Improve jcr decorator in jcr-ext
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
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
[jira] Closed: (JCR-256) Improve jcr decorator in jcr-ext
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-256?page=all ]
Marcel Reutegger closed JCR-256:
--------------------------------
> 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
> Assignee: 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
[jira] Commented: (JCR-256) Improve jcr decorator in jcr-ext
Posted by "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
[jira] Updated: (JCR-256) Improve jcr decorator in jcr-ext
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-256?page=all ]
Marcel Reutegger updated JCR-256:
---------------------------------
Attachment: jcr-decorator.patch
> 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
[jira] Assigned: (JCR-256) Improve jcr decorator in jcr-ext
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-256?page=all ]
Marcel Reutegger reassigned JCR-256:
------------------------------------
Assign To: Marcel Reutegger
> 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
> Assignee: 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
[jira] Resolved: (JCR-256) Improve jcr decorator in jcr-ext
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-256?page=all ]
Marcel Reutegger resolved JCR-256:
----------------------------------
Resolution: Fixed
Thanks for your comments. I've committed the patch as is. I didn't touch the name package, because it is not urgent to me to resolve that issue.
- added decoration for all required jcr interfaces
- added more factory methods to DecoratorFactory
- renamed SimpleDecoratorFactory to DefaultDecoratorFactory
- removed ChainedDecoratorFactory and ChainedItemDecorator
- added sample decorator: TrussDecoratorFactory
svn revision: 326437
> 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
> Assignee: 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