[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces
[ https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420975#comment-17420975 ] Justin Edelson commented on SLING-10840: bq. But still it is a very common use-case in real world applications. For example when rewriting response in a java Filter. Isn't this a use case where you would use a wrapper per [~cziegeler]'s comment? > Sling Servlet Helpers implements @ProviderType interfaces > - > > Key: SLING-10840 > URL: https://issues.apache.org/jira/browse/SLING-10840 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Servlet Helpers 1.4.2 >Reporter: David Gonzalez >Priority: Major > > When using the Sling Servlet Helpers bundle/API, code quality scans detect > that implentations in the Sling Servlet Helpers bundle implement > @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here > are some fo the examples (though probably not exhaustive) I found when > attempting to use ths Servlet Helpers library. > > |The product interface org.apache.sling.api.request.RequestParameter > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestParameterMap > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained > in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestPathInfo annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockRequestPathInfo contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.request.RequestProgressTracker > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletRequest annotated > with @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.SlingHttpServletResponse > annotated with @ProviderType should not be implemented by custom code. > Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > |The product interface org.apache.sling.api.resource.Resource annotated with > @ProviderType should not be implemented by custom code. Detected in > org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource > contained in > /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.| > Perhaps there needs to be Wrappers for all these classes that are > @ConsumerTypes? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9674) Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
[
https://issues.apache.org/jira/browse/SLING-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-9674:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
> -
>
> Key: SLING-9674
> URL: https://issues.apache.org/jira/browse/SLING-9674
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> The {{ChildResourceInjector}} always returns one/multiple Resource objects
> which makes it impossible to use those return values with another Sling Model
> requiring the adaptable {{SlingHttpServletRequest}}.
> A solution from ACS Commons introduced
> https://adobe-consulting-services.github.io/acs-aem-commons/features/sling-model-injectors/child-resource-from-request/index.html
> in https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1920.
> There should be a solution built into Sling which allows for easier Sling
> Model aggregation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException
[
https://issues.apache.org/jira/browse/SLING-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-8079:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Returning false in a model PostConstruct causes an
> java.lang.IllegalStateException
> --
>
> Key: SLING-8079
> URL: https://issues.apache.org/jira/browse/SLING-8079
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.6
>Reporter: Santiago García Pimentel
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> I was just trying the exporter framework and the feature from SLING-7124,
> where you can return false in a post construct to prevent a model to being
> returned.
> Unfortunately I found myself with an IllegalStateException:
>
> {quote}java.lang.IllegalStateException: No throwable available at
> org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
> org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:316)
> at
> org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
> at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552){quote}
> It seems like the ModelAdapterFactory assumes that there should be an
> exception if a model was not returned, which is no longer the case. I don't
> think this exception should be thrown.
> The easiest solution I think is to make o.a.s.models.impl.Result not throw
> that exception and let the ModelAdapterFactory handle it, but Im not sure
> that would the be most appropriate way.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9478) Expose the full stack trace for PostConstruct exceptions
[
https://issues.apache.org/jira/browse/SLING-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-9478:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Expose the full stack trace for PostConstruct exceptions
>
>
> Key: SLING-9478
> URL: https://issues.apache.org/jira/browse/SLING-9478
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> Currently any InvocationTargetException is stripped in
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/80b1dea63615ea5be8252241d6147bce9552fa8e/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L756
> as it is replaced by the more generic PostConstruct exception stripping the
> the reflection part of the call stack.
> That may lead to exceptions like
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> Identifier cannot be correctly instantiated by the Use API
> at
> com.adobe.cq.sightly.WCMScriptHelper.includeScript(WCMScriptHelper.java:227)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> at
> com.adobe.cq.sightly.internal.extensions.IncludeExtension.call(IncludeExtension.java:72)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.apps.bruker.components.structure.header.header_html.render(header_html.java:41)
> at
> org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:50)
> [org.apache.sling.scripting.sightly.runtime:1.1.0.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:60)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> [org.apache.sling.scripting.core:2.0.56]
> ... 198 common frames omitted
> Caused by: org.apache.sling.api.SlingException: Cannot get
> DefaultSlingScript: Identifier cannot be correctly instantiated by
> the Use API
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:510)
> [org.apache.sling.scripting.core:2.0.56]
> at
> com.adobe.cq.sightly.WCMScriptHelper.includeScript(WCMScriptHelper.java:222)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> ... 206 common frames omitted
> Caused by: org.apache.sling.scripting.sightly.SightlyException: Identifier
> cannot be correctly instantiated by the Use API
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.apps.bruker.components.structure.header.content_html.render(content_html.java:43)
> at
> org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:50)
> [org.apache.sling.scripting.sightly.runtime:1.1.0.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:60)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> [org.apache.sling.scripting.core:2.0.56]
> ... 207 common frames omitted
> Caused by: org.apache.sling.models.factory.PostConstructException:
> Post-construct method has thrown an exception for model class
> at
>
[jira] [Updated] (SLING-8923) Jackson Sling Model Exporter for application/xml needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-8923: -- Fix Version/s: (was: Sling Models Impl 1.4.14) Sling Models Impl 1.4.16 > Jackson Sling Model Exporter for application/xml needs correct character > encoding > - > > Key: SLING-8923 > URL: https://issues.apache.org/jira/browse/SLING-8923 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Sumanth >Priority: Major > Fix For: Sling Models Impl 1.4.16 > > Attachments: image-2019-12-17-09-18-52-797.png > > > Incorrect Character encoding was identified in the below issue > https://issues.apache.org/jira/browse/SLING-7344 > and the fix was provided only for application/json Content-type. > This issue needs to be fixed even for application/xml type > > Currently, this is being set to iso-8859-1, which would be problem with > Special Characters. > > !image-2019-12-17-09-18-52-797.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9036) Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
[
https://issues.apache.org/jira/browse/SLING-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-9036:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
> --
>
> Key: SLING-9036
> URL: https://issues.apache.org/jira/browse/SLING-9036
> Project: Sling
> Issue Type: New Feature
> Components: Sling Models
>Reporter: Henry Kuijpers
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> Sling Model:
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> MySlingModel.class)
> class MySlingModel {
> @Inject
> public MySlingModel(@Self SlingHttpServletRequest req) {
> logger.log(req.getResourceBundle().getClass().getName());
> }
> }
> {code}
> Calling code:
> {code:java}
> // req obtained via JSP/HTL
> final SlingHttpServletRequest myWrappedReq = new
> SlingHttpServletRequestWrapper(req) {
> @Override
> public ResourceBundle getResourceBundle() {
> return new MyCustomResourceBundle();
> }
> };
>
> final MySlingModel myModel = myWrappedReq.adaptTo(MySlingModel.class);
> {code}
> I would expect the log file to contain "MyCustomResourceBundle". Instead it
> contains "NullResourceBundle".
> This is because the request is being "unwrapped" when doing the adaptTo()
> call: It keeps on delegating to the wrapped request. This should not have
> happened, i.e. how can we otherwise overwrite (parts of) requests and
> resources?
> See also:
> [https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/wrappers/SlingHttpServletRequestWrapper.java#L147]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9781) [Sling Models] Caching doesn't work with Wrapped requests
[
https://issues.apache.org/jira/browse/SLING-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-9781.
---
Resolution: Fixed
Fixed with 73cae5875cc47c76991d0a58e4fb2351595eb146
> [Sling Models] Caching doesn't work with Wrapped requests
> -
>
> Key: SLING-9781
> URL: https://issues.apache.org/jira/browse/SLING-9781
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Christophe Jelger
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The caching of Sling models doesn't work when the original
> {{SlingHttpServletRequest}} is wrapped in a request wrapper, like this is
> typically done in HTL scripts with the {{OnDemandReaderRequest}} wrapper.
> The solution is to use the original request when caching models so that any
> wrapping does not interfere with the caching. When someone enables caching
> for a model adapted from request, I think the expectation is that caching
> does happen whenever the original request is wrapped.
> I'll provide a PR with a fix.
> cc: [~justinedelson] [~radu] as discussed in Slack.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-8706) Injections for java.util.Optional<> should be automatic optional
[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17142111#comment-17142111
]
Justin Edelson commented on SLING-8706:
---
The question of how HTL interprets methods which return {{Optional}} should
really be orthogonal. Whether or not Sling Models supports *injection* of
{{Optional}} fields has no bearing on the API exposed by a model class. One
could have a Sling Model class *today* used by HTL which had a method which
returned an {{Optional}} value.
I don't see why the lack of serialization support is a problem, for two reasons
-- one, I'm not sure how common is it to use Java serialization for model
classes, second, this is (no pun intended) an _optional_ feature so worst case
a model developer would need to make a choice between using Java serialization
and this method for optional field injection. While yes, {{Optional}} wasn't
intended to be used in this way, I see no documentation that its usage as a
field is *prohibited*.
> Injections for java.util.Optional<> should be automatic optional
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The current approach to support optional injections requires to annotate the
> field with {{@Optional}} plus proper handling within the javacode (null
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the
> case that the value is not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException
[
https://issues.apache.org/jira/browse/SLING-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039980#comment-17039980
]
Justin Edelson commented on SLING-8079:
---
[~kwin] What I would suggest is to have {{invokePostConstruct}} return a
special (constant) {{Result}} object (let's say called {{NULL}}) which then the
methods which use the {{Result}} object could check for to determine what to
return/throw/log (which yes, would mean {{invokePostConstruct}} returning a
{{Result}} object rather than it being constructed in {{createObject}}). In the
case of {{getAdapter}} this should be logged and {{null}} returned. In the case
of {{createModel}}, an exception should be thrown -- there's also some other
cases (like adapting an injected field object). But IMO throwing an exception
internally smells like using an exception for control flow and it would be best
to somehow represent this state explicitly.
> Returning false in a model PostConstruct causes an
> java.lang.IllegalStateException
> --
>
> Key: SLING-8079
> URL: https://issues.apache.org/jira/browse/SLING-8079
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.6
>Reporter: Santiago García Pimentel
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
>
> I was just trying the exporter framework and the feature from SLING-7124,
> where you can return false in a post construct to prevent a model to being
> returned.
> Unfortunately I found myself with an IllegalStateException:
>
> {quote}java.lang.IllegalStateException: No throwable available at
> org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
> org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:316)
> at
> org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
> at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552){quote}
> It seems like the ModelAdapterFactory assumes that there should be an
> exception if a model was not returned, which is no longer the case. I don't
> think this exception should be thrown.
> The easiest solution I think is to make o.a.s.models.impl.Result not throw
> that exception and let the ModelAdapterFactory handle it, but Im not sure
> that would the be most appropriate way.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-7624) Add OSGi7 component property annotations for Servlet and Filter
[ https://issues.apache.org/jira/browse/SLING-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473503#comment-16473503 ] Justin Edelson commented on SLING-7624: --- Sorry, didn't understand that restriction. But with the PREFIX_ approach, it looks much better. Thanks! > Add OSGi7 component property annotations for Servlet and Filter > --- > > Key: SLING-7624 > URL: https://issues.apache.org/jira/browse/SLING-7624 > Project: Sling > Issue Type: New Feature > Components: Servlets >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Previously there were annotations hosted at Felix for Sling Servlets/Filters > as custom Felix SCR annotations > (https://github.com/apache/felix/tree/trunk/tools/org.apache.felix.scr.annotations/src/main/java/org/apache/felix/scr/annotations/sling). > With OSGi R7 and DS 1.4 component property annotations are specified. Sling > should provide those annotations in a dedicated new artifact. Compare also > with FELIX-5396. > Those are supported in the upcoming bnd 4.0 > (https://github.com/bndtools/bnd/issues/2163). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7624) Add OSGi7 component property annotations for Servlet and Filter
[
https://issues.apache.org/jira/browse/SLING-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473486#comment-16473486
]
Justin Edelson commented on SLING-7624:
---
IMO, there is some unnecessary verbosity here.
{code:java}
@SlingServletByResourceType(sling_servlet_resourceTypes={"myco/mytype"}){code}
Couldn't this just be
{code:java}
@SlingServletByResourceType(resourceTypes={"myco/mytype"}){code}
> Add OSGi7 component property annotations for Servlet and Filter
> ---
>
> Key: SLING-7624
> URL: https://issues.apache.org/jira/browse/SLING-7624
> Project: Sling
> Issue Type: New Feature
> Components: Servlets
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Previously there were annotations hosted at Felix for Sling Servlets/Filters
> as custom Felix SCR annotations
> (https://github.com/apache/felix/tree/trunk/tools/org.apache.felix.scr.annotations/src/main/java/org/apache/felix/scr/annotations/sling).
> With OSGi R7 and DS 1.4 component property annotations are specified. Sling
> should provide those annotations in a dedicated new artifact. Compare also
> with FELIX-5396.
> Those are supported in the upcoming bnd 4.0
> (https://github.com/bndtools/bnd/issues/2163).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7586) [Sling Models] Memory Leak in cached adapters
[ https://issues.apache.org/jira/browse/SLING-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7586: -- Description: There is a potential memory leak in the adapterCache in ModelAdapterFactory when the model class references the adaptable. The solution is to wrap the model object in a WeakReference. That ensures that the model can be GC'd and then the key can be GC'd. (was: There is a potential memory leak in the adapterCache in ModelAdapterFactory when the model class references the adaptable.) > [Sling Models] Memory Leak in cached adapters > - > > Key: SLING-7586 > URL: https://issues.apache.org/jira/browse/SLING-7586 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.0, Sling Models Impl 1.4.2, Sling > Models Impl 1.4.4, Sling Models Impl 1.4.6, Sling Models Impl 1.4.8 >Reporter: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.10 > > Time Spent: 10m > Remaining Estimate: 0h > > There is a potential memory leak in the adapterCache in ModelAdapterFactory > when the model class references the adaptable. The solution is to wrap the > model object in a WeakReference. That ensures that the model can be GC'd and > then the key can be GC'd. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7586) [Sling Models] Memory Leak in cached adapters
[ https://issues.apache.org/jira/browse/SLING-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7586: -- Affects Version/s: Sling Models Impl 1.4.0 Sling Models Impl 1.4.2 Sling Models Impl 1.4.4 > [Sling Models] Memory Leak in cached adapters > - > > Key: SLING-7586 > URL: https://issues.apache.org/jira/browse/SLING-7586 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.0, Sling Models Impl 1.4.2, Sling > Models Impl 1.4.4, Sling Models Impl 1.4.6, Sling Models Impl 1.4.8 >Reporter: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.10 > > > There is a potential memory leak in the adapterCache in ModelAdapterFactory > when the model class references the adaptable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7586) [Sling Models] Memory Leak in cached adapters
Justin Edelson created SLING-7586: - Summary: [Sling Models] Memory Leak in cached adapters Key: SLING-7586 URL: https://issues.apache.org/jira/browse/SLING-7586 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Impl 1.4.8, Sling Models Impl 1.4.6 Reporter: Justin Edelson Fix For: Sling Models Impl 1.4.10 There is a potential memory leak in the adapterCache in ModelAdapterFactory when the model class references the adaptable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SLING-7584) Only the last DisposalCallbackRegistry is disposed when multiple models are adapted in the same request
[ https://issues.apache.org/jira/browse/SLING-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439818#comment-16439818 ] Justin Edelson edited comment on SLING-7584 at 4/16/18 6:22 PM: pull request: https://github.com/apache/sling-org-apache-sling-models-impl/pull/5 was (Author: justinedelson): pull request: https://github.com/apache/sling-org-apache-sling-models-impl/pull/5/files > Only the last DisposalCallbackRegistry is disposed when multiple models are > adapted in the same request > --- > > Key: SLING-7584 > URL: https://issues.apache.org/jira/browse/SLING-7584 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6, Sling Models Impl 1.4.8 >Reporter: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.10 > > Time Spent: 10m > Remaining Estimate: 0h > > The implementation of SLING-5668 naively assumes that only a single disposal > callback registry will be used per request. This is plainly not the case and > unfortunately results in only the last callback for a given request to be > invoked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7584) Only the last DisposalCallbackRegistry is disposed when multiple models are adapted in the same request
[ https://issues.apache.org/jira/browse/SLING-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439818#comment-16439818 ] Justin Edelson commented on SLING-7584: --- pull request: https://github.com/apache/sling-org-apache-sling-models-impl/pull/5/files > Only the last DisposalCallbackRegistry is disposed when multiple models are > adapted in the same request > --- > > Key: SLING-7584 > URL: https://issues.apache.org/jira/browse/SLING-7584 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6, Sling Models Impl 1.4.8 >Reporter: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.10 > > Time Spent: 10m > Remaining Estimate: 0h > > The implementation of SLING-5668 naively assumes that only a single disposal > callback registry will be used per request. This is plainly not the case and > unfortunately results in only the last callback for a given request to be > invoked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7584) Only the last DisposalCallbackRegistry is disposed when multiple models are adapted in the same request
Justin Edelson created SLING-7584: - Summary: Only the last DisposalCallbackRegistry is disposed when multiple models are adapted in the same request Key: SLING-7584 URL: https://issues.apache.org/jira/browse/SLING-7584 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Impl 1.4.8, Sling Models Impl 1.4.6 Reporter: Justin Edelson Fix For: Sling Models Impl 1.4.10 The implementation of SLING-5668 naively assumes that only a single disposal callback registry will be used per request. This is plainly not the case and unfortunately results in only the last callback for a given request to be invoked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16377598#comment-16377598
]
Justin Edelson edited comment on SLING-7508 at 2/26/18 9:26 PM:
sorry [~diru] was on vacation. the patch looks good to me. I wanted to make
sure there is a clean IT for this before merging – the IT you have is a bit
complicated. PR has been merged and a new IT has been added.
Thanks!
was (Author: justinedelson):
sorry [~diru] was on vacation. the patch looks good to me. I wanted to make
sure there is a clean IT for this before merging – the IT you have is a bit
complicated.
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7508.
---
Resolution: Fixed
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16377598#comment-16377598
]
Justin Edelson commented on SLING-7508:
---
sorry [~diru] was on vacation. the patch looks good to me. I wanted to make
sure there is a clean IT for this before merging – the IT you have is a bit
complicated.
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7508:
--
Fix Version/s: Sling Models Impl 1.4.8
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker
[
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7508:
-
Assignee: Justin Edelson
> StackOverflowError adapting ServletResource to Sling Model with impl picker
> ---
>
> Key: SLING-7508
> URL: https://issues.apache.org/jira/browse/SLING-7508
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.2
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
>
> Adapting a {{SlingHttpServletRequest}} to a servlet that is registered using
> sling.servlet.paths to a {{@Model}} fails in the following StackOverflowError:
> {code}
> java.lang.StackOverflowError: null
> ...
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:318)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> at
> org.apache.sling.models.impl.AdapterImplementations.getModelClassForResource(AdapterImplementations.java:322)
> {code}
> See for example the following pseudo code:
> {code}
> @SlingServlet(paths = "/apps/mypath")
> class MyServlet extends SlingSafeMethodsServlet {
> doGet(request) { request.adaptTo(Model.class); }
> }
> interface Model {
> ...
> }
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> {ModelImpl.class, Model.class})
> class ModelImpl implements Model {
> ...
> }
> {code}
> See the example here:
> https://github.com/Buuhuu/sling-org-apache-sling-models-integration-tests/commit/db174f7a8d43432e4445f4e0aa90487827f66f72
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7517) Memory Leak for "fake" Request objects in ModelAdapterFactory with interface-based models
[ https://issues.apache.org/jira/browse/SLING-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7517. --- Resolution: Fixed Fixed with b1ac26cfe2a6b4c6c20bbe30c5d2b3191e8bb5dc > Memory Leak for "fake" Request objects in ModelAdapterFactory with > interface-based models > - > > Key: SLING-7517 > URL: https://issues.apache.org/jira/browse/SLING-7517 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). > > The fix in SLING-7470 was incomplete and only addressed class-based models. > Interface-based models were not fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7517) Memory Leak for "fake" Request objects in ModelAdapterFactory with interface-based models
[ https://issues.apache.org/jira/browse/SLING-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7517: -- Summary: Memory Leak for "fake" Request objects in ModelAdapterFactory with interface-based models (was: CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory) > Memory Leak for "fake" Request objects in ModelAdapterFactory with > interface-based models > - > > Key: SLING-7517 > URL: https://issues.apache.org/jira/browse/SLING-7517 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). > > The fix in SLING-7470 was incomplete and only addressed class-based models. > Interface-based models were not fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7517) CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory
[ https://issues.apache.org/jira/browse/SLING-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7517: -- Description: The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). The fix in SLING-7470 was incomplete and only addressed class-based models. Interface-based models were not fixed. was: The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). > CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory > - > > Key: SLING-7517 > URL: https://issues.apache.org/jira/browse/SLING-7517 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). > > The fix in SLING-7470 was incomplete and only addressed class-based models. > Interface-based models were not fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7517) CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory
Justin Edelson created SLING-7517: - Summary: CLONE - Memory Leak for "fake" Request objects in ModelAdapterFactory Key: SLING-7517 URL: https://issues.apache.org/jira/browse/SLING-7517 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Impl 1.4.6 Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Sling Models Impl 1.4.8 The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7344) Jackson Sling Model Exporter needs correct character encoding
[
https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361002#comment-16361002
]
Justin Edelson commented on SLING-7344:
---
{quote}FWIW, there is no "right" approach for text/json, as that media type is
undefined.
{quote}
Please explain this to the Jetty team.
> Jackson Sling Model Exporter needs correct character encoding
> -
>
> Key: SLING-7344
> URL: https://issues.apache.org/jira/browse/SLING-7344
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Chris Millar
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.8
>
> Attachments: observe-1.png, observe-2.png, observe-3.png
>
>
> This is a formal ticket of what [~justinedelson] and I discussed earlier in
> December 2017.
> The Jackson Sling Model Exporter needs to correctly set the character
> encoding so content can be correctly handled. It currently defaults out to
> ISO-8859-1 which makes displaying localized content impossible.
> I have put together a sample project here:
> https://github.com/auniverseaway/sling-exporter-sample
> This will show how the default JSON get servlet correctly handles the
> content, but the Jackson exporter does not. I have also attached screenshots
> of the behaviors to this ticket.
> It sounded like Justin had ideas on where to solve this, so I will defer to
> him on where it should be done. If I can help implement a solution in the
> place you want, let me know. Internally, we cannot use the Jackson Exporter
> until this is fixed, so it's pretty high priority for me to contribute back
> if I can.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7344) Jackson Sling Model Exporter needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358605#comment-16358605 ] Justin Edelson commented on SLING-7344: --- Jetty does the right thing for the text/json content type, just not application/json which is what is used in Sling (and mandated by the RFC). > Jackson Sling Model Exporter needs correct character encoding > - > > Key: SLING-7344 > URL: https://issues.apache.org/jira/browse/SLING-7344 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Chris Millar >Assignee: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.8 > > Attachments: observe-1.png, observe-2.png, observe-3.png > > > This is a formal ticket of what [~justinedelson] and I discussed earlier in > December 2017. > The Jackson Sling Model Exporter needs to correctly set the character > encoding so content can be correctly handled. It currently defaults out to > ISO-8859-1 which makes displaying localized content impossible. > I have put together a sample project here: > https://github.com/auniverseaway/sling-exporter-sample > This will show how the default JSON get servlet correctly handles the > content, but the Jackson exporter does not. I have also attached screenshots > of the behaviors to this ticket. > It sounded like Justin had ideas on where to solve this, so I will defer to > him on where it should be done. If I can help implement a solution in the > place you want, let me know. Internally, we cannot use the Jackson Exporter > until this is fixed, so it's pretty high priority for me to contribute back > if I can. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7344) Jackson Sling Model Exporter needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358369#comment-16358369 ] Justin Edelson commented on SLING-7344: --- [~reschke] the problem is that unless we set the charset in the servlet, Jetty automatically sets the charset to ISO-8859-1. I think (as I said on linked the mailing list thread and above) this is clearly a bug in Jetty which we are just working around here (and in the default GET servlet). > Jackson Sling Model Exporter needs correct character encoding > - > > Key: SLING-7344 > URL: https://issues.apache.org/jira/browse/SLING-7344 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Chris Millar >Assignee: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.8 > > Attachments: observe-1.png, observe-2.png, observe-3.png > > > This is a formal ticket of what [~justinedelson] and I discussed earlier in > December 2017. > The Jackson Sling Model Exporter needs to correctly set the character > encoding so content can be correctly handled. It currently defaults out to > ISO-8859-1 which makes displaying localized content impossible. > I have put together a sample project here: > https://github.com/auniverseaway/sling-exporter-sample > This will show how the default JSON get servlet correctly handles the > content, but the Jackson exporter does not. I have also attached screenshots > of the behaviors to this ticket. > It sounded like Justin had ideas on where to solve this, so I will defer to > him on where it should be done. If I can help implement a solution in the > place you want, let me know. Internally, we cannot use the Jackson Exporter > until this is fixed, so it's pretty high priority for me to contribute back > if I can. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7470) Memory Leak for "fake" Request objects in ModelAdapterFactory
[ https://issues.apache.org/jira/browse/SLING-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7470. --- Resolution: Fixed Fixed by https://github.com/apache/sling-org-apache-sling-models-impl/commit/b0647a3419924c46e58b78aa6384e0f49491a0c6 > Memory Leak for "fake" Request objects in ModelAdapterFactory > - > > Key: SLING-7470 > URL: https://issues.apache.org/jira/browse/SLING-7470 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.8 > > > The functionality added in SLING-5668 to dispose of OSGi services (or > anything else needing disposal when creating a Sling Model object) based on > the ServletRequest lifecycle only works if the ServletRequest object was > actually created by the ServletContext. In some cases, applications make > construct "fake" request object (primarily for use with > SlingRequestProcessor). In these cases, since the ServletContext didn't > create these requests, it won't call the requestDestroyed method when they > are complete. > > The easiest way to resolve this is to only apply the special behavior in > SLING-5668 to request objects actually created by the ServletContext and use > the general-purpose ReferenceQueue method for all other requests (and all > other adaptables). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7470) Memory Leak for "fake" Request objects in ModelAdapterFactory
Justin Edelson created SLING-7470: - Summary: Memory Leak for "fake" Request objects in ModelAdapterFactory Key: SLING-7470 URL: https://issues.apache.org/jira/browse/SLING-7470 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Impl 1.4.6 Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Sling Models Impl 1.4.8 The functionality added in SLING-5668 to dispose of OSGi services (or anything else needing disposal when creating a Sling Model object) based on the ServletRequest lifecycle only works if the ServletRequest object was actually created by the ServletContext. In some cases, applications make construct "fake" request object (primarily for use with SlingRequestProcessor). In these cases, since the ServletContext didn't create these requests, it won't call the requestDestroyed method when they are complete. The easiest way to resolve this is to only apply the special behavior in SLING-5668 to request objects actually created by the ServletContext and use the general-purpose ReferenceQueue method for all other requests (and all other adaptables). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7344) Jackson Sling Model Exporter needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7344. --- Resolution: Fixed Although I still think this is really a bug in Jetty, we have already implemented a workaround for the same issue in the default GET servlet, so we can do the same here. > Jackson Sling Model Exporter needs correct character encoding > - > > Key: SLING-7344 > URL: https://issues.apache.org/jira/browse/SLING-7344 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Chris Millar >Assignee: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.8 > > Attachments: observe-1.png, observe-2.png, observe-3.png > > > This is a formal ticket of what [~justinedelson] and I discussed earlier in > December 2017. > The Jackson Sling Model Exporter needs to correctly set the character > encoding so content can be correctly handled. It currently defaults out to > ISO-8859-1 which makes displaying localized content impossible. > I have put together a sample project here: > https://github.com/auniverseaway/sling-exporter-sample > This will show how the default JSON get servlet correctly handles the > content, but the Jackson exporter does not. I have also attached screenshots > of the behaviors to this ticket. > It sounded like Justin had ideas on where to solve this, so I will defer to > him on where it should be done. If I can help implement a solution in the > place you want, let me know. Internally, we cannot use the Jackson Exporter > until this is fixed, so it's pretty high priority for me to contribute back > if I can. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-7344) Jackson Sling Model Exporter needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson reassigned SLING-7344: - Assignee: Justin Edelson Fix Version/s: Sling Models Impl 1.4.8 Component/s: Extensions > Jackson Sling Model Exporter needs correct character encoding > - > > Key: SLING-7344 > URL: https://issues.apache.org/jira/browse/SLING-7344 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Chris Millar >Assignee: Justin Edelson >Priority: Major > Fix For: Sling Models Impl 1.4.8 > > Attachments: observe-1.png, observe-2.png, observe-3.png > > > This is a formal ticket of what [~justinedelson] and I discussed earlier in > December 2017. > The Jackson Sling Model Exporter needs to correctly set the character > encoding so content can be correctly handled. It currently defaults out to > ISO-8859-1 which makes displaying localized content impossible. > I have put together a sample project here: > https://github.com/auniverseaway/sling-exporter-sample > This will show how the default JSON get servlet correctly handles the > content, but the Jackson exporter does not. I have also attached screenshots > of the behaviors to this ticket. > It sounded like Justin had ideas on where to solve this, so I will defer to > him on where it should be done. If I can help implement a solution in the > place you want, let me know. Internally, we cannot use the Jackson Exporter > until this is fixed, so it's pretty high priority for me to contribute back > if I can. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7321) ChildResourceViaProvider should be able to deal with SlingHttpServletRequest
[ https://issues.apache.org/jira/browse/SLING-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7321. --- Resolution: Fixed Assignee: Justin Edelson Pull request merged. Thanks a bunch for this. > ChildResourceViaProvider should be able to deal with SlingHttpServletRequest > > > Key: SLING-7321 > URL: https://issues.apache.org/jira/browse/SLING-7321 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Santiago García Pimentel >Assignee: Justin Edelson >Priority: Minor > Fix For: Sling Models Impl 1.4.8 > > > The ForcedResourceType and ResourceSuperType are able to deal with Sling > requests by creating a wrapper request that returns a wrapped Request. > Still, the ChildResourceViaProvider does not offer such possibility. I think > that for sake of consistency it should. > I propose that if the adaptable is a SlingHttpServletRequest the > ChildResourceViaProvider should create a request wrapper that returns the > child as given in 'value' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7321) ChildResourceViaProvider should be able to deal with SlingHttpServletRequest
[ https://issues.apache.org/jira/browse/SLING-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16300274#comment-16300274 ] Justin Edelson commented on SLING-7321: --- I have a few stylistic comments to make in GitHub, but generally I agree that this looks like a fine addition. Thanks! > ChildResourceViaProvider should be able to deal with SlingHttpServletRequest > > > Key: SLING-7321 > URL: https://issues.apache.org/jira/browse/SLING-7321 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Sling Models Impl 1.4.6 >Reporter: Santiago García Pimentel >Priority: Minor > Fix For: Sling Models Impl 1.4.8 > > > The ForcedResourceType and ResourceSuperType are able to deal with Sling > requests by creating a wrapper request that returns a wrapped Request. > Still, the ChildResourceViaProvider does not offer such possibility. I think > that for sake of consistency it should. > I propose that if the adaptable is a SlingHttpServletRequest the > ChildResourceViaProvider should create a request wrapper that returns the > child as given in 'value' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7307) Sling Model impl should not embed beanutils
[
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289406#comment-16289406
]
Justin Edelson commented on SLING-7307:
---
True, but for the worst possible reason. Fixed in
https://github.com/apache/sling-org-apache-sling-models-integration-tests/commit/bd7658008d6053622a2b154f8f0e7f22e7da431f
> Sling Model impl should not embed beanutils
> ---
>
> Key: SLING-7307
> URL: https://issues.apache.org/jira/browse/SLING-7307
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Alex COLLIGNON
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.8
>
>
> {{org.apache.sling.models.impl}} relies and embeds on Bean Utils.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7307) Sling Model impl should not embed beanutils
[
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7307.
---
Resolution: Fixed
PR Merged
> Sling Model impl should not embed beanutils
> ---
>
> Key: SLING-7307
> URL: https://issues.apache.org/jira/browse/SLING-7307
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Alex COLLIGNON
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.8
>
>
> {{org.apache.sling.models.impl}} relies and embeds on Bean Utils.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7307) Sling Model impl should not embed beanutils
[
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16287787#comment-16287787
]
Justin Edelson commented on SLING-7307:
---
Looking at where this is used, I think it is a trivial removal and we can do it
without pain. {{PropertiesUtils.getProperty()}} handles things like
{{DynaBean}} objects which we obviously don't need to support (and probably
wouldn't work anyway since we're embedding {{BeanUtils}}.
Pull request created:
https://github.com/apache/sling-org-apache-sling-models-impl/pull/2
> Sling Model impl should not embed beanutils
> ---
>
> Key: SLING-7307
> URL: https://issues.apache.org/jira/browse/SLING-7307
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Alex COLLIGNON
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.8
>
>
> {{org.apache.sling.models.impl}} relies and embeds on Bean Utils.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7307) Sling Model impl should not embed beanutils
[
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7307:
--
Fix Version/s: Sling Models Impl 1.4.8
> Sling Model impl should not embed beanutils
> ---
>
> Key: SLING-7307
> URL: https://issues.apache.org/jira/browse/SLING-7307
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Alex COLLIGNON
> Fix For: Sling Models Impl 1.4.8
>
>
> {{org.apache.sling.models.impl}} relies and embeds on Bean Utils.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SLING-7307) Sling Model impl should not embed beanutils
[
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7307:
-
Assignee: Justin Edelson
> Sling Model impl should not embed beanutils
> ---
>
> Key: SLING-7307
> URL: https://issues.apache.org/jira/browse/SLING-7307
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Alex COLLIGNON
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.8
>
>
> {{org.apache.sling.models.impl}} relies and embeds on Bean Utils.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7307) Sling Model impl should not embed beanutils
[
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7307:
--
Component/s: (was: General)
Extensions
> Sling Model impl should not embed beanutils
> ---
>
> Key: SLING-7307
> URL: https://issues.apache.org/jira/browse/SLING-7307
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Alex COLLIGNON
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.8
>
>
> {{org.apache.sling.models.impl}} relies and embeds on Bean Utils.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7292) Only add model object to disposal registry if it is not empty
[
https://issues.apache.org/jira/browse/SLING-7292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson closed SLING-7292.
-
> Only add model object to disposal registry if it is not empty
> -
>
> Key: SLING-7292
> URL: https://issues.apache.org/jira/browse/SLING-7292
> Project: Sling
> Issue Type: Improvement
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
>
> Currently, a reference to a created model object is added to the
> {{ReferenceQueue}} for reference disposal regardless of whether or not the
> model object actually has created any references to clean up. This creates
> unnecessary work when those objects are garbage collected. We should only do
> this when necessary, i.e. disposal callbacks have been registered for that
> model object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7283) ModelPackageBundleListener: lower log level when registering servlets
[
https://issues.apache.org/jira/browse/SLING-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson closed SLING-7283.
-
> ModelPackageBundleListener: lower log level when registering servlets
> -
>
> Key: SLING-7283
> URL: https://issues.apache.org/jira/browse/SLING-7283
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Trivial
> Fix For: Sling Models Impl 1.4.6
>
>
> ModelPackageBundleListener logs messages like this when registering exporters:
> {noformat}
> [pool-1-thread-1] INFO
> org.apache.sling.models.impl.ModelPackageBundleListener - registering servlet
> for core/wcm/components/form/container/v1/container, model, [json]
> {noformat}
> we should lower the log level for this message to debug to avoid spamming log
> files - especially in sling-mock based unit tests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson closed SLING-7187.
-
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-5668) Models: Leverage ServletRequestListener.requestDestroyed for calling DisposalCallback in case the model was created from a request
[
https://issues.apache.org/jira/browse/SLING-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson closed SLING-5668.
-
> Models: Leverage ServletRequestListener.requestDestroyed for calling
> DisposalCallback in case the model was created from a request
> --
>
> Key: SLING-5668
> URL: https://issues.apache.org/jira/browse/SLING-5668
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Sling Models Impl 1.2.6
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
>
> Due to SLING-5664 I had to remove usage of {{SlingScriptHelper}} in the
> {{OSGiServiceInjector}}. Therefore now always the
> {{DisposableCallbackRegistry}} is used to release service references. That
> mechanism relies on a dedicated thread
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L133)
> and phantom references
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L504).
> In case of acting on top of a request one could leverage
> {{ServletRequestListener.requestDestroyed(...)}} instead, which is more
> reliable and called earlier than relying on phantom references.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson closed SLING-7124.
-
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7292) Only add model object to disposal registry if it is not empty
[
https://issues.apache.org/jira/browse/SLING-7292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7292.
---
Resolution: Fixed
Fixed with 56acddf62e55653283d750a938228aea3030b78b
> Only add model object to disposal registry if it is not empty
> -
>
> Key: SLING-7292
> URL: https://issues.apache.org/jira/browse/SLING-7292
> Project: Sling
> Issue Type: Improvement
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
>
> Currently, a reference to a created model object is added to the
> {{ReferenceQueue}} for reference disposal regardless of whether or not the
> model object actually has created any references to clean up. This creates
> unnecessary work when those objects are garbage collected. We should only do
> this when necessary, i.e. disposal callbacks have been registered for that
> model object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7292) Only add model object to disposal registry if it is not empty
Justin Edelson created SLING-7292:
-
Summary: Only add model object to disposal registry if it is not
empty
Key: SLING-7292
URL: https://issues.apache.org/jira/browse/SLING-7292
Project: Sling
Issue Type: Improvement
Reporter: Justin Edelson
Assignee: Justin Edelson
Fix For: Sling Models Impl 1.4.6
Currently, a reference to a created model object is added to the
{{ReferenceQueue}} for reference disposal regardless of whether or not the
model object actually has created any references to clean up. This creates
unnecessary work when those objects are garbage collected. We should only do
this when necessary, i.e. disposal callbacks have been registered for that
model object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-5668) Models: Leverage ServletRequestListener.requestDestroyed for calling DisposalCallback in case the model was created from a request
[
https://issues.apache.org/jira/browse/SLING-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-5668.
---
Resolution: Fixed
Assignee: Justin Edelson
> Models: Leverage ServletRequestListener.requestDestroyed for calling
> DisposalCallback in case the model was created from a request
> --
>
> Key: SLING-5668
> URL: https://issues.apache.org/jira/browse/SLING-5668
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Sling Models Impl 1.2.6
>Reporter: Konrad Windszus
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
>
> Due to SLING-5664 I had to remove usage of {{SlingScriptHelper}} in the
> {{OSGiServiceInjector}}. Therefore now always the
> {{DisposableCallbackRegistry}} is used to release service references. That
> mechanism relies on a dedicated thread
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L133)
> and phantom references
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L504).
> In case of acting on top of a request one could leverage
> {{ServletRequestListener.requestDestroyed(...)}} instead, which is more
> reliable and called earlier than relying on phantom references.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-5668) Models: Leverage ServletRequestListener.requestDestroyed for calling DisposalCallback in case the model was created from a request
[
https://issues.apache.org/jira/browse/SLING-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-5668:
--
Fix Version/s: Sling Models Impl 1.4.6
> Models: Leverage ServletRequestListener.requestDestroyed for calling
> DisposalCallback in case the model was created from a request
> --
>
> Key: SLING-5668
> URL: https://issues.apache.org/jira/browse/SLING-5668
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Sling Models Impl 1.2.6
>Reporter: Konrad Windszus
> Fix For: Sling Models Impl 1.4.6
>
>
> Due to SLING-5664 I had to remove usage of {{SlingScriptHelper}} in the
> {{OSGiServiceInjector}}. Therefore now always the
> {{DisposableCallbackRegistry}} is used to release service references. That
> mechanism relies on a dedicated thread
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L133)
> and phantom references
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L504).
> In case of acting on top of a request one could leverage
> {{ServletRequestListener.requestDestroyed(...)}} instead, which is more
> reliable and called earlier than relying on phantom references.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-5668) Models: Leverage ServletRequestListener.requestDestroyed for calling DisposalCallback in case the model was created from a request
[
https://issues.apache.org/jira/browse/SLING-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282289#comment-16282289
]
Justin Edelson commented on SLING-5668:
---
[~kwin] do you want to review this pull request?
I found it a bit surprising that I had to do the unwrapping in the
{{requestDestroyed}} method, but it turns out that the {{request}} object in
the event is also a wrapper.
> Models: Leverage ServletRequestListener.requestDestroyed for calling
> DisposalCallback in case the model was created from a request
> --
>
> Key: SLING-5668
> URL: https://issues.apache.org/jira/browse/SLING-5668
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Sling Models Impl 1.2.6
>Reporter: Konrad Windszus
>
> Due to SLING-5664 I had to remove usage of {{SlingScriptHelper}} in the
> {{OSGiServiceInjector}}. Therefore now always the
> {{DisposableCallbackRegistry}} is used to release service references. That
> mechanism relies on a dedicated thread
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L133)
> and phantom references
> (https://github.com/apache/sling/blob/b864f105617c0ac7c2d525bfdb66eda2200c6460/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L504).
> In case of acting on top of a request one could leverage
> {{ServletRequestListener.requestDestroyed(...)}} instead, which is more
> reliable and called earlier than relying on phantom references.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7257) Sling Models injector for resolving paths stored in the repo
[
https://issues.apache.org/jira/browse/SLING-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16259561#comment-16259561
]
Justin Edelson commented on SLING-7257:
---
Leaving aside the Tags-specific piece (which appears to depends upon AEM APIs
and so doesn't belong in Sling), how is this different than the existing
ResourcePath injector?
In terms of the Tags, since AEM Tags are not stored (or at least shouldn't be
stored) as traditional paths but rather Tag IDs, the existing ResourcePath
injector won't work. This could be submitted to ACS AEM Commons or wcm.io as a
contribution.
> Sling Models injector for resolving paths stored in the repo
>
>
> Key: SLING-7257
> URL: https://issues.apache.org/jira/browse/SLING-7257
> Project: Sling
> Issue Type: New Feature
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Henry Kuijpers
>
> It would be great to have the ability to store paths in the repository (as a
> string or as a string array) and then resolve them with a simple annotation,
> instead of having a lot of code in the specific models to do so.
> I started working on something that for now only supports resources and tags,
> but I think it should actually be possible to delegate the execution of
> transforming the resource to any object, using the injectors that are already
> available.
> I'm not sure if what I made is the way to go, but at least it's a starting
> point?
> Injector:
> {code}
> @Component
> @Slf4j
> public class ResolvePathInjector implements
> InjectAnnotationProcessorFactory2, Injector {
> @Override
> public String getName() {
> return "resolve-path";
> }
> @Override
> public Object getValue(Object adaptable, String name, Type declaredType,
> AnnotatedElement element,
>DisposalCallbackRegistry callbackRegistry) {
> final ResolvePath annotation =
> element.getAnnotation(ResolvePath.class);
> if (annotation == null) {
> return null;
> }
> final Resource resource = getResource(adaptable);
> if (resource == null) {
> throw new IllegalArgumentException("Cannot get resource resolver
> from adaptable");
> }
> final String[] paths = getPaths(annotation, resource);
> if (paths == null) {
> return null;
> }
> return getValue(paths, declaredType, resource.getResourceResolver());
> }
> private static String[] getPaths(ResolvePath annotation, Resource
> resource) {
> final ValueMap map = resource.adaptTo(ValueMap.class);
> if (map == null) {
> return null;
> }
> final String[] paths = map.get(annotation.name(), String[].class);
> if (paths == null || paths.length == 0) {
> return null;
> }
> return paths;
> }
> private static Object getValue(String[] paths, Type declaredType,
> ResourceResolver resourceResolver) {
> // TODO: Support more injections! I.e. other sling models
> final boolean isTagArray = declaredType == Tag[].class;
> final boolean isTag = declaredType == Tag.class;
> if (!isTag && !isTagArray) {
> return null;
> }
> final List tags = new ArrayList<>();
> final TagManager tagManager =
> resourceResolver.adaptTo(TagManager.class);
> if (tagManager != null) {
> for (String path : paths) {
> final Tag tag = tagManager.resolve(path);
> if (tag != null) {
> tags.add(tag);
> }
> }
> }
> if (isTag && !tags.isEmpty()) {
> return tags.get(0);
> }
> return tags.toArray(new Tag[tags.size()]);
> }
> private static Resource getResource(Object adaptable) {
> Resource resource = null;
> if (adaptable instanceof Resource) {
> resource = (Resource) adaptable;
> } else if (adaptable instanceof SlingHttpServletRequest) {
> resource = ((SlingHttpServletRequest) adaptable).getResource();
> } else if (adaptable instanceof Adaptable) {
> resource = ((Adaptable)adaptable).adaptTo(Resource.class);
> }
> return resource;
> }
> @Override
> public InjectAnnotationProcessor2 createAnnotationProcessor(Object
> adaptable, AnnotatedElement element) {
> // check if the element has the expected annotation
> ResolvePath annotation = element.getAnnotation(ResolvePath.class);
> if (annotation != null) {
> return new ValueAnnotationProcessor(annotation, adaptable);
> }
> return null;
> }
> }
> {code}
> Annotation:
> {code}
> @Target({ ElementType.FIELD,
[jira] [Commented] (SLING-7203) Sling Model Request-Scoped Caching Not Effective Across Script Include Boundaries
[
https://issues.apache.org/jira/browse/SLING-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207730#comment-16207730
]
Justin Edelson commented on SLING-7203:
---
One thing which could work would be to unwind the request in the
{{ModelAdapterFactory}} *only* for use as the cache key.
> Sling Model Request-Scoped Caching Not Effective Across Script Include
> Boundaries
> -
>
> Key: SLING-7203
> URL: https://issues.apache.org/jira/browse/SLING-7203
> Project: Sling
> Issue Type: Bug
>Reporter: Justin Edelson
>
> The request-scoped caching added in SLING-6785 does not work correctly across
> included boundaries, i.e. if you have a script like
> {code}
>
>
> {code}
> and both {{first.html}} the request is adapted to some cacheable model
> object, the adaptation will happen twice, despite the cache attribute on the
> {{@Model}} annotation.
> The reason for this is that each script actually has a unique request object,
> instantiated by {{ScriptHelper}} (see
> https://github.com/apache/sling/blob/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/ScriptHelper.java#L100).
> I don't know what a good way to fix this is. One option could be to unwrap
> the {{SlingHttpServletRequestWrapper}} in {{SlingModelsUseProvider}}.
> [~kwin] any ideas?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7203) Sling Model Request-Scoped Caching Not Effective Across Script Include Boundaries
[
https://issues.apache.org/jira/browse/SLING-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207721#comment-16207721
]
Justin Edelson commented on SLING-7203:
---
Thinking about this some more, unwinding the wrapping would probably break the
functionality added in SLING-7015 (as well as custom implementations doing
similar things).
> Sling Model Request-Scoped Caching Not Effective Across Script Include
> Boundaries
> -
>
> Key: SLING-7203
> URL: https://issues.apache.org/jira/browse/SLING-7203
> Project: Sling
> Issue Type: Bug
>Reporter: Justin Edelson
>
> The request-scoped caching added in SLING-6785 does not work correctly across
> included boundaries, i.e. if you have a script like
> {code}
>
>
> {code}
> and both {{first.html}} the request is adapted to some cacheable model
> object, the adaptation will happen twice, despite the cache attribute on the
> {{@Model}} annotation.
> The reason for this is that each script actually has a unique request object,
> instantiated by {{ScriptHelper}} (see
> https://github.com/apache/sling/blob/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/ScriptHelper.java#L100).
> I don't know what a good way to fix this is. One option could be to unwrap
> the {{SlingHttpServletRequestWrapper}} in {{SlingModelsUseProvider}}.
> [~kwin] any ideas?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7203) Sling Model Request-Scoped Caching Not Effective Across Script Include Boundaries
Justin Edelson created SLING-7203:
-
Summary: Sling Model Request-Scoped Caching Not Effective Across
Script Include Boundaries
Key: SLING-7203
URL: https://issues.apache.org/jira/browse/SLING-7203
Project: Sling
Issue Type: Bug
Reporter: Justin Edelson
The request-scoped caching added in SLING-6785 does not work correctly across
included boundaries, i.e. if you have a script like
{code}
{code}
and both {{first.html}} the request is adapted to some cacheable model object,
the adaptation will happen twice, despite the cache attribute on the {{@Model}}
annotation.
The reason for this is that each script actually has a unique request object,
instantiated by {{ScriptHelper}} (see
https://github.com/apache/sling/blob/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/ScriptHelper.java#L100).
I don't know what a good way to fix this is. One option could be to unwrap the
{{SlingHttpServletRequestWrapper}} in {{SlingModelsUseProvider}}.
[~kwin] any ideas?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7187:
-
Assignee: Justin Edelson
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199005#comment-16199005
]
Justin Edelson commented on SLING-7187:
---
I did find one additional oddity.
{code}
@ValueMapValue(optional=true)
@Required
{code}
In this case, the field is optional. BUT...
{code}
@ValueMapValue(injectionStrategy = InjectionStrategy.OPTIONAL)
@Required
{code}
The field is optional.
Since, as [~kwin] notes the optional attribute is deprecated, I'm not going to
fix that, but I did add the test cases to save the behavior.
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7187.
---
Resolution: Fixed
fixed in r1811741
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198999#comment-16198999
]
Justin Edelson commented on SLING-7187:
---
bq. The patch in general looks fine but it would modify the behavior in case
both the optional attribute is set to false as well as the @Optional annotation
is set, as with your patch the @Optional would take precedence. But since this
would be rather unexpected I don't think this is a problem.
Yes, that's the whole point :) since the optional attribute is set to false by
default.
bq. I would just like to highlight that the optional attribute is anyhow
deprecated since SLING-4155 and instead the injectionStrategy attribute should
be used.
The problem is that even if someone doesn't use it, it is still set. I guess
the other alternative to this would be to remove support for the optional
attribute entirely (i.e. just ignore it if set). I don't think we need to do
that.
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198835#comment-16198835
]
Justin Edelson edited comment on SLING-7187 at 10/10/17 5:16 PM:
-
patch attached. [~kwin] can you take a look at this since I think you did the
original implementation.
was (Author: justinedelson):
patch attached. [~kwindszus] can you take a look at this since I think you did
the original implementation.
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
[
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7187:
--
Attachment: SLING-7187.diff
patch attached. [~kwindszus] can you take a look at this since I think you did
the original implementation.
> Use of Injector-specific annotation and @Optional results in required-value
> ---
>
> Key: SLING-7187
> URL: https://issues.apache.org/jira/browse/SLING-7187
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.4
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7187.diff
>
>
> If there is a model class like
> {code}
> @Model(adaptables = Resource.class)
> public class ModelClass {
> @ValueMapValue
> private String otherText;
> @Override
> public String getOtherText() {
> return otherText;
> }
> @ValueMapValue
> @Optional
> private String emptyText;
> @Override
> public String getEmptyText() {
> return emptyText;
> }
> }
> {code}
> It would be a reasonable expectation that the {{emptyText}} field will be
> optional. But that is not actually the case since the {{@ValueMapValue}} has
> a default {{optional}} attribute of {{false}}.
> Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
> having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value
Justin Edelson created SLING-7187:
-
Summary: Use of Injector-specific annotation and @Optional results
in required-value
Key: SLING-7187
URL: https://issues.apache.org/jira/browse/SLING-7187
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Sling Models Impl 1.4.4
Reporter: Justin Edelson
Fix For: Sling Models Impl 1.4.6
If there is a model class like
{code}
@Model(adaptables = Resource.class)
public class ModelClass {
@ValueMapValue
private String otherText;
@Override
public String getOtherText() {
return otherText;
}
@ValueMapValue
@Optional
private String emptyText;
@Override
public String getEmptyText() {
return emptyText;
}
}
{code}
It would be a reasonable expectation that the {{emptyText}} field will be
optional. But that is not actually the case since the {{@ValueMapValue}} has a
default {{optional}} attribute of {{false}}.
Can be worked around by using {{@ValueMapValue(optional = true)}} instead of
having the separate {{@Optional}} annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188675#comment-16188675 ] Justin Edelson commented on SLING-7174: --- that's just me forgetting to commit a file. Should be fixed now. > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer >Assignee: Justin Edelson > Fix For: Servlet Helpers 1.1.2, Sling Models Impl 1.4.6 > > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7174. --- Resolution: Fixed > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer >Assignee: Justin Edelson > Fix For: Servlet Helpers 1.1.2, Sling Models Impl 1.4.6 > > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[
https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188487#comment-16188487
]
Justin Edelson commented on SLING-7174:
---
Fixed in r1810562/r1810564 by properly implementing the {{getReader}} method.
Also fixed the implementation of {{getInputStream}} to properly through
{{IllegalStateException}} if the reader has already been accessed.
Also fixed in r1810563 by catching the exception in {{ExportServlet}} since
even with these changes, an {{IllegalStateException}} could be thrown by a call
to {{getReader}}.
> Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with
> Export Servlet
>
>
> Key: SLING-7174
> URL: https://issues.apache.org/jira/browse/SLING-7174
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Environment: Sling 9, Java 1.8
>Reporter: Andreas Schaefer
>Assignee: Justin Edelson
> Fix For: Servlet Helpers 1.1.2, Sling Models Impl 1.4.6
>
>
> When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a
> page within sling then I will get an Unsupported Operation Exception when I
> hit the Export Servlet.
> The reason is that the Export Servlet is retrieving Request Reader in
> addScriptBindings():
> bindings.put(READER, request.getReader());
> In my opinion Sling should provide a Request / Response class for in-Sling
> rendering that is for that specific purpose as using that class for testing
> does clash with the the rendering.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7174: -- Fix Version/s: Sling Models Impl 1.4.6 Servlet Helpers 1.1.2 > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer >Assignee: Justin Edelson > Fix For: Servlet Helpers 1.1.2, Sling Models Impl 1.4.6 > > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188477#comment-16188477 ] Justin Edelson commented on SLING-7174: --- bq. If that Request / Response pair if for In-Sling rendering why is it then prefixed with 'Mock' Because naming things is hard. bq. why does it throw an Unsupported Operation Exception? Presumably because no one thought that was an issue. > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer >Assignee: Justin Edelson > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson reassigned SLING-7174: - Assignee: Justin Edelson > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer >Assignee: Justin Edelson > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188425#comment-16188425 ] Justin Edelson commented on SLING-7174: --- bq. In my opinion Sling should provide a Request / Response class for in-Sling rendering that is for that specific purpose as using that class for testing does clash with the the rendering. It does. That's the purpose of the Servlet Helpers bundle. > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7174) Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with Export Servlet
[ https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7174: -- Component/s: (was: Servlets) Extensions > Using MockSlingHttpServletRequest for In-Sling Rendering fails when used with > Export Servlet > > > Key: SLING-7174 > URL: https://issues.apache.org/jira/browse/SLING-7174 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: Sling 9, Java 1.8 >Reporter: Andreas Schaefer > > When I use MockSlingHttpServletRequest with SlingRequestProcessor to render a > page within sling then I will get an Unsupported Operation Exception when I > hit the Export Servlet. > The reason is that the Export Servlet is retrieving Request Reader in > addScriptBindings(): > bindings.put(READER, request.getReader()); > In my opinion Sling should provide a Request / Response class for in-Sling > rendering that is for that specific purpose as using that class for testing > does clash with the the rendering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7095) Document Sling Models cache feature
[
https://issues.apache.org/jira/browse/SLING-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187358#comment-16187358
]
Justin Edelson commented on SLING-7095:
---
well spotted [~kwin]. restored
> Document Sling Models cache feature
> ---
>
> Key: SLING-7095
> URL: https://issues.apache.org/jira/browse/SLING-7095
> Project: Sling
> Issue Type: Task
> Components: Extensions, Site
>Reporter: Oliver Lietz
>Assignee: Justin Edelson
>
> See SLING-6785 Add support for scoped lifecycle of sling models
> ({{@Model(adaptables = SlingHttpServletRequest.class, cache = true)}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7095) Document Sling Models cache feature
[
https://issues.apache.org/jira/browse/SLING-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7095.
---
Resolution: Fixed
> Document Sling Models cache feature
> ---
>
> Key: SLING-7095
> URL: https://issues.apache.org/jira/browse/SLING-7095
> Project: Sling
> Issue Type: Task
> Components: Extensions, Site
>Reporter: Oliver Lietz
>Assignee: Justin Edelson
>
> See SLING-6785 Add support for scoped lifecycle of sling models
> ({{@Model(adaptables = SlingHttpServletRequest.class, cache = true)}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7095) Document Sling Models cache feature
[
https://issues.apache.org/jira/browse/SLING-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180671#comment-16180671
]
Justin Edelson commented on SLING-7095:
---
I've added a section all about caching to
http://sling.apache.org/documentation/bundles/models.html#caching
> Document Sling Models cache feature
> ---
>
> Key: SLING-7095
> URL: https://issues.apache.org/jira/browse/SLING-7095
> Project: Sling
> Issue Type: Task
> Components: Extensions, Site
>Reporter: Oliver Lietz
>Assignee: Justin Edelson
>
> See SLING-6785 Add support for scoped lifecycle of sling models
> ({{@Model(adaptables = SlingHttpServletRequest.class, cache = true)}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SLING-7095) Document Sling Models cache feature
[
https://issues.apache.org/jira/browse/SLING-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7095:
-
Assignee: Justin Edelson
> Document Sling Models cache feature
> ---
>
> Key: SLING-7095
> URL: https://issues.apache.org/jira/browse/SLING-7095
> Project: Sling
> Issue Type: Task
> Components: Extensions, Site
>Reporter: Oliver Lietz
>Assignee: Justin Edelson
>
> See SLING-6785 Add support for scoped lifecycle of sling models
> ({{@Model(adaptables = SlingHttpServletRequest.class, cache = true)}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170075#comment-16170075
]
Justin Edelson commented on SLING-5739:
---
[~kwin] docs have been updated.
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.4.0
>
> Attachments: SLING-5739.diff
>
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson closed SLING-5739.
-
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.4.0
>
> Attachments: SLING-5739.diff
>
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-5739:
--
Fix Version/s: Sling Models API 1.3.4
Sling Models Impl 1.4.0
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.4.0
>
> Attachments: SLING-5739.diff
>
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7124:
-
Assignee: Justin Edelson
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7124.
---
Resolution: Fixed
committed in r1808699
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7124:
--
Fix Version/s: Sling Models Impl 1.4.6
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.6
>
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16168184#comment-16168184
]
Justin Edelson commented on SLING-7124:
---
Good point [~kwin]. Added this log message:
{code}
251 [main] DEBUG org.apache.sling.models.impl.ModelAdapterFactory -
PostConstruct method
org.apache.sling.models.testmodels.classes.FalsePostConstuctModel.pc returned
false. Returning null model.
{code}
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7124:
--
Attachment: SLING-7124.diff
proposed diff
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
Justin Edelson created SLING-7124:
-
Summary: Allow PostConstruct method to return false to indicate
that a model object should not be returned
Key: SLING-7124
URL: https://issues.apache.org/jira/browse/SLING-7124
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Justin Edelson
In cases where a model objects (as opposed to the adaptable Resources) need to
be validated programmatically, the options at present are to have the
PostConstruct method throw an Exception or to have a special method which
clients use to determine if the object is valid. The former adds unnecessary
noise to the log files and the latter puts undue complexity on clients.
It should be possible to return {{false}} from the PostConstruct method and for
this to be considered a signal for a null value to be returned from the
adaptTo() method (without extra logging). For the createModel() cases, we can't
return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7122) Sling Models: @Path and @ResourcePath should allow relative paths
[
https://issues.apache.org/jira/browse/SLING-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164725#comment-16164725
]
Justin Edelson commented on SLING-7122:
---
@ChildResource should work for non-immediate children, although there could be
limitations of certain ResourceProviders. But the contract for
{{Resource.getChild()}} says
bq. Returns the child at the given relative path of this resource or {{null}}
if no such child exists.
> Sling Models: @Path and @ResourcePath should allow relative paths
> -
>
> Key: SLING-7122
> URL: https://issues.apache.org/jira/browse/SLING-7122
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Sling Models API 1.3.6
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> It would be nice if the ResourcePathInjector could not only allow injecting
> resources with absolute paths, but also with relative paths. For example if
> I'm constructing a model from a Resource /some/resource , I currently don't
> see a way to inject the subresource, say, jcr:content/config . @ChildResource
> can be used to inject immediate children, but not descendants.
> It would be easy to distinguish between absolute and relative paths: if it
> starts with / it is an absolute path, otherwise relative.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7069) CompositeHealthcheck combines subchecks with AND instead of OR
[
https://issues.apache.org/jira/browse/SLING-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7069.
---
Resolution: Fixed
fixed in r1805830
there's now an option {{filter.combineTagsWithOr}}
if there is interest in a broader expression language, that should be a
separate issue :)
> CompositeHealthcheck combines subchecks with AND instead of OR
> --
>
> Key: SLING-7069
> URL: https://issues.apache.org/jira/browse/SLING-7069
> Project: Sling
> Issue Type: Improvement
> Components: Health Check
>Affects Versions: Health Check Core 1.2.8
>Reporter: Jörg Hoh
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.10
>
>
> I have a CompositeHealthcheck like this
> {code}
> http://sling.apache.org/jcr/sling/1.0;
> xmlns:cq="http://www.day.com/jcr/cq/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> xmlns:nt="http://www.jcp.org/jcr/nt/1.0;
> jcr:primaryType="sling:OsgiConfig"
> hc.name="Health Checks (Runtime)"
> hc.mbean.name="runtime-monitoring"
> filter.tags="[tag1,tag2,tag3]"
> hc.tags="[runtime-monitoring]"
> hc.async.cronExpression="50 0/1 * 1/1 * ? *"/>
> {code}
> whenever I run a healthcheck on the tag "runtime-monitoring" the healthchecks
> tagged with "tag1", "tag2" and "tage3" should be executed.
> But whenever I run the healthceck on "runtime-monitoring", noone is executed
> at all.
> I tracked it down to the fact, that only these healthchecks are executed
> which have all tags (tag1,tag2 and tag3) configured. Which of course none of
> my tags are.
> {code}
> 21.08.2017 17:06:00.502 *DEBUG* [HealthCheck Health Checks (Runtime)]
> org.apache.sling.hc.util.HealthCheckFilter OSGi service filter in
> getTaggedHealthCheckServiceReferences():
> (&(objectClass=org.apache.sling.hc.api.HealthCheck)(hc.tags=tag1)(hc.tags=tag2)(hc.tags=tag3))
> {code}
> It seems to me that instead of the AND it should be an OR:
> {code}
> (&(objectClass=org.apache.sling.hc.api.HealthCheck)(|(hc.tags=tag1)(hc.tags=tag2)(hc.tags=tag3)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SLING-7069) CompositeHealthcheck combines subchecks with AND instead of OR
[
https://issues.apache.org/jira/browse/SLING-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson reassigned SLING-7069:
-
Assignee: Justin Edelson
Fix Version/s: Health Check Core 1.2.10
Issue Type: Improvement (was: Bug)
> CompositeHealthcheck combines subchecks with AND instead of OR
> --
>
> Key: SLING-7069
> URL: https://issues.apache.org/jira/browse/SLING-7069
> Project: Sling
> Issue Type: Improvement
> Components: Health Check
>Affects Versions: Health Check Core 1.2.8
>Reporter: Jörg Hoh
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.10
>
>
> I have a CompositeHealthcheck like this
> {code}
> http://sling.apache.org/jcr/sling/1.0;
> xmlns:cq="http://www.day.com/jcr/cq/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> xmlns:nt="http://www.jcp.org/jcr/nt/1.0;
> jcr:primaryType="sling:OsgiConfig"
> hc.name="Health Checks (Runtime)"
> hc.mbean.name="runtime-monitoring"
> filter.tags="[tag1,tag2,tag3]"
> hc.tags="[runtime-monitoring]"
> hc.async.cronExpression="50 0/1 * 1/1 * ? *"/>
> {code}
> whenever I run a healthcheck on the tag "runtime-monitoring" the healthchecks
> tagged with "tag1", "tag2" and "tage3" should be executed.
> But whenever I run the healthceck on "runtime-monitoring", noone is executed
> at all.
> I tracked it down to the fact, that only these healthchecks are executed
> which have all tags (tag1,tag2 and tag3) configured. Which of course none of
> my tags are.
> {code}
> 21.08.2017 17:06:00.502 *DEBUG* [HealthCheck Health Checks (Runtime)]
> org.apache.sling.hc.util.HealthCheckFilter OSGi service filter in
> getTaggedHealthCheckServiceReferences():
> (&(objectClass=org.apache.sling.hc.api.HealthCheck)(hc.tags=tag1)(hc.tags=tag2)(hc.tags=tag3))
> {code}
> It seems to me that instead of the AND it should be an OR:
> {code}
> (&(objectClass=org.apache.sling.hc.api.HealthCheck)(|(hc.tags=tag1)(hc.tags=tag2)(hc.tags=tag3)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7049) MissingExporterException thrown when the desired ModelExporter is not the first in the list
[ https://issues.apache.org/jira/browse/SLING-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7049. --- Resolution: Fixed fixed in r1805037 > MissingExporterException thrown when the desired ModelExporter is not the > first in the list > --- > > Key: SLING-7049 > URL: https://issues.apache.org/jira/browse/SLING-7049 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Critical > Fix For: Sling Models Impl 1.4.4 > > > Only the first ModelExporter is actually checked if it can satisfy an export > request. If it does not match by name or type, an exception is immediately > thrown rather than checking other ModelExporters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7049) MissingExporterException thrown when the desired ModelExporter is not the first in the list
Justin Edelson created SLING-7049: - Summary: MissingExporterException thrown when the desired ModelExporter is not the first in the list Key: SLING-7049 URL: https://issues.apache.org/jira/browse/SLING-7049 Project: Sling Issue Type: Bug Components: Extensions Reporter: Justin Edelson Assignee: Justin Edelson Priority: Critical Fix For: Sling Models Impl 1.4.4 Only the first ModelExporter is actually checked if it can satisfy an export request. If it does not match by name or type, an exception is immediately thrown rather than checking other ModelExporters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7028) Commons Metrics Web Console outputs all Histograms as durations
[ https://issues.apache.org/jira/browse/SLING-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7028. --- Resolution: Fixed Assignee: Justin Edelson implemented in r1804333 > Commons Metrics Web Console outputs all Histograms as durations > --- > > Key: SLING-7028 > URL: https://issues.apache.org/jira/browse/SLING-7028 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics 1.2.2 >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: commons metrics 1.2.4 > > Attachments: SLING-7028.diff > > > For the purpose of the Web Console plugin, Histograms from the > MetricsRegistry are assumed to be durations and are output as if the values > are in milliseconds. This is not a safe assumption and in fact would > generally not be the case since durations would be better tracked through the > Timer type (which uses a Histogram internally) not by direct use of the > Histogram type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7031) Write (subset) of metrics to log file on a recurring basis
[ https://issues.apache.org/jira/browse/SLING-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-7031. --- Resolution: Fixed Assignee: Justin Edelson implemented in r1804333 > Write (subset) of metrics to log file on a recurring basis > -- > > Key: SLING-7031 > URL: https://issues.apache.org/jira/browse/SLING-7031 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: commons metrics 1.2.4 > > Attachments: SLING-7031.diff > > > For ease of visibility and extraction, we should provide a way to output a > set of metrics to the log file on a recurring basis. Most of this > functionality is already provided by the Metrics library, we can just wrap it > in a nice OSGi config-based component. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7028) Commons Metrics Web Console outputs all Histograms as durations
[ https://issues.apache.org/jira/browse/SLING-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7028: -- Fix Version/s: commons metrics 1.2.4 > Commons Metrics Web Console outputs all Histograms as durations > --- > > Key: SLING-7028 > URL: https://issues.apache.org/jira/browse/SLING-7028 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics 1.2.2 >Reporter: Justin Edelson > Fix For: commons metrics 1.2.4 > > Attachments: SLING-7028.diff > > > For the purpose of the Web Console plugin, Histograms from the > MetricsRegistry are assumed to be durations and are output as if the values > are in milliseconds. This is not a safe assumption and in fact would > generally not be the case since durations would be better tracked through the > Timer type (which uses a Histogram internally) not by direct use of the > Histogram type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7031) Write (subset) of metrics to log file on a recurring basis
[ https://issues.apache.org/jira/browse/SLING-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7031: -- Fix Version/s: commons metrics 1.2.4 > Write (subset) of metrics to log file on a recurring basis > -- > > Key: SLING-7031 > URL: https://issues.apache.org/jira/browse/SLING-7031 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Justin Edelson > Fix For: commons metrics 1.2.4 > > Attachments: SLING-7031.diff > > > For ease of visibility and extraction, we should provide a way to output a > set of metrics to the log file on a recurring basis. Most of this > functionality is already provided by the Metrics library, we can just wrap it > in a nice OSGi config-based component. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7031) Write (subset) of metrics to log file on a recurring basis
[ https://issues.apache.org/jira/browse/SLING-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7031: -- Attachment: SLING-7031.diff proposed change > Write (subset) of metrics to log file on a recurring basis > -- > > Key: SLING-7031 > URL: https://issues.apache.org/jira/browse/SLING-7031 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Justin Edelson > Attachments: SLING-7031.diff > > > For ease of visibility and extraction, we should provide a way to output a > set of metrics to the log file on a recurring basis. Most of this > functionality is already provided by the Metrics library, we can just wrap it > in a nice OSGi config-based component. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7031) Write (subset) of metrics to log file on a recurring basis
Justin Edelson created SLING-7031: - Summary: Write (subset) of metrics to log file on a recurring basis Key: SLING-7031 URL: https://issues.apache.org/jira/browse/SLING-7031 Project: Sling Issue Type: Improvement Components: Commons Reporter: Justin Edelson For ease of visibility and extraction, we should provide a way to output a set of metrics to the log file on a recurring basis. Most of this functionality is already provided by the Metrics library, we can just wrap it in a nice OSGi config-based component. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7028) Commons Metrics Web Console outputs all Histograms as durations
[ https://issues.apache.org/jira/browse/SLING-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-7028: -- Attachment: SLING-7028.diff proposed change > Commons Metrics Web Console outputs all Histograms as durations > --- > > Key: SLING-7028 > URL: https://issues.apache.org/jira/browse/SLING-7028 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics 1.2.2 >Reporter: Justin Edelson > Attachments: SLING-7028.diff > > > For the purpose of the Web Console plugin, Histograms from the > MetricsRegistry are assumed to be durations and are output as if the values > are in milliseconds. This is not a safe assumption and in fact would > generally not be the case since durations would be better tracked through the > Timer type (which uses a Histogram internally) not by direct use of the > Histogram type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7028) Commons Metrics Web Console outputs all Histograms as durations
Justin Edelson created SLING-7028: - Summary: Commons Metrics Web Console outputs all Histograms as durations Key: SLING-7028 URL: https://issues.apache.org/jira/browse/SLING-7028 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Metrics 1.2.2 Reporter: Justin Edelson For the purpose of the Web Console plugin, Histograms from the MetricsRegistry are assumed to be durations and are output as if the values are in milliseconds. This is not a safe assumption and in fact would generally not be the case since durations would be better tracked through the Timer type (which uses a Histogram internally) not by direct use of the Histogram type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7015) Add Utility Method to ModelFactory to help proper model creation from child resources in a request context
[
https://issues.apache.org/jira/browse/SLING-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-7015.
---
Resolution: Fixed
Assignee: Justin Edelson
Implemented in r1802505
> Add Utility Method to ModelFactory to help proper model creation from child
> resources in a request context
> --
>
> Key: SLING-7015
> URL: https://issues.apache.org/jira/browse/SLING-7015
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.4.4, Sling Models API 1.3.6
>
> Attachments: SLING-7015.diff
>
>
> At present, it is somewhat complex to generate Sling Model objects (or
> really, any adapter class) from an included resource. This is especially true
> when the adaptable is the SlingHttpServletRequest object.
> There are a few different cases which are problematic:
> 1. When you want to inject an object adapted from a child resource where the
> adaptable is a request object (i.e. you want to override the
> request.getResource() to the child resource)
> 2. When you want to inject an object adapted from a child resource
> (regardless of the adaptable) and the model class depends upon the Script
> Bindings.
> In the first case, this currently requires creating a wrapper request. The
> second case is more complex to solve as (to do it correctly) requires
> re-invoking all of the BindingsValuesProviders (which entails creating a fake
> ScriptEngine).
> To solve both issues, I would like to add a new method named
> {{getModelFromWrappedRequest}}. Parameters would be
> {{SlingHttpServletRequest}}, {{Resource}}, {{Class}}.
> This method would create a wrapped request with the passed resource, set the
> bindings to a new object and reinvoke the BVPs.
> Patch to follow, but I wanted to file this early to get any feedback.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7017) Make it possible to mount packages at different paths
[
https://issues.apache.org/jira/browse/SLING-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094729#comment-16094729
]
Justin Edelson commented on SLING-7017:
---
[~simone.tripodi] I've never done this myself (and, to be honest, I'm not
really familiar with the SCD code) but what I would expect is that the target
prefix is either determined on the target system (e.g. based on a user ->
tenant mapping) or passed outside of the package as part of the HTTP request.
In that case, I'd suggest doing the mapping on installation on using
{{ImportOptions}}.
> Make it possible to mount packages at different paths
> -
>
> Key: SLING-7017
> URL: https://issues.apache.org/jira/browse/SLING-7017
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Simone Tripodi
> Fix For: Content Distribution Core 0.2.10
>
>
> In some scenarios (e.g. multi tenant instances) it may be useful to be able
> to mount packages at configurable paths.
> For example mounting a package for _/foo/bar/_ at _/tenant1/foo/bar_; we can
> leverage FileVault [configuration
> options|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/ExportOptions.java#L126]
> to support that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7017) Make it possible to mount packages at different paths
[
https://issues.apache.org/jira/browse/SLING-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094638#comment-16094638
]
Justin Edelson commented on SLING-7017:
---
[~teofili] [~simone.tripodi] To be clear, the concept here is that you have
{{/etc/my/data}} on the source system and want to copy it to the target system
as {{/custom/etc/my/data}}. Is that correct? And such prefixing would be done
per-copy, e.g. at some point later in time you might want to take
{{/etc/myother/data}} and transfer it to the target system as
{{/custom2/etc/myother/data}}.
> Make it possible to mount packages at different paths
> -
>
> Key: SLING-7017
> URL: https://issues.apache.org/jira/browse/SLING-7017
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Simone Tripodi
> Fix For: Content Distribution Core 0.2.10
>
>
> In some scenarios (e.g. multi tenant instances) it may be useful to be able
> to mount packages at configurable paths.
> For example mounting a package for _/foo/bar/_ at _/tenant1/foo/bar_; we can
> leverage FileVault [configuration
> options|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/ExportOptions.java#L126]
> to support that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7015) Add Utility Method to ModelFactory to help proper model creation from child resources in a request context
[
https://issues.apache.org/jira/browse/SLING-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-7015:
--
Fix Version/s: Sling Models Impl 1.4.4
Sling Models API 1.3.6
> Add Utility Method to ModelFactory to help proper model creation from child
> resources in a request context
> --
>
> Key: SLING-7015
> URL: https://issues.apache.org/jira/browse/SLING-7015
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models Impl 1.4.4, Sling Models API 1.3.6
>
> Attachments: SLING-7015.diff
>
>
> At present, it is somewhat complex to generate Sling Model objects (or
> really, any adapter class) from an included resource. This is especially true
> when the adaptable is the SlingHttpServletRequest object.
> There are a few different cases which are problematic:
> 1. When you want to inject an object adapted from a child resource where the
> adaptable is a request object (i.e. you want to override the
> request.getResource() to the child resource)
> 2. When you want to inject an object adapted from a child resource
> (regardless of the adaptable) and the model class depends upon the Script
> Bindings.
> In the first case, this currently requires creating a wrapper request. The
> second case is more complex to solve as (to do it correctly) requires
> re-invoking all of the BindingsValuesProviders (which entails creating a fake
> ScriptEngine).
> To solve both issues, I would like to add a new method named
> {{getModelFromWrappedRequest}}. Parameters would be
> {{SlingHttpServletRequest}}, {{Resource}}, {{Class}}.
> This method would create a wrapped request with the passed resource, set the
> bindings to a new object and reinvoke the BVPs.
> Patch to follow, but I wanted to file this early to get any feedback.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
