[
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