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
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/[email protected]/msg01211.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
