You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/12/07 12:41:18 UTC
Decoupling resource resolver and resource manager
Hi,
I think we should not let the ResourceManager extend the
ResourceResolver as this complicates its usage.
If you want to get the ResourceManager you currently have to get it from
the request via the getResourceResolver() method and then try to down
cast it.
If we are in an OSGi environment and you want to implement a service
depending on the resource manager, you have to depend (bind) the
resource resolver and test if it is a resource manager. This is a little
bit ugly as you just want to use a resource manager.
As the resource manager gets a Resource object via its method I think we
can decouple the interfaces without any problems.
I currently see no benefit in extending the resource resolver for the
resource manager. Therefore I propose to make it a standalone
interface/service and add a getResourceManager() method to the sling
request which might return null if no resource manager is available.
Or, if we don't want to add the getResourceManager() method, one can get
the resource manager through the service locator (which is fine for me
as well).
In addition we should perhaps think of a better name than resource
manager...
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Yes, adapters always (currently) rely on the functionality supported by
> the concrete implementation. This is the case for both the
> Resource.adaptTo() as well as for the proposed
> ResourceResolver.adaptTo() method.
>
> Of course, we could conceive a more flexible approach as implemented in
> Eclipse, where there is an Adaptable interface defining the adaptTo()
> method and some functionality for implementing configurable adaptors
> exist. Not sure, whether we this for Sling, though.
>
Yepp, I'm not sure, too :)
Ok, so we could start with the adaptTo approach and see where we get
with it.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Yes, adapters always (currently) rely on the functionality supported by
the concrete implementation. This is the case for both the
Resource.adaptTo() as well as for the proposed
ResourceResolver.adaptTo() method.
Of course, we could conceive a more flexible approach as implemented in
Eclipse, where there is an Adaptable interface defining the adaptTo()
method and some functionality for implementing configurable adaptors
exist. Not sure, whether we this for Sling, though.
Regards
Felix
Am Montag, den 10.12.2007, 14:30 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> >
> > Not sure whether I understand you correctly. Thing is that the adaptTo
> > method just returns an object of the requested class (or null if not
> > possible). It is by no means required, that the adaptTo method returns
> > this cast to the correct type. So, the implementation may possible by:
> >
> > public <T> T adaptTo(Class<T> type) {
> > if (type == Session.class) {
> > return (T) getSession();
> > } else if (type == ObjectMapper.class) {
> > return (T) getObjectMapper();
> > }
> > return null;
> > }
> >
> > private ObjectMapper getObjectMapper() {
> > if (objectMapper == null) {
> > objectMapper = new ObjectMapper(getSession());
> > }
> > return objectMapper;
> > }
> >
> > I do not think, that we run into any extension problems using this
> > approach because the ObjectMapper and the ResourceResolver are not
> > necessairily the same.
> >
> Ok, these might not be the same classes, but the service used as the
> resource resolver needs to "know" all possibilities for "adaptTo" and
> needs to do the correct stuff.
> So, if we have two possibilities for adaptTo, you can think of four
> possible implementations - one not supporting the extensions at all, one
> support both and two each supporting just one extension.
>
> I'm not sure if this is just a theoretical problem, but it seems to me
> that this might cause trouble over time.
>
> Carsten
>
Re: Decoupling resource resolver and resource manager
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
>
> Not sure whether I understand you correctly. Thing is that the adaptTo
> method just returns an object of the requested class (or null if not
> possible). It is by no means required, that the adaptTo method returns
> this cast to the correct type. So, the implementation may possible by:
>
> public <T> T adaptTo(Class<T> type) {
> if (type == Session.class) {
> return (T) getSession();
> } else if (type == ObjectMapper.class) {
> return (T) getObjectMapper();
> }
> return null;
> }
>
> private ObjectMapper getObjectMapper() {
> if (objectMapper == null) {
> objectMapper = new ObjectMapper(getSession());
> }
> return objectMapper;
> }
>
> I do not think, that we run into any extension problems using this
> approach because the ObjectMapper and the ResourceResolver are not
> necessairily the same.
>
Ok, these might not be the same classes, but the service used as the
resource resolver needs to "know" all possibilities for "adaptTo" and
needs to do the correct stuff.
So, if we have two possibilities for adaptTo, you can think of four
possible implementations - one not supporting the extensions at all, one
support both and two each supporting just one extension.
I'm not sure if this is just a theoretical problem, but it seems to me
that this might cause trouble over time.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 10.12.2007, 14:06 +0100 schrieb Carsten Ziegeler:
> This would be symmetrical to the resource interface - but I'm not sure
> if we might run into implementation problems with this approach over
> time. Let's assume we have more than one extension for the
> ResourceResolver, the ObjectMapper and the YetUnknownExtension - to
> support both extensions you need to create an implementation hierarchy
> between the implementations (either ObjectMapper extends
> YetUnknownExtension or vice versa). Or you can only have one or the other.
>
> When over time another extension is added you get into the typical multi
> inheritance problem.
>
> On the other hand all these extensions might not be possible to be
> implemented independently from the resource resolver...difficult.
Not sure whether I understand you correctly. Thing is that the adaptTo
method just returns an object of the requested class (or null if not
possible). It is by no means required, that the adaptTo method returns
this cast to the correct type. So, the implementation may possible by:
public <T> T adaptTo(Class<T> type) {
if (type == Session.class) {
return (T) getSession();
} else if (type == ObjectMapper.class) {
return (T) getObjectMapper();
}
return null;
}
private ObjectMapper getObjectMapper() {
if (objectMapper == null) {
objectMapper = new ObjectMapper(getSession());
}
return objectMapper;
}
I do not think, that we run into any extension problems using this
approach because the ObjectMapper and the ResourceResolver are not
necessairily the same.
Regards
Felix
Re: Decoupling resource resolver and resource manager
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Another option could be (as proposed elsewhere) a new method
>
> <T> T ResourceResolver.adaptTo(Class<T> type);
>
> so we could:
>
> Session s = request.getResourceResolver().adaptTo(Session.class);
>
> or
>
> ObjectMapper om =
> request.getResourceResolver().adaptTo(ObjectMapper.class);
>
> WDYT ?
>
This would be symmetrical to the resource interface - but I'm not sure
if we might run into implementation problems with this approach over
time. Let's assume we have more than one extension for the
ResourceResolver, the ObjectMapper and the YetUnknownExtension - to
support both extensions you need to create an implementation hierarchy
between the implementations (either ObjectMapper extends
YetUnknownExtension or vice versa). Or you can only have one or the other.
When over time another extension is added you get into the typical multi
inheritance problem.
On the other hand all these extensions might not be possible to be
implemented independently from the resource resolver...difficult.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Another option could be (as proposed elsewhere) a new method
<T> T ResourceResolver.adaptTo(Class<T> type);
so we could:
Session s = request.getResourceResolver().adaptTo(Session.class);
or
ObjectMapper om =
request.getResourceResolver().adaptTo(ObjectMapper.class);
WDYT ?
Regards
Felix
Am Montag, den 10.12.2007, 12:28 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger schrieb:
> > Hi Carsten,
> >
> > Thinking about this ResourceManager and taking into account the recent
> > changes we introduced to the Resource interface (replacing getRawObject
> > and getObject by the adaptTo method), I would even take a further step:
> > We made the JCR dependency an implementation detail by not providing a
> > getNode() or getItem() method. In the same spirit we should make object
> > mapping an implementation detail.
> >
> > As such I propose to drop the ResourceManager interface alltogether in
> > the Sling API.
> >
> > In the Sling jcr/resource implementation we will have this mapping
> > support and we may introduce such a helper for example as a request
> > attribute or on-demand through a factory method of the
> > JcrResourceManagerFactoryImpl (to be renamed of course to
> > JcrResourceResolverFactoryImpl) as
> >
> > ObjectMapper getObjectMapper(Session session);
> >
> > microsling has no object mapping and thus no such feature.
> >
> > WDYT ?
> >
> Hmm, yes makes sense - would it be possible to make the ObjectMapper
> available through the ServiceLocator? I think that's a little bit more
> convenient than storing it into an request attribute.
>
> Carsten
>
>
Re: Decoupling resource resolver and resource manager
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Am Montag, den 10.12.2007, 12:28 +0100 schrieb Carsten Ziegeler:
>>> In the Sling jcr/resource implementation we will have this mapping
>>> support and we may introduce such a helper for example as a request
>>> attribute or on-demand through a factory method of the
>>> JcrResourceManagerFactoryImpl (to be renamed of course to
>>> JcrResourceResolverFactoryImpl) as
>>>
>>> ObjectMapper getObjectMapper(Session session);
>>>
>>> microsling has no object mapping and thus no such feature.
>>>
>>> WDYT ?
>>>
>> Hmm, yes makes sense - would it be possible to make the ObjectMapper
>> available through the ServiceLocator? I think that's a little bit more
>> convenient than storing it into an request attribute.
>
> I agree regarding the request attribute (therefore I prefer the new
> JcrResourceManagerFactory method). We cannot register the ObjectMapper
> as a service because it will most certainly be linked to a Session,
> which is available per session.
>
Yes (and I fear sooner or later we have to find a solution for this as
well). As a summary: this means that services that are tied to the
current request like the ObjectMapper are available through the
ServiceLocator (which is tied to the current request as well); but these
services including the ServiceLocator are not registered as OSGi services.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 10.12.2007, 12:28 +0100 schrieb Carsten Ziegeler:
> > In the Sling jcr/resource implementation we will have this mapping
> > support and we may introduce such a helper for example as a request
> > attribute or on-demand through a factory method of the
> > JcrResourceManagerFactoryImpl (to be renamed of course to
> > JcrResourceResolverFactoryImpl) as
> >
> > ObjectMapper getObjectMapper(Session session);
> >
> > microsling has no object mapping and thus no such feature.
> >
> > WDYT ?
> >
> Hmm, yes makes sense - would it be possible to make the ObjectMapper
> available through the ServiceLocator? I think that's a little bit more
> convenient than storing it into an request attribute.
I agree regarding the request attribute (therefore I prefer the new
JcrResourceManagerFactory method). We cannot register the ObjectMapper
as a service because it will most certainly be linked to a Session,
which is available per session.
(The JcrResourceManagerFactory [or JcrResourceResolverFactory] is
available as a service).
Regards
Felix
Re: Decoupling resource resolver and resource manager
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger schrieb:
> Hi Carsten,
>
> Thinking about this ResourceManager and taking into account the recent
> changes we introduced to the Resource interface (replacing getRawObject
> and getObject by the adaptTo method), I would even take a further step:
> We made the JCR dependency an implementation detail by not providing a
> getNode() or getItem() method. In the same spirit we should make object
> mapping an implementation detail.
>
> As such I propose to drop the ResourceManager interface alltogether in
> the Sling API.
>
> In the Sling jcr/resource implementation we will have this mapping
> support and we may introduce such a helper for example as a request
> attribute or on-demand through a factory method of the
> JcrResourceManagerFactoryImpl (to be renamed of course to
> JcrResourceResolverFactoryImpl) as
>
> ObjectMapper getObjectMapper(Session session);
>
> microsling has no object mapping and thus no such feature.
>
> WDYT ?
>
Hmm, yes makes sense - would it be possible to make the ObjectMapper
available through the ServiceLocator? I think that's a little bit more
convenient than storing it into an request attribute.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Carsten,
Thinking about this ResourceManager and taking into account the recent
changes we introduced to the Resource interface (replacing getRawObject
and getObject by the adaptTo method), I would even take a further step:
We made the JCR dependency an implementation detail by not providing a
getNode() or getItem() method. In the same spirit we should make object
mapping an implementation detail.
As such I propose to drop the ResourceManager interface alltogether in
the Sling API.
In the Sling jcr/resource implementation we will have this mapping
support and we may introduce such a helper for example as a request
attribute or on-demand through a factory method of the
JcrResourceManagerFactoryImpl (to be renamed of course to
JcrResourceResolverFactoryImpl) as
ObjectMapper getObjectMapper(Session session);
microsling has no object mapping and thus no such feature.
WDYT ?
Regards
Felix
Am Freitag, den 07.12.2007, 12:41 +0100 schrieb Carsten Ziegeler:
> Hi,
>
> I think we should not let the ResourceManager extend the
> ResourceResolver as this complicates its usage.
> If you want to get the ResourceManager you currently have to get it from
> the request via the getResourceResolver() method and then try to down
> cast it.
>
> If we are in an OSGi environment and you want to implement a service
> depending on the resource manager, you have to depend (bind) the
> resource resolver and test if it is a resource manager. This is a little
> bit ugly as you just want to use a resource manager.
> As the resource manager gets a Resource object via its method I think we
> can decouple the interfaces without any problems.
>
> I currently see no benefit in extending the resource resolver for the
> resource manager. Therefore I propose to make it a standalone
> interface/service and add a getResourceManager() method to the sling
> request which might return null if no resource manager is available.
> Or, if we don't want to add the getResourceManager() method, one can get
> the resource manager through the service locator (which is fine for me
> as well).
> In addition we should perhaps think of a better name than resource
> manager...
>
> Carsten
Re: Decoupling resource resolver and resource manager
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> I think we should not let the ResourceManager extend the
> ResourceResolver as this complicates its usage.
> If you want to get the ResourceManager you currently have to get it from
> the request via the getResourceResolver() method and then try to down
> cast it.
>
> If we are in an OSGi environment and you want to implement a service
> depending on the resource manager, you have to depend (bind) the
> resource resolver and test if it is a resource manager. This is a little
> bit ugly as you just want to use a resource manager.
> As the resource manager gets a Resource object via its method I think we
> can decouple the interfaces without any problems.
>
> I currently see no benefit in extending the resource resolver for the
> resource manager. Therefore I propose to make it a standalone
> interface/service and add a getResourceManager() method to the sling
> request which might return null if no resource manager is available.
> Or, if we don't want to add the getResourceManager() method, one can get
> the resource manager through the service locator (which is fine for me
> as well).
> In addition we should perhaps think of a better name than resource
> manager...
>
I'm only speaking of the api here - the impl will most propably shared
between the two services (it could be one component registering for both
interfaces)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Decoupling resource resolver and resource manager
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
To summarize this discussion I created a JIRA issue [1] on what I intend
to be done.
Regards
Felix
[1] http://issues.apache.org/jira/browse/SLING-134
Am Freitag, den 07.12.2007, 12:41 +0100 schrieb Carsten Ziegeler:
> Hi,
>
> I think we should not let the ResourceManager extend the
> ResourceResolver as this complicates its usage.
> If you want to get the ResourceManager you currently have to get it from
> the request via the getResourceResolver() method and then try to down
> cast it.
>
> If we are in an OSGi environment and you want to implement a service
> depending on the resource manager, you have to depend (bind) the
> resource resolver and test if it is a resource manager. This is a little
> bit ugly as you just want to use a resource manager.
> As the resource manager gets a Resource object via its method I think we
> can decouple the interfaces without any problems.
>
> I currently see no benefit in extending the resource resolver for the
> resource manager. Therefore I propose to make it a standalone
> interface/service and add a getResourceManager() method to the sling
> request which might return null if no resource manager is available.
> Or, if we don't want to add the getResourceManager() method, one can get
> the resource manager through the service locator (which is fine for me
> as well).
> In addition we should perhaps think of a better name than resource
> manager...
>
> Carsten