[
https://issues.apache.org/jira/browse/SLING-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger reassigned SLING-134:
---------------------------------------
Assignee: Felix Meschberger
> Decoupling resource resolver and resource manager
> -------------------------------------------------
>
> Key: SLING-134
> URL: https://issues.apache.org/jira/browse/SLING-134
> Project: Sling
> Issue Type: Bug
> Components: API
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
>
> On the dev list in the "Decoupling resource resolver and resource manager"
> thread [1], Carsten raises the question on whether the ResourceManager
> interface should actually extend the ResourceResolver interface. In fact,
> just as we have "removed" the JCR API dependency from the Sling API, we
> should probably also removed the Object Mapping "dependency" from the API and
> make this an implementation detail.
> So to summarize the findings of the discussion, we the SLING API shold be
> modified as follows:
> * Drop the ResourceManager interface alltogether
> * Add a new method to the ResourceResolver interface :
> <Type> Type adaptTo(Class<Type> type);
> Using this method and depending on the implementation, various views of the
> ResourceResolver may be obtained. For microsling an adaptor a JCR Session is
> conceivable, while for Sling an adaptor to both a JCR Session and an
> ObjectContentManager (from the Jackrabbit OCM project) would make sense.
> Please note, that dropping the ResourceManager interface has absolutely no
> impact on the jcr/resource project supporting object mapping through the
> Resource.adaptTo method. This change only make access to the object content
> mapping cleaner and the Sling API simpler.
> If there is no objection, I will implement this change sometime next week.
> [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01211.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
