[
https://issues.apache.org/jira/browse/SLING-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978942#comment-15978942
]
Stefan Seifert edited comment on SLING-6785 at 4/21/17 3:43 PM:
----------------------------------------------------------------
please note that if the adaptable extends SlingAdaptable ,there is already
today an implicit caching:
https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java#L77
but this does not seem to apply to current SlingHttpServletRequest
implementation. but the JCR resource implementation extends AbstractResource
which extends SlingAdaptable. if we add a scoping/caching support via @Model
annotation we have to make sure that does not mix up with the SlingAdaptable
caching implementation.
---
concerning the ticket in general: as already discussed "application" scope is
dangerous, this should be OSGi services instead sling models.
in general i have a slight "tension" when comparing OSGi services and Sling
models: from a certain toplevel perspective view both provide quite same
("dependency injection in POJOs and some sort of lifecycle"), but do this with
completely different set of annotations. this is puzzling for new developers.
if would be nice if sling models would be osgi components with the additional
sling models stuff attached. but the osgi scoped lifecycle support is not
extensible to support things like "cache per adaptable" or "per session".
was (Author: sseif...@pro-vision.de):
please note that if the adaptable extends SlingAdaptable ,there is already
today an implicit caching:
https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/adapter/SlingAdaptable.java#L77
but this does not seem to apply to current SlingHttpServletRequest
implementation or the current JCR resource implementation, they do not extend
SlingAdaptable. if we add a scoping/caching support via @Model annotation we
have to make sure that does not mix up with the SlingAdaptable caching
implementation.
---
concerning the ticket in general: as already discussed "application" scope is
dangerous, this should be OSGi services instead sling models.
in general i have a slight "tension" when comparing OSGi services and Sling
models: from a certain toplevel perspective view both provide quite same
("dependency injection in POJOs and some sort of lifecycle"), but do this with
completely different set of annotations. this is puzzling for new developers.
if would be nice if sling models would be osgi components with the additional
sling models stuff attached. but the osgi scoped lifecycle support is not
extensible to support things like "cache per adaptable" or "per session".
> Add support for scoped lifecycle of sling models
> ------------------------------------------------
>
> Key: SLING-6785
> URL: https://issues.apache.org/jira/browse/SLING-6785
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Christophe Jelger
> Priority: Minor
> Attachments: SLING-6785.diff
>
>
> Similar to the scopes of JEE beans
> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html), it would be nice
> to have the possibility to set a scope for sling models.
> For example, a sling model instance could be reused for all the components
> within the same HTTP request, thus avoiding that multiple instances of the
> "same" model are created.
> This could be an attribute of the {{@model}} annotation, for example
> something like:
> {{@model(scope="request")}}
> The {{request}} scope sounds straightforward for a sling model adapted from a
> request.
> For models adapted from a resource, there are scenarios where the resource
> itself is not relevant once the model has been instantiated, so it would
> still be useful to be able to obtain the same model instance for different
> components and resources within the same HTTP request.
> We could possibly have the same scopes than the JEE beans scope: {{request}},
> {{session}}, and {{application}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
