[
http://issues.apache.org/jira/browse/JCR-212?page=comments#action_12323013 ]
Jukka Zitting commented on JCR-212:
-----------------------------------
Re: NoOpDecoratorFactory.java
There's a subtle reason for the DecoratorFactory interface and the functioning
of some of the decorator methods. To decorate the entire JCR API you need to
manage the various back-references between the decorated instances. For example
the decorated Session.getRepository() method should return the *decorated*
repository instance, not just the repository reference returned by the
underlying session:
Repository repository = decoratorFactory.getRepositoryDecorator(...);
Session session = repository.login();
assertTrue(repository == session.getRepository());
The DecoratorFactory implementation should make sure that all returned
decorators honor this contract. The SimpleDecoratorFactory class binds the
individiual decorator base classes together to implement the decorator layer
for the entire JCR API. Thus the SimpleDecoratorFactory (or the
ChainedDecoratorFactory) should always be used as a base class when adding
custom decorator classes to the decorator layer.
Thus I see little use for the NoOpDecoratorFactory. Instead of doing
NoOpDecoratorFactory.getRepositoryDecorator(repository) you could always just
use the repository instance directly.
> decorator enhancements
> ----------------------
>
> Key: JCR-212
> URL: http://issues.apache.org/jira/browse/JCR-212
> Project: Jackrabbit
> Type: Improvement
> Reporter: Costin Leau
> Assignee: Jukka Zitting
> Attachments: EventListenerDefinition.java, NoOpDecoratorFactory.java,
> decorators.zip
>
> added some decorating enhancements as we discussed on the mailing list
> (apparently there is nothing yet in the gmane /marc archives).
--
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