You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2011/02/03 15:33:28 UTC
[jira] Created: (SLING-1967) Document possibility of caching in
Adaptable
Document possibility of caching in Adaptable
--------------------------------------------
Key: SLING-1967
URL: https://issues.apache.org/jira/browse/SLING-1967
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.2.0
Reporter: Alexander Klimetschek
SLING-1673 added caching in SlingAdaptable. This means that Adaptable.adapTo() users must be aware that there won't be a new instance of the requested object upon repeated calls. This should be documented in adaptTo(), i.e. that one cannot expect new instances - or rely on any behavior, be it always the same instance or always a new one.
This affects mostly adapters provided by AdapterFactories, as these will be behind the default caching implementation in SlingAdaptable. If adaptTo() is directly implemented in an object, it can chose itself whether it does caching or not. So I think the docs for AdapterFactory should also be changed to note that - something like "make sure you return re-usable objects here, as these might get cached and the adapter factory won't be called for each adaptTo call of the same object".
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SLING-1967) Document possibility of caching in
Adaptable
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-1967.
--------------------------------------
Resolution: Fixed
Fix Version/s: API 2.2.2
Assignee: Felix Meschberger
Updated and clarified the JavaDoc of the classes in the org.apache.sling.api.adapter package.
> Document possibility of caching in Adaptable
> --------------------------------------------
>
> Key: SLING-1967
> URL: https://issues.apache.org/jira/browse/SLING-1967
> Project: Sling
> Issue Type: Improvement
> Components: API
> Affects Versions: API 2.2.0
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: API 2.2.2
>
>
> SLING-1673 added caching in SlingAdaptable. This means that Adaptable.adapTo() users must be aware that there won't be a new instance of the requested object upon repeated calls. This should be documented in adaptTo(), i.e. that one cannot expect new instances - or rely on any behavior, be it always the same instance or always a new one.
> This affects mostly adapters provided by AdapterFactories, as these will be behind the default caching implementation in SlingAdaptable. If adaptTo() is directly implemented in an object, it can chose itself whether it does caching or not. So I think the docs for AdapterFactory should also be changed to note that - something like "make sure you return re-usable objects here, as these might get cached and the adapter factory won't be called for each adaptTo call of the same object".
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (SLING-1967) Document possibility of caching in
Adaptable
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler closed SLING-1967.
-----------------------------------
> Document possibility of caching in Adaptable
> --------------------------------------------
>
> Key: SLING-1967
> URL: https://issues.apache.org/jira/browse/SLING-1967
> Project: Sling
> Issue Type: Improvement
> Components: API
> Affects Versions: API 2.2.0
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: API 2.2.2
>
>
> SLING-1673 added caching in SlingAdaptable. This means that Adaptable.adapTo() users must be aware that there won't be a new instance of the requested object upon repeated calls. This should be documented in adaptTo(), i.e. that one cannot expect new instances - or rely on any behavior, be it always the same instance or always a new one.
> This affects mostly adapters provided by AdapterFactories, as these will be behind the default caching implementation in SlingAdaptable. If adaptTo() is directly implemented in an object, it can chose itself whether it does caching or not. So I think the docs for AdapterFactory should also be changed to note that - something like "make sure you return re-usable objects here, as these might get cached and the adapter factory won't be called for each adaptTo call of the same object".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1967) Document possibility of caching in
Adaptable
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009573#comment-13009573 ]
Carsten Ziegeler commented on SLING-1967:
-----------------------------------------
I don't think that this is the task of the caller - if we do something in this area, the service implementing the adaption should decide whether it should cache or not.
> Document possibility of caching in Adaptable
> --------------------------------------------
>
> Key: SLING-1967
> URL: https://issues.apache.org/jira/browse/SLING-1967
> Project: Sling
> Issue Type: Improvement
> Components: API
> Affects Versions: API 2.2.0
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: API 2.2.2
>
>
> SLING-1673 added caching in SlingAdaptable. This means that Adaptable.adapTo() users must be aware that there won't be a new instance of the requested object upon repeated calls. This should be documented in adaptTo(), i.e. that one cannot expect new instances - or rely on any behavior, be it always the same instance or always a new one.
> This affects mostly adapters provided by AdapterFactories, as these will be behind the default caching implementation in SlingAdaptable. If adaptTo() is directly implemented in an object, it can chose itself whether it does caching or not. So I think the docs for AdapterFactory should also be changed to note that - something like "make sure you return re-usable objects here, as these might get cached and the adapter factory won't be called for each adaptTo call of the same object".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (SLING-1967) Document possibility of caching
in Adaptable
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote
> I agree that an adaptTo(Class clazz, boolean doNotCache) seems a bit
> "ugly", although it is definitely the caller that wants to make the
> cache/no cache decision.
>
As a caller I don't want to care about implementation details - before
we start adding such a mechanism we should rather skip the caching
completly - though I really think we should keep caching in this area.
Like we see with the input stream, it is up to the implementation
providing the right behaviour - we could simply add support for
implementations that don't want to cache their result as a general
mechanism. But still it is then up to the implementation to decide.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [jira] [Commented] (SLING-1967) Document possibility of caching
in Adaptable
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 21.03.11 19:12, "Felix Meschberger" <fm...@adobe.com> wrote:
>I don't really like this because it adds connotations which might not be
>valid and may even indicate wrong usage of the adaptTo method/mechanism.
>
>The idea of adapTo is to return adapted object in disguise. As such it
>is probably irrelevant whether the object returned from adaptTo is the
>same everytime or not. In fact, I would even expect to get the same
>object each time (if not the same object reference but at least an
>"equals" object).
>
>If a different object is expected on each call to adaptTo, this method
>is probably misused as a factory method.
>
>If there is a general need for such factory functionality, we should
>probably devise an explicit factory mechanism.
Well, the borderline is very fuzzy, even for the standard adaptTo cases
that come with Sling:
On one hand, for example, Resource.adaptTo(InputStream.class) is expected
_and_ implemented to return a new input stream every time for nt:file JCR
nodes. (Here it is implemented directly in the class and not passed to the
Adaptable default implementation that does the caching; but from an API
point of view, there is no difference).
In other cases, people mainly use adaptTo() to get services / "manager"
objects that are tied to the current session using
resourceResolver.adaptTo(...), where caching makes a lot of sense.
I agree that an adaptTo(Class clazz, boolean doNotCache) seems a bit
"ugly", although it is definitely the caller that wants to make the
cache/no cache decision.
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: [jira] [Commented] (SLING-1967) Document possibility of
caching in Adaptable
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Montag, den 21.03.2011, 15:34 +0000 schrieb Bertrand Delacretaz
(JIRA):
> FWIW, I've been bitten by this as well and it took quite a while to
> figure out. I haven't studied the details yet but adding a doNotCache
> parameter to the adaptTo call might help make things more explicit.
I don't really like this because it adds connotations which might not be
valid and may even indicate wrong usage of the adaptTo method/mechanism.
The idea of adapTo is to return adapted object in disguise. As such it
is probably irrelevant whether the object returned from adaptTo is the
same everytime or not. In fact, I would even expect to get the same
object each time (if not the same object reference but at least an
"equals" object).
If a different object is expected on each call to adaptTo, this method
is probably misused as a factory method.
If there is a general need for such factory functionality, we should
probably devise an explicit factory mechanism.
Regards
Felix
[jira] [Commented] (SLING-1967) Document possibility of caching in
Adaptable
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009176#comment-13009176 ]
Bertrand Delacretaz commented on SLING-1967:
--------------------------------------------
FWIW, I've been bitten by this as well and it took quite a while to figure out. I haven't studied the details yet but adding a doNotCache parameter to the adaptTo call might help make things more explicit.
> Document possibility of caching in Adaptable
> --------------------------------------------
>
> Key: SLING-1967
> URL: https://issues.apache.org/jira/browse/SLING-1967
> Project: Sling
> Issue Type: Improvement
> Components: API
> Affects Versions: API 2.2.0
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: API 2.2.2
>
>
> SLING-1673 added caching in SlingAdaptable. This means that Adaptable.adapTo() users must be aware that there won't be a new instance of the requested object upon repeated calls. This should be documented in adaptTo(), i.e. that one cannot expect new instances - or rely on any behavior, be it always the same instance or always a new one.
> This affects mostly adapters provided by AdapterFactories, as these will be behind the default caching implementation in SlingAdaptable. If adaptTo() is directly implemented in an object, it can chose itself whether it does caching or not. So I think the docs for AdapterFactory should also be changed to note that - something like "make sure you return re-usable objects here, as these might get cached and the adapter factory won't be called for each adaptTo call of the same object".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira