[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces

[Justin Edelson (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-10840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

[RESULT] [VOTE] Release Apache Sling Models Impl Version 1.4.14

[Justin Edelson]

Hi,
The vote has passed with the following result :
+1 (binding): Radu Cotescu, Karl Pauls, Carsten Ziegeler, Nicolas
Peltier, Dan Klco

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

[VOTE] Release Apache Sling Models Impl Version 1.4.14

[Justin Edelson]

Hi,

We solved 3 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12346492

There are still some outstanding issues:
https://issues.apache.org/jira/browse/SLING/fixforversion/12349142

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2348

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob_plain;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2348 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

[jira] [Updated] (SLING-9674) Allow SlingHttpServletRequest based adaptations for ChildResourceInjector

[Justin Edelson (Jira)]

 [ 
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

[Justin Edelson (Jira)]

 [ 
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

[Justin Edelson (Jira)]

 [ 
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(D

[jira] [Updated] (SLING-8923) Jackson Sling Model Exporter for application/xml needs correct character encoding

[Justin Edelson (Jira)]

 [ 
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

[Justin Edelson (Jira)]

 [ 
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

[Justin Edelson (Jira)]

 [ 
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

[Justin Edelson (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Re: [Discuss] Thoughts about renaming the 'master' branches to 'main'?

[Justin Edelson]

+1

Regardless of the members@ discussion, we should do this. Although perhaps
this should be done as a formal vote.

I'm assuming this is something that can be relatively easily scripted, but
if does require manual work, I'd be happy to help.

On Sun, Jun 14, 2020 at 4:38 AM  wrote:

> Hi all,
>
> It seems that the members@ discussion is moving in this direction now as
> well...
>
> Best,
>
> David
>
> On Sat, 13 Jun 2020 at 09:57,  wrote:
>
> > Hi all,
> >
> > What would others think about renaming the 'master' branches to 'main' in
> > Sling?
> >
> > I know that there is discussion going on at members@ where people think
> > that 'master' on its own is not problematic, with suggestions to document
> > this somewhere. This could be an alternative.
> > However I personally think that it would be preferable to avoid
> > any potential problematic language in our codebases. I think renaming the
> > 'master' branch to the 'main' branch would solve that.
> >
> > I know Sling has a lot of git repositories, and if we decide to agree on
> > this I would be happy to help progressing this.
> >
> > Kind regards,
> >
> > David Bosschaert
> >
>

Re: Sonar complains about no assertion when using Awaitility

[Justin Edelson]

On Mon, Mar 30, 2020 at 5:58 AM Robert Munteanu  wrote:

> Hi Christian,
>
> On Mon, 2020-03-30 at 11:38 +0200, Christian Schneider wrote:
> > In some of our tests we use Awaitility as the expected result will
> > happen
> > asynchronously.
> > The code looks like:
> >
> > await().until(checker::isAvailable);
> >
> >
> > This actually is like an assertion but sonar then complains that the
> > test
> > does not assert anything.
> >
> > Is there a way to let sonar know that using an await is also a good
> > assertion?
>

Yes. See https://jira.sonarsource.com/browse/SONARJAVA-2927.

Cheers,
Justin


>
> I am not aware of any specific way of doing this. Maybe a posting on
>
>   https://community.sonarsource.com/c/help/sc
>
> would get you some help?
>
> Thanks,
> Robert
>
> >
> > See
> >
> https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-distribution-journal&issues=AWvhm55N9kO6n_b9qo1U&open=AWvhm55N9kO6n_b9qo1U
> >
> >
> > --
>
>

[jira] [Commented] (SLING-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException

[Justin Edelson (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Re: Why get rid of the rewriter?

[Justin Edelson]

+1 great summary.

On Tue, Sep 10, 2019 at 12:37 PM Stefan Seifert 
wrote:

> i try to write a first summary:
>
> - we have good use cases for a rewriter in general, but are unhappy with
> the current implementation and it's way of configuration. the whole thing
> is a bit "alien" to the other parts of sling.
>
> - a new rewriter implementation should be performant and with up-to-date
> support for modern HTML. ideally something like SAX for HTML (not
> XML/XHTML). this would not cover other use cases producing something other
> than HTML, though. perhaps there are libraries out there that can be built
> upon. should also provide modular support, e.g. rewriting only the output
> of a single component or text fragment. maybe someone can come up with a
> proposal.
>
> - we have to keep the old rewriter for backward compatibility because it
> was used a lot in the past, but do not plan to maintain it further and
> probably will remove it from the sling starter as well. mark it as
> deprecated or contrib.
>
> - we do no longer want to use the rewriter for link validation and
> externalization, but support this as aspect in another, more appropriate
> way (with some basic support or hooks/SPIs from Sling itself, the rest is
> more up to upstream layers). we have currently only very rough ideas here,
> a proposal needs to be draftet as well.
>
> stefan
>
> >-Original Message-
> >From: Jason E Bailey [mailto:jason.bai...@24601.org]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: dev@sling.apache.org
> >Subject: Re: Why get rid of the rewriter?
> >
> >I'm positive towards the concept of the rewriter, a utility that provides
> >centralized features that addresses cross-cutting concerns with user
> >generated content.
> >
> >I'm not a fan of the current implementation of the rewriter.
> >
> >1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do
> >with XML. There is no concept of namespace in HTML now. There is no self
> >closing tag. There may not be an end tag. There is a concept of implied
> >parent tags.
> >
> >2. TagSoup, which is currently used to parse the HTML, requires  fully
> >cached content and will attempt to validate the content and add to it,
> >where appropriate. Which isn't necessary.
> >
> >3. The Rewriter requires the pipeline configuration to be in a specific
> >place with a specific name which is inflexible and contrary to other tools
> >we use.
> >
> >
> >The point being that I would prefer to have the rewriter implementation
> >deprecated in favor of a more up to date solution then having the concept
> >of the rewriter deprecated.
> >
> >
> >
> >--
> >Jason
> >
> >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:
> >> As was pointed out before the rewriter is used in a lot of projects for
> >> other things than rewriting links (in our case we use it a lot to inject
> >> legal disclaimers or content fragment models)
> >>
> >> The bigger problem however is that it assumes hml == xml and hence can
> >not
> >> deal with attributes with no value
> >>
> >> Ruben
> >>
> >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz
> >
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> >> > > ...Can anyone summarize why we are getting rid of it?...
> >> >
> >> > I'm not sure if we need to "get rid" of that module, even if some
> >> > portion of Sling users stops using it.
> >> >
> >> > The proposal at [1] says the rewriter should be "deprecated and no
> >> > longer used", which is apparently what was discussed at the adaptTo
> >> > round table or hackathon.
> >> >
> >> > If people still find the module useful I think it''s fine to move it
> >> > to "contrib" status instead of deprecating. As long as there's a
> >> > reasonable expectation that the module will be maintained I think
> >> > that's a realistic status, but our guarantees are weak for contrib
> >> > modules so there's no pressure.
> >> >
> >> > And if other modules provide better ways of doing similar things, link
> >> > to them from the rewriter's docs.
> >> >
> >> > -Bertrand
> >> >
> >> > [1]
> >> >
> >
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3
> >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >> >
> >>
> >>
> >> --
> >> thank you
> >>
> >> Ruben Reusser
> >> CTO, headwire.com, Inc
> >>
>
>
>

Re: Why get rid of the rewriter?

[Justin Edelson]

... for urls, not for markup in general.

On Tue, Sep 10, 2019 at 10:35 AM Konrad Windszus  wrote:

> The new url rewriter SPI will be perfectly supporting AOP.
> Konrad
>
> > Am 10.09.2019 um 16:09 schrieb Justin Edelson  >:
> >
> > I see that the same assumptions are being made here that were made a year
> > ago when this was discussed. I would strongly caution against assuming
> that
> > the "aspect developer" and the "script developer" are the same person or
> > even work for the same organization. The value of AOP programming styles,
> > such as that used by the rewriter, is that these roles do not need to be
> > aware of each other.
> >
> > Agree 100% that AEM should change how link rewriting is done. But that's
> > not really Sling's concern per se with respect to the rewriter. Sling's
> > concern should be (1) whether or not AOP has value in a component-based
> > system (I think the answer here is a clear "yes") and (2) what the right
> > programming model is to support AOP. To Reuben's point, it is certainly
> > possible that SAX is the wrong programming model (I personally don't
> agree,
> > but I have a very soft spot for SAX). But the answer to that IMO is to
> > define a better programming model, not jump to the conclusion that AOP
> > doesn't have value.
> >
> > Cheers,
> > Justin
> >
> > On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
> > wrote:
> >
> >> The rewriter is a generic solution (for xhtml) which works independent
> >> of the scripting engine used. However, with engines like HTL which knows
> >> about HTML and has all the contextual information about the html
> >> elements, it is way more efficient to do any transformation whether its
> >> link transformations or anything else already during that step.
> >> Reparsing with a rather expensive XML processing pipeline is flexible
> >> but also slows down the rendering unnecessary.
> >>
> >> Carsten
> >>
> >>> Am 10.09.2019 um 14:56 schrieb Ruben Reusser:
> >>> As was pointed out before the rewriter is used in a lot of projects for
> >>> other things than rewriting links (in our case we use it a lot to
> inject
> >>> legal disclaimers or content fragment models)
> >>>
> >>> The bigger problem however is that it assumes hml == xml and hence can
> >> not
> >>> deal with attributes with no value
> >>>
> >>> Ruben
> >>>
> >>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz <
> >> bdelacre...@apache.org>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey 
> wrote:
> >>>>> ...Can anyone summarize why we are getting rid of it?...
> >>>>
> >>>> I'm not sure if we need to "get rid" of that module, even if some
> >>>> portion of Sling users stops using it.
> >>>>
> >>>> The proposal at [1] says the rewriter should be "deprecated and no
> >>>> longer used", which is apparently what was discussed at the adaptTo
> >>>> round table or hackathon.
> >>>>
> >>>> If people still find the module useful I think it''s fine to move it
> >>>> to "contrib" status instead of deprecating. As long as there's a
> >>>> reasonable expectation that the module will be maintained I think
> >>>> that's a realistic status, but our guarantees are weak for contrib
> >>>> modules so there's no pressure.
> >>>>
> >>>> And if other modules provide better ways of doing similar things, link
> >>>> to them from the rewriter's docs.
> >>>>
> >>>> -Bertrand
> >>>>
> >>>> [1]
> >>>>
> >>
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >>>>
> >>>
> >>>
> >>
> >> --
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
>
>

Re: Why get rid of the rewriter?

[Justin Edelson]

I see that the same assumptions are being made here that were made a year
ago when this was discussed. I would strongly caution against assuming that
the "aspect developer" and the "script developer" are the same person or
even work for the same organization. The value of AOP programming styles,
such as that used by the rewriter, is that these roles do not need to be
aware of each other.

Agree 100% that AEM should change how link rewriting is done. But that's
not really Sling's concern per se with respect to the rewriter. Sling's
concern should be (1) whether or not AOP has value in a component-based
system (I think the answer here is a clear "yes") and (2) what the right
programming model is to support AOP. To Reuben's point, it is certainly
possible that SAX is the wrong programming model (I personally don't agree,
but I have a very soft spot for SAX). But the answer to that IMO is to
define a better programming model, not jump to the conclusion that AOP
doesn't have value.

Cheers,
Justin

On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
wrote:

> The rewriter is a generic solution (for xhtml) which works independent
> of the scripting engine used. However, with engines like HTL which knows
> about HTML and has all the contextual information about the html
> elements, it is way more efficient to do any transformation whether its
> link transformations or anything else already during that step.
> Reparsing with a rather expensive XML processing pipeline is flexible
> but also slows down the rendering unnecessary.
>
> Carsten
>
> Am 10.09.2019 um 14:56 schrieb Ruben Reusser:
> > As was pointed out before the rewriter is used in a lot of projects for
> > other things than rewriting links (in our case we use it a lot to inject
> > legal disclaimers or content fragment models)
> >
> > The bigger problem however is that it assumes hml == xml and hence can
> not
> > deal with attributes with no value
> >
> > Ruben
> >
> > On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz <
> bdelacre...@apache.org>
> > wrote:
> >
> >> Hi,
> >>
> >> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> >>> ...Can anyone summarize why we are getting rid of it?...
> >>
> >> I'm not sure if we need to "get rid" of that module, even if some
> >> portion of Sling users stops using it.
> >>
> >> The proposal at [1] says the rewriter should be "deprecated and no
> >> longer used", which is apparently what was discussed at the adaptTo
> >> round table or hackathon.
> >>
> >> If people still find the module useful I think it''s fine to move it
> >> to "contrib" status instead of deprecating. As long as there's a
> >> reasonable expectation that the module will be maintained I think
> >> that's a realistic status, but our guarantees are weak for contrib
> >> modules so there's no pressure.
> >>
> >> And if other modules provide better ways of doing similar things, link
> >> to them from the rewriter's docs.
> >>
> >> -Bertrand
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >>
> >
> >
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [DISCUSS] Feature Files I/O long-therm proposal: improving the processing pipeline

[Justin Edelson]

Hi Simo,
Take this with several grains of salt as I don't know the internals of the
feature processing, but just looking at your email from a generic "how do I
process a JSON file" it still seems inefficient.

Ideally, IMO, the substitution would be done as a filter applied to the
stream of parser events. That way the entire String is not held in memory
-- only the parsed DOM. I suspect it is also "safer" in the sense that you
can more tightly control the context in which interpolation occurs (for
example, interpolation should be allowed in string values, but not keys);
the flip side is that it also is more restrictive, i.e. supporting
interpolation of non-String values would be non-trivial (then again, doing
this would make the original document invalid JSON so I'm not sure this is
a real use case). I would suggest taking a look at Jackson's
JsonParserDelegate.

Regards,
Justin

On Mon, Nov 12, 2018 at 2:46 PM Simone Tripodi 
wrote:

> Hi all mates,
>
> during the last couple of months the work we've been doing on Feature
> files processing is HUGE, so the iterations to refine the pipeline
> process introduced some "overhead" operations we can improve, what we
> currently do is:
>
>  * the pre processor starts by reading the whole file to memory,
> storing it in a String reference;
>  * parse the JSON file to create the javax.json DOM and check the `id`
> property is missing, adding it if necessary and then serializing it to
> string again:
>  * JSON Schema validation takes the string as input, creates the
> Jackson DOM to validate it against the defined schema;
>  * if schema validation is OK, the Substitution takes the JSON string
> as input to interpolate variables, which creates a new JSON string
> representation;
>  * the JS Min takes the JSON string representation and converts it to
> a new JSON string representation where useless stuff are removed;
>  * at that point, the JSON Feature reader takes the final string and
> creates a javax.json DOM once again to map it to a Feature instance.
>
> My proposal is improving a little our pipeline in order to speed up
> the JSON processing in that way:
>
>  * the JS Min starts by reading the whole file to memory, storing it
> in a String reference;
>  * the Substitution takes the JSON string as input to interpolate
> variables, which creates a new JSON string representation;
>  * a Jackson DOM will be created in order to check the `id` property
> is missing, adding it if necessary;
>  * the Jackson DOM will be validated against the defined schema;
>  * the Jackson DOM will be mapped to a Feature instance.
>
> WDYT?
>
> Many thanks in advance!
> ~Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>

Re: Sling 12 themes

[Justin Edelson]

As long as this doesn't require explicit action by the script developer, I
could see this working. But that's not how, IIUC, HTL works. Rewriting has
to work even if the script developer didn't anticipate that a particular
element/attribute/text content needs rewriting.

On Wed, Oct 24, 2018 at 9:21 AM Konrad Windszus  wrote:

> IMHO modifying the script would not even be necessary in the best case for
> HTL as the HTL context would lead to automatically invoking a certain HTL
> plugin which allows to modify the link itself.
> So I totally agree we need aspect-oriented programming here (i.e. only do
> it once in code instead of hundreds of times explicitly in HTL).
>
> Konrad
>
> > On 24. Oct 2018, at 15:16, Justin Edelson 
> wrote:
> >
> > As I was trying to say, this assumes that modifying the script (or the
> > model or even the content) is an option. In many cases it isn't. How
> often,
> > I don't know, but I'm sure it is more than 5% (although I guess it
> depends
> > on how this is measured).
> >
> >
> >
> > On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler 
> > wrote:
> >
> >> In addition to that, it seems to me wrong to write a script which
> >> creates an output (being that html or json or whatever) and then you
> >> need an additional mechanism to modify this output. Wouldn't it be much
> >> better to create the correct output in the first place?
> >>
> >> So I think there are three places where you potentially do the
> >> modifications:
> >> 1. You modify your model which is the input to your script
> >> 2. You do it in a script
> >> 3. You reparse the output of your script and then modify it
> >>
> >> Maybe there are still use cases for 3 and then the rewriter is a good
> >> tool for it. But I sincerely hope that 95% of the use cases can already
> >> be solved with 1 or 2 - and thats were we should focus on.
> >>
> >> Carsten
> >>
> >> Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
> >>> As usual we're giving ourselves and our users a hard time as we want to
> >>> support all the possible options in the world instead of focusing on
> one
> >>> or two options and make them as good as possible. I don't care what the
> >>> solution is, but supporting 5 different ways of creating html is imho
> >>> totally wrong and fragmenting our user base. Whether it is HTL or not
> is
> >>> a different question.
> >>>
> >>> The current architecture of the rewriter is not optimal as it needs to
> >>> reparse the output which is expensive. The servlet API has no support
> >>> for streaming text based outputs so as long as we have that API in
> >>> between we have a bad solution. Building on top of something where we
> >>> know that its not a good thing, seems wrong to me as well.
> >>>
> >>> Carsten
> >>>
> >>> Am 24.10.2018 um 01:45 schrieb Justin Edelson:
> >>>> Just my 2cents as a fan of the rewriter.
> >>>>
> >>>> The problem with saying "just use HTL" (aside from what Jason said) is
> >>>> that
> >>>> it enables a separation of concerns. To say "just use HTL" implies
> that
> >>>> there is a single developer (or organization) who "owns" all the code
> >>>> responsible for generating HTML and has the authority to change them
> to
> >>>> suit emerging requirements (which today can be done universally via a
> >>>> rewriter transformer). But this isn't really the case a lot of the
> >>>> time --
> >>>> there's multiple "owners" who are each contributing components and
> >>>> applying
> >>>> rewriter-style logic across those owners is complicated (if not
> >>>> impossible)
> >>>> to manage. This also assumes that HTL (or any other scripting language
> >>>> generating HTML) is actually being used properly -- in my experience,
> >>>> there's plenty of "raw" HTML being output from string properties and
> you
> >>>> need a way to rewrite that too.
> >>>>
> >>>> I really don't think all the rewriter use cases boil down to link
> >>>> rewriting.
> >>>>
> >>
> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> >>>> is
> >>>> a real-world examp

Re: Sling 12 themes

[Justin Edelson]

These are orthogonal questions IMO.

We can say that the one true way of generating HTML is HTL (or Thymeleaf or
JSP or whatever). But that doesn't obviate the need to modify the *output*
of the HTL script using some kind of AOP model (which is really what the
rewriter is).

On Wed, Oct 24, 2018 at 12:55 AM Carsten Ziegeler 
wrote:

> As usual we're giving ourselves and our users a hard time as we want to
> support all the possible options in the world instead of focusing on one
> or two options and make them as good as possible. I don't care what the
> solution is, but supporting 5 different ways of creating html is imho
> totally wrong and fragmenting our user base. Whether it is HTL or not is
> a different question.
>
> The current architecture of the rewriter is not optimal as it needs to
> reparse the output which is expensive. The servlet API has no support
> for streaming text based outputs so as long as we have that API in
> between we have a bad solution. Building on top of something where we
> know that its not a good thing, seems wrong to me as well.
>
> Carsten
>
> Am 24.10.2018 um 01:45 schrieb Justin Edelson:
> > Just my 2cents as a fan of the rewriter.
> >
> > The problem with saying "just use HTL" (aside from what Jason said) is
> that
> > it enables a separation of concerns. To say "just use HTL" implies that
> > there is a single developer (or organization) who "owns" all the code
> > responsible for generating HTML and has the authority to change them to
> > suit emerging requirements (which today can be done universally via a
> > rewriter transformer). But this isn't really the case a lot of the time
> --
> > there's multiple "owners" who are each contributing components and
> applying
> > rewriter-style logic across those owners is complicated (if not
> impossible)
> > to manage. This also assumes that HTL (or any other scripting language
> > generating HTML) is actually being used properly -- in my experience,
> > there's plenty of "raw" HTML being output from string properties and you
> > need a way to rewrite that too.
> >
> > I really don't think all the rewriter use cases boil down to link
> > rewriting.
> > https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> is
> > a real-world example. But I'll need to dig through my project archive to
> > come up with good examples.
> >
> > Personally, I'd suggest that HTL could be more tightly coupled to the
> > rewriter and rather than emit a character stream which gets parsed into a
> > SAX stream, the rewriter could be reimagined as a more generic event
> stream
> > processing chain and HTL is directly providing HTML events into this
> chain
> > (and given that HTL knows the output context, it could indicate as part
> of
> > the event that the text content should be parsed in the case of embedded
> > HTML). The output of JSPs could be parsed as is the current state. JSON
> > could be handled through different event types.
> >
> >
> >
> >
> > On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
> > wrote:
> >
> >> The rewriter as it is today is pretty heavy and adds a lot of overhead
> >> to request processing. Especially as the output needs to be created
> >> first and then parsed again.
> >>
> >> There is nothing wrong with enhancing it in general. But for example if
> >> you use HTL we could provide much better and faster support ootb. I
> >> think if JSON is rendered we could do something at JSON creation time
> >> instead of needing to reparse it again as well.
> >>
> >> I agree that it gets pretty hard to come up with a solution that targets
> >> all output formats at once, even with the rewriter concept it's not that
> >> easy. But maybe we can come up with different implementations that share
> >> a single configuration. For example for link rewriting that should be
> >> possible.
> >>
> >>
> >> Carsten
> >>
> >> Am 23.10.2018 um 21:43 schrieb Daniel Klco:
> >>> I don't see how we could support multiple templating languages without
> >> some
> >>> sort of rewriter support.
> >>>
> >>> Part of the problem IMO is that the Rewriter library muddles the
> >> rewriting
> >>> concept with an expectation of specifically dealing with (X)HTML.
> Instead
> >>> it would make more sense to me to have a content agnostic library for
> >>> performing content rewriting and

Re: Sling 12 themes

[Justin Edelson]

As I was trying to say, this assumes that modifying the script (or the
model or even the content) is an option. In many cases it isn't. How often,
I don't know, but I'm sure it is more than 5% (although I guess it depends
on how this is measured).



On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler 
wrote:

> In addition to that, it seems to me wrong to write a script which
> creates an output (being that html or json or whatever) and then you
> need an additional mechanism to modify this output. Wouldn't it be much
> better to create the correct output in the first place?
>
> So I think there are three places where you potentially do the
> modifications:
> 1. You modify your model which is the input to your script
> 2. You do it in a script
> 3. You reparse the output of your script and then modify it
>
> Maybe there are still use cases for 3 and then the rewriter is a good
> tool for it. But I sincerely hope that 95% of the use cases can already
> be solved with 1 or 2 - and thats were we should focus on.
>
> Carsten
>
> Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
> > As usual we're giving ourselves and our users a hard time as we want to
> > support all the possible options in the world instead of focusing on one
> > or two options and make them as good as possible. I don't care what the
> > solution is, but supporting 5 different ways of creating html is imho
> > totally wrong and fragmenting our user base. Whether it is HTL or not is
> > a different question.
> >
> > The current architecture of the rewriter is not optimal as it needs to
> > reparse the output which is expensive. The servlet API has no support
> > for streaming text based outputs so as long as we have that API in
> > between we have a bad solution. Building on top of something where we
> > know that its not a good thing, seems wrong to me as well.
> >
> > Carsten
> >
> > Am 24.10.2018 um 01:45 schrieb Justin Edelson:
> >> Just my 2cents as a fan of the rewriter.
> >>
> >> The problem with saying "just use HTL" (aside from what Jason said) is
> >> that
> >> it enables a separation of concerns. To say "just use HTL" implies that
> >> there is a single developer (or organization) who "owns" all the code
> >> responsible for generating HTML and has the authority to change them to
> >> suit emerging requirements (which today can be done universally via a
> >> rewriter transformer). But this isn't really the case a lot of the
> >> time --
> >> there's multiple "owners" who are each contributing components and
> >> applying
> >> rewriter-style logic across those owners is complicated (if not
> >> impossible)
> >> to manage. This also assumes that HTL (or any other scripting language
> >> generating HTML) is actually being used properly -- in my experience,
> >> there's plenty of "raw" HTML being output from string properties and you
> >> need a way to rewrite that too.
> >>
> >> I really don't think all the rewriter use cases boil down to link
> >> rewriting.
> >>
> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> >> is
> >> a real-world example. But I'll need to dig through my project archive to
> >> come up with good examples.
> >>
> >> Personally, I'd suggest that HTL could be more tightly coupled to the
> >> rewriter and rather than emit a character stream which gets parsed into
> a
> >> SAX stream, the rewriter could be reimagined as a more generic event
> >> stream
> >> processing chain and HTL is directly providing HTML events into this
> >> chain
> >> (and given that HTL knows the output context, it could indicate as
> >> part of
> >> the event that the text content should be parsed in the case of embedded
> >> HTML). The output of JSPs could be parsed as is the current state. JSON
> >> could be handled through different event types.
> >>
> >>
> >>
> >>
> >> On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
> >> wrote:
> >>
> >>> The rewriter as it is today is pretty heavy and adds a lot of overhead
> >>> to request processing. Especially as the output needs to be created
> >>> first and then parsed again.
> >>>
> >>> There is nothing wrong with enhancing it in general. But for example if
> >>> you use HTL we could provide much better and faster support ootb. I
> >>> t

Re: Sling 12 themes

[Justin Edelson]

Just my 2cents as a fan of the rewriter.

The problem with saying "just use HTL" (aside from what Jason said) is that
it enables a separation of concerns. To say "just use HTL" implies that
there is a single developer (or organization) who "owns" all the code
responsible for generating HTML and has the authority to change them to
suit emerging requirements (which today can be done universally via a
rewriter transformer). But this isn't really the case a lot of the time --
there's multiple "owners" who are each contributing components and applying
rewriter-style logic across those owners is complicated (if not impossible)
to manage. This also assumes that HTL (or any other scripting language
generating HTML) is actually being used properly -- in my experience,
there's plenty of "raw" HTML being output from string properties and you
need a way to rewrite that too.

I really don't think all the rewriter use cases boil down to link
rewriting.
https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13 is
a real-world example. But I'll need to dig through my project archive to
come up with good examples.

Personally, I'd suggest that HTL could be more tightly coupled to the
rewriter and rather than emit a character stream which gets parsed into a
SAX stream, the rewriter could be reimagined as a more generic event stream
processing chain and HTL is directly providing HTML events into this chain
(and given that HTL knows the output context, it could indicate as part of
the event that the text content should be parsed in the case of embedded
HTML). The output of JSPs could be parsed as is the current state. JSON
could be handled through different event types.




On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
wrote:

> The rewriter as it is today is pretty heavy and adds a lot of overhead
> to request processing. Especially as the output needs to be created
> first and then parsed again.
>
> There is nothing wrong with enhancing it in general. But for example if
> you use HTL we could provide much better and faster support ootb. I
> think if JSON is rendered we could do something at JSON creation time
> instead of needing to reparse it again as well.
>
> I agree that it gets pretty hard to come up with a solution that targets
> all output formats at once, even with the rewriter concept it's not that
> easy. But maybe we can come up with different implementations that share
> a single configuration. For example for link rewriting that should be
> possible.
>
>
> Carsten
>
> Am 23.10.2018 um 21:43 schrieb Daniel Klco:
> > I don't see how we could support multiple templating languages without
> some
> > sort of rewriter support.
> >
> > Part of the problem IMO is that the Rewriter library muddles the
> rewriting
> > concept with an expectation of specifically dealing with (X)HTML. Instead
> > it would make more sense to me to have a content agnostic library for
> > performing content rewriting and providing a HTML, XML and (possibly)
> JSON
> > implementation.
> >
> > On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey  wrote:
> >
> >>
> >> On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote:
> >>> I would  rather prefer to get rid of a server side postprocessing like
> >>> the rewriter. For HTL I agree with Carsten, we should probably look
> into
> >>> a generic link rewriting mechanism which allows for custom rewriting
> >>> with a nice HTL plugin. Much less overhead than a Cocoon pipeline which
> >>> needs to deserialize and then serialize again...
> >>> Would be interesting to get forward in that regard with Sling 12.
> >>
> >> There is a real world need for html post processing that is not
> dependent
> >> on HTL. The rewriter is already not a core component and something that
> is
> >> community supported so I don't think enhancing it should be much of an
> >> issue. For what it's worth though I don't like the overhead of the
> existing
> >> pipeline as it is anyway. HTML doesn't have anything to do with XML
> anymore.
> >>
> >>> For JSON and client side rendering the link rewriting must be rather
> >>> encapsulated on the client side as well. I don’t think Sling should
> >>> provide that functionality as Sling is focusing on the server side.
> >>
> >> Missing a point here I think. If you are focusing on link rewriting,
> that
> >> is something that can only occur on the server side.  Helps with
> >> multi-tenancy and cross linking.
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [hackathon] health checks

[Justin Edelson]

Hi Georg,
Great. It looks like I misread Stefan's notes as being more dramatic than
they actually were intended to be :)

Regards,
Justin

On Tue, Sep 18, 2018 at 4:48 PM Georg Henzler  wrote:

> Hi Justin,
>
> there was quite some discussion at adaptTo() around this topic already. So
> as it stands all requirements to run Sling-based applications in Kubernetes
> are met already by Sling Health Checks (you just create two tags for
> readiness and liveness each). HCs were developed from the first day with
> the goal to have them used by load balancers (and not only manual). Also
> Sling HCs are more mature in terms of parallel execution, timeout handling,
> response customizing and special handling like asynchronous checks.


> Now the system readyness framework was mostly created to have something on
> Felix level and the capabilities of the Sling Health Checks weren’t known.
>
> I do agree that it would make sense to have it on Felix level though (more
> visible to the non-Sling world, as a low level mechanism maybe best located
> at the lowest framework level). The dependencies of Sling HC to Sling are
> minimal today already: It’s Sling thread pool (a felix pendant or just a
> plain java one can be used) and Sling Scheduler (also this can easily be
> replaced by the standard java mechanism).


> > It might make more sense to invert this and identify what the readyness
> framework does (mostly in its OOTB checks and servlets)
> > and merge that functionality into Sling Health Checks and then move Sling
> > Health Checks (or solid chunks of it) to Felix.
>
> This was the intention, but let’s wait for the feedback from Andrei and
> Christian.
>
> -Georg
>
> Sent from my iPhone
>
> > On 18. Sep 2018, at 16:31, Justin Edelson 
> wrote:
> >
> > Hi,
> > After reviewing the presentation, this seems like kind of a stretch to
> me.
> > IIUC, the System Readyness Framework is (as its name would suggest)
> solely
> > concerned with "readyness"  and "liveness" (as seen in the example use
> > cases on slide 3) and the API is explicitly designed for this purpose
> > without any opportunity for namespace extension (i.e. you can extend how
> > "readyness" and "liveness" are determined but you can't add new
> > categories). Sling Health Checks is concerned with a broader concept of
> > "health" with no restrictions on namespacing. There are all kinds of
> > reasons why a system may be considered "ready" but still fails specific
> > health checks. In other words, I'm doubtful that there is an overlap here
> > at a framework level. What would make sense is a bridge where a subset of
> > health checks could be fed into the readyness framework (i.e. if these X
> > health checks pass, the system is considered "ready" and/or "alive"). But
> > I'd strongly suggest that the gamut of expression possible with the
> health
> > check framework goes far beyond the scope of what the readyness framework
> > is designed to do. It might make more sense to invert this and identify
> > what the readyness framework does (mostly in its OOTB checks and
> servlets)
> > and merge that functionality into Sling Health Checks and then move Sling
> > Health Checks (or solid chunks of it) to Felix.
> >
> > Or perhaps I've misunderstood the intention of this email/F2F discussion.
> > But the way this looks is that we are going to take something with a
> decent
> > install base and replace it with something a few months old and a much
> > smaller functional scope. Just doesn't make sense to me.
> >
> > Regards,
> > Justin
> >
> > On Thu, Sep 13, 2018 at 1:03 PM Stefan Seifert 
> > wrote:
> >
> >> - currently there is some overlap between sling health checks and the
> new
> >> felix system readyness framework presented [1]
> >> - the idea is to bring this together within felix
> >> - provide a facade for the sling healthcheck API for backwards
> >> compatibility
> >>
> >> stefan
> >>
> >> [1]
> >>
> https://adapt.to/2018/en/schedule/system-readiness-framework-makes-deployment-automation-a-breeze.html
> >>
> >>
> >>
>

Re: [hackathon] health checks

[Justin Edelson]

Hi,
After reviewing the presentation, this seems like kind of a stretch to me.
IIUC, the System Readyness Framework is (as its name would suggest) solely
concerned with "readyness"  and "liveness" (as seen in the example use
cases on slide 3) and the API is explicitly designed for this purpose
without any opportunity for namespace extension (i.e. you can extend how
"readyness" and "liveness" are determined but you can't add new
categories). Sling Health Checks is concerned with a broader concept of
"health" with no restrictions on namespacing. There are all kinds of
reasons why a system may be considered "ready" but still fails specific
health checks. In other words, I'm doubtful that there is an overlap here
at a framework level. What would make sense is a bridge where a subset of
health checks could be fed into the readyness framework (i.e. if these X
health checks pass, the system is considered "ready" and/or "alive"). But
I'd strongly suggest that the gamut of expression possible with the health
check framework goes far beyond the scope of what the readyness framework
is designed to do. It might make more sense to invert this and identify
what the readyness framework does (mostly in its OOTB checks and servlets)
and merge that functionality into Sling Health Checks and then move Sling
Health Checks (or solid chunks of it) to Felix.

Or perhaps I've misunderstood the intention of this email/F2F discussion.
But the way this looks is that we are going to take something with a decent
install base and replace it with something a few months old and a much
smaller functional scope. Just doesn't make sense to me.

Regards,
Justin

On Thu, Sep 13, 2018 at 1:03 PM Stefan Seifert 
wrote:

> - currently there is some overlap between sling health checks and the new
> felix system readyness framework presented [1]
> - the idea is to bring this together within felix
> - provide a facade for the sling healthcheck API for backwards
> compatibility
>
> stefan
>
> [1]
> https://adapt.to/2018/en/schedule/system-readiness-framework-makes-deployment-automation-a-breeze.html
>
>
>

Re: SLING-7613 - un-deprecating loginAdministrative

[Justin Edelson]

If this is technically possible (and I don't see why it isn't), I think
this is a very elegant solution.

On Fri, Jul 27, 2018 at 10:41 AM Jason E Bailey  wrote:

> I may be off base here since I haven't spent much time with service users
> but couldn't  this be handled by extending the Service User so that for
> specific services, the user returned is the literal admin user.
>
> i.e. rather then whitelisting the services that can use
> loginAdministrative the service user that these whitelisted services would
> get would be the Administrator user.
>
> - Jason
>
> On Thu, Jul 19, 2018, at 5:25 AM, Bertrand Delacretaz wrote:
> > Hi,
> >
> > On Tue, Jul 17, 2018 at 1:43 PM Justin Edelson 
> wrote:
> > > ...Without the deprecation, how will a developer know that they need to
> > > configure the whitelist? While the deprecation wasn't perfect, at
> least it
> > > gave the developer the sense that they were doing something which
> should be
> > > avoided. It is unfortunate that deprecation in Java is such a binary
> > > concept, but it is what it is...
> >
> > I agree with Justin here, I think our intention is to say "do not use
> > this method unless you really have to and you know what you are doing"
> > and also "note that you have to whitelist bundles which uses this".
> >
> > That's not the standard meaning of a deprecated Java method, but as
> > Justin says we don't want developers to miss that restriction and
> > deprecation is a workable (and imperfect) way of doing that.
> >
> > With this in mind I suggest keeping the deprecation, creating a
> > website page that explains what it actually means and linking to that
> > page in the javadocs.
> >
> > -Bertrand
>

Re: SLING-7613 - un-deprecating loginAdministrative

[Justin Edelson]

Hi Roy,
I think Joerg lays out a few scenarios in SLING-7613 where there is a
distinction between loginService* and loginAdministrative. But that's not
really my point :)

All I'm trying to say is that if we are going to continue to have a
whitelist, we need a way to tell the developer that when they use
loginAdministrative some extra step is necessary. To my knowledge,
deprecation is the most universal way to do that.

Regards,
Justin

On Tue, Jul 17, 2018 at 9:45 AM Roy Teeuwen  wrote:

> Hey Justin,
>
> How would this be any different from using the getServiceResourceResolver
> though? This also needs additional work to actually create the service user
> and make a service mapping config for it.
> Not that I am disagreeing with what you are saying because I think the
> service user is also a bit too complex sometimes
>
> Greets
> Roy
>
> > On 17 Jul 2018, at 15:43, Justin Edelson 
> wrote:
> >
> > +1 to the idea of removing the deprecation
> > -0 on the PR
> >
> > Without the deprecation, how will a developer know that they need to
> > configure the whitelist? While the deprecation wasn't perfect, at least
> it
> > gave the developer the sense that they were doing something which should
> be
> > avoided. It is unfortunate that deprecation in Java is such a binary
> > concept, but it is what it is.
> >
> > I think we have two choices:
> >
> > 1. Go back to the way things were before -- no deprecation, no whitelist
> > 2. Keep the deprecation and whitelist and improve the JavaDoc
> >
> > No deprecation and keeping the whitelist just seems like a recipe for
> > confusion.
> >
> > Justin
> >
> > On Tue, Jul 17, 2018 at 8:55 AM Robert Munteanu 
> wrote:
> >
> >> Hi,
> >>
> >> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
> >> to un-deprecate loginAdministrative [3].
> >>
> >> Comments/reviews are most welcome, I plan to merge this next Monday.
> >>
> >> Thanks,
> >>
> >> Robert
> >>
> >> [1]: https://issues.apache.org/jira/browse/SLING-7613
> >> [2]:
> >>
> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
> >> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
> >>
>
>

Re: SLING-7613 - un-deprecating loginAdministrative

[Justin Edelson]

+1 to the idea of removing the deprecation
-0 on the PR

Without the deprecation, how will a developer know that they need to
configure the whitelist? While the deprecation wasn't perfect, at least it
gave the developer the sense that they were doing something which should be
avoided. It is unfortunate that deprecation in Java is such a binary
concept, but it is what it is.

I think we have two choices:

1. Go back to the way things were before -- no deprecation, no whitelist
2. Keep the deprecation and whitelist and improve the JavaDoc

No deprecation and keeping the whitelist just seems like a recipe for
confusion.

Justin

On Tue, Jul 17, 2018 at 8:55 AM Robert Munteanu  wrote:

> Hi,
>
> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
> to un-deprecate loginAdministrative [3].
>
> Comments/reviews are most welcome, I plan to merge this next Monday.
>
> Thanks,
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-7613
> [2]:
> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
>

Re: Issue with Animal Snigger Maven Plugin

[Justin Edelson]

I don't know if this is necessarily related to the problem you are having,
but FWIW, doing this will cause problems on case-insensitive filesystems --
depending on the compile sequencing (I assume it is the sequence in the
file, but I'm not sure), the class file for Check will overwrite the class
file for CHECK.

Personally, I would stay away from names that are so possibly conflatable,
either by humans or machines.

Regards,
Justin

On Fri, Jul 6, 2018 at 3:46 PM Andreas Schaefer 
wrote:

> Hi
>
> Will developing some code in org-apache-sling-resourceresolver I ran into
> an issue with the animal sniffer maven plugin.
>
> I create an Interface that contains:
> - an enum called ‘CHECK'
> - an inner class that is named’ Check'
> - that inner class has a private variable 'CHECK check’
>
> Then I see this report while building the module:
>
> [INFO] --- animal-sniffer-maven-plugin:1.16:check (default) @
> org.apache.sling.resourceresolver ---
> [INFO] Checking unresolved references to
> org.codehaus.mojo.signature:java17:1.0
> [ERROR] /Users/schaefa/Development/
> madplanet.com/apache/sling-dev/sling-git/org-apache-sling-resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java:993:
> Undefined reference:
> org.apache.sling.resourceresolver.impl.mapping.PlaceholderProvider.CHECK
> [ERROR] /Users/schaefa/Development/
> madplanet.com/apache/sling-dev/sling-git/org-apache-sling-resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java:993:
> Undefined reference:
> org.apache.sling.resourceresolver.impl.mapping.PlaceholderProvider.CHECK
> org.apache.sling.resourceresolver.impl.mapping.PlaceholderProvider.CHECK.found
>
> Renaming the enum to something else like ‘STATUS’ did resolve the issue.
>
> Upgrading to 1.17 did caused the same issue but I now see this error which
> seems to indicate an issue with the plugin itself:
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:animal-sniffer-maven-plugin:1.17:check (default) on
> project org.apache.sling.resourceresolver: Execution default of goal
> org.codehaus.mojo:animal-sniffer-maven-plugin:1.17:check failed: An API
> incompatibility was encountered while executing
> org.codehaus.mojo:animal-sniffer-maven-plugin:1.17:check:
> java.lang.NoSuchMethodError:
> java.nio.CharBuffer.position(I)Ljava/nio/CharBuffer;
> [ERROR] -
> [ERROR] realm =
> plugin>org.codehaus.mojo:animal-sniffer-maven-plugin:1.17
> …
>
> Did anyone see something similar?
>
> Cheers - Andy Schaefer

Re: New "capabilities" module, feedback welcome

[Justin Edelson]

Hi Joerg,
Even when a servlet is bound by resource type, it still assigned a resource
entry. If you look at /system/console/status-jcrresolver (which is
incorrectly named, but that's another story) on a running Sling instance
with some servlets installed, you'll see entries for each servlet under a
path like /libs/..servlet (or something like that).

Looking at this specific case, I'm now thinking that the implementation of
a servlet here is non-idiomatic. It would be better (at least from my
perspective), if this was all handled via ResourceProvider (e.g. mounted at
/system/sling/capabilities or some such) and each CapabilitySource resulted
in a child resource (the ResourceProvider could/should handle the creation
of the synthetic resource; it doesn't have to be part of the
CapabilitiesSource SPI). Then a request to
/system/sling/capabilities.infinity.json would return all the capabilities
and a request to /system/sling/capabilities/.json would return
just a single capability. No servlet is actually necessary -- the default
GET servlet will handle the serialization.

This would, I think, obviate the need for some of this discussion about
access control since it becomes obvious that Resource Access Security is
the correct approach as securing non-JCR Resource Providers is the original
use case for Resource Access Security (at least if my fragile memory
serves).

@Bertrand - is there a reason you went with a single servlet implementation
vs. having each capability source be its own resource?

On Wed, Jun 27, 2018 at 1:42 PM Jörg Hoh 
wrote:

> Hi Julian,
>
> the "traditional" way to bind a servlet to the resource tree is to create a
> resource with the respective resource type. And because in "traditional"
> setups we most often had backed our resource tree by a JCR repo, so
> creating a node with the correct resource type property was the way to go.
> And restricting access to that servlet can then be implemented by
> restricting access to the JCR node by the means of JCR access control.
> But I understand that you are speaking of Resource Access Security, which
> does not rely on JCR access control, but can be applied independently of
> it, on a pure Sling Resource level.
>
> Is that correct?
>
> In my understanding, it doesn't matter which approach we choose (JCR access
> control or Resource Access Security), limiting access to a servlet should
> not be a concern of the servlet; I fully agree to Julian's position here.
>
> Jörg
>
>
>
>
> 2018-06-27 13:23 GMT+00:00 Julian Sedding :
>
> > Hi Radu
> >
> > Internally, every Servlet registered by resource type in Sling is
> > exposed at one (or several) locations in the Resource tree (!= JCR
> > Node tree).
> >
> > ResourceAccessGate is a pluggable API that allows preventing read
> > access to arbitrary resources.
> >
> > Therefore it is possible to prevent access to the resource(s) that
> > represent the Servlet.
> >
> > Whether the actual ResourceAccessGate implementation uses JCR/Oak
> > internally is irrelevant on a conceptual level. On a practical level
> > it may be desirable and it is certainly possible. The implementation
> > could choose an arbitrary convention, e.g. permissions could be
> > checked at /apps/servlets/org.example.BackDoorServlet for
> > org.example.BackDoorServlet.
> >
> > I hope this helps clarify the concept :)
> >
> > Regards
> > Julian
> >
> >
> >
> > On Wed, Jun 27, 2018 at 1:58 PM, Radu Cotescu  wrote:
> > > Hi Julian,
> > >
> > >> On 26 Jun 2018, at 09:25, Julian Sedding  wrote:
> > >>
> > >> Hi Bertrand
> > >>
> > >> On Mon, Jun 25, 2018 at 6:22 PM, Bertrand Delacretaz
> > >> mailto:bdelacre...@apache.org>> wrote:
> > >>> Hi Julian,
> > >>>
> > >>> On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding 
> > wrote:
> >  Regarding securing the servlet:
> >  Registering a servlet in Sling creates resources. In the case of the
> >  capabilities servlet, that should be the resource
> >  "/libs/sling/capabilities.json.GET.servlet". Since the "Resource
> >  Access Security" module allows restricting read access to resources,
> >  this could be used to secure the servlet...
> > >>>
> > >>> Yes, but that only works for servlet, I think if we agree on a
> > >>> (simple) mechanism to secure arbitrary operations, as Radu suggest,
> > >>> it's more flexible.
> > >>
> > >> Why do you say that only works for servlets? Sling's rendering script
> > >> resolution is entirely built on topof the resource abstraction. That
> > >> is the reason that servlets are part of the resource tree in the first
> > >> place. This in turn leads to the (IMHO desirable) property that
> > >> "Scripts and Servlets are equal"[0].
> > >>
> > >> [0] https://sling.apache.org/documentation/the-sling-
> > engine/url-to-script-resolution.html#fundamental-
> > scripts-and-servlets-are-equal  > documentation/the-sling-engine/url-to-script-resolution.html#fundamental-
> > scripts-and-servlets-are-equal>
> > >>
> > >>>
> > >>> And 

Re: New "capabilities" module, feedback welcome

[Justin Edelson]

One thing I noticed in the example is the (apparent) use of the class name
as the namespace. While there doesn't appear to be anything in the API to
encourage or require this (if anything the opposite), I'd suggest updating
the example to use something that wasn't an implementation detail so that
SPI implementors don't get the wrong idea.

I created
https://github.com/apache/sling-org-apache-sling-capabilities/pull/1 to
change this. Of course, the namespaces used there are not normative -- just
an idea.

I'm interested to see how this gets used.

Regards,
Justin

On Wed, Jun 20, 2018 at 9:38 AM Bertrand Delacretaz 
wrote:

> Hi,
>
> I've been working on a (very simple) module to create a "capabilities"
> endpoint, where a Sling instance can let HTTP clients know about its
> version levels, presence or absence of certain services etc.
>
> It's at
> https://github.com/apache/sling-whiteboard/tree/master/capabilities
> and if no one is opposed I'll move it to its own module and make a
> first release later this week.
>
> Feedback is welcome.
>
> -Bertrand
>

[jira] [Commented] (SLING-7624) Add OSGi7 component property annotations for Servlet and Filter

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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 (JIRA)]

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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 (JIRA)]

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)

Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

[Justin Edelson]

Oh yeah, then that's a problem. It really should be epoch-based IMO.

On Mon, Apr 9, 2018 at 10:28 AM Konrad Windszus  wrote:

> By default the timestamp is having the format "MMddHHmm" (
> http://bnd.bndtools.org/macros/tstamp.html <
> http://bnd.bndtools.org/macros/tstamp.html>), this could be a problem in
> certain cases where you redeploy two builds within the same minute.
>
>
> > On 9. Apr 2018, at 15:55, Justin Edelson 
> wrote:
> >
> > I'm not sure this is problematic from the perspective of the installer.
> The
> > point of the different SNAPSHOT handling is to support the use case of
> > updating a bundle with the *same* bundle version. However, if the bundle
> > versions are including a timestamp, it isn't needed since the bundle
> > versions would be constantly increasing.
> >
> > Now there could be a problem if the timestamp somehow not taking
> timezones
> > into account, but assuming it is UNIX epoch based, then this won't be an
> > issue.
> >
> > Regards,
> > Justin
> >
> > On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:
> >
> >> I am just migrating the OSGi Installer HC (
> >> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
> >> bnd-maven-plugin and I observed one difference to the
> maven-bundle-plugin:
> >>
> >> The bundle version for SNAPSHOTs by default looks like
> "1.0.1."
> >> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
> >> The reason for that is this line:
> >>
> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
> >> wich
> >> sets the snapshot instruction to the timestamp (
> >> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
> >> SNAPSHOT qualifier in the version being replaced by the timestamp in the
> >> generated bundle version.
> >>
> >> This is IMHO problematic in combination with the OSGi Installer, as that
> >> behaves differently when it detects a SNAPSHOT (
> >>
> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
> >> ).
> >>
> >> Should we configure all our bundles in a way that SNAPSHOT in the
> version
> >> is not being replaced, or can we come up with a more intelligent
> solution
> >> in the OSGi Installer?
> >> I noticed that in the manifest we have in addition still
> >> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base
> the
> >> SNAPSHOT detection of the OSGi Installer.
> >>
> >> WDYT?
> >> Konrad
> >>
> >>
> >>
>
>

Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

[Justin Edelson]

I'm not sure this is problematic from the perspective of the installer. The
point of the different SNAPSHOT handling is to support the use case of
updating a bundle with the *same* bundle version. However, if the bundle
versions are including a timestamp, it isn't needed since the bundle
versions would be constantly increasing.

Now there could be a problem if the timestamp somehow not taking timezones
into account, but assuming it is UNIX epoch based, then this won't be an
issue.

Regards,
Justin

On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:

> I am just migrating the OSGi Installer HC (
> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
> bnd-maven-plugin and I observed one difference to the maven-bundle-plugin:
>
> The bundle version for SNAPSHOTs by default looks like "1.0.1."
> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
> The reason for that is this line:
> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
> wich
> sets the snapshot instruction to the timestamp (
> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
> SNAPSHOT qualifier in the version being replaced by the timestamp in the
> generated bundle version.
>
> This is IMHO problematic in combination with the OSGi Installer, as that
> behaves differently when it detects a SNAPSHOT (
> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
> ).
>
> Should we configure all our bundles in a way that SNAPSHOT in the version
> is not being replaced, or can we come up with a more intelligent solution
> in the OSGi Installer?
> I noticed that in the manifest we have in addition still
> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base the
> SNAPSHOT detection of the OSGi Installer.
>
> WDYT?
> Konrad
>
>
>

[jira] [Comment Edited] (SLING-7508) StackOverflowError adapting ServletResource to Sling Model with impl picker

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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 (JIRA)]

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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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 (JIRA)]

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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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)

[RESULT] [VOTE] Release Apache Sling Models Impl version 1.4.6

[Justin Edelson]

The vote has passed with 3 votes:

+1: Stefan Seifert, Robert Munteanu, Justin Edelson

On Fri, Dec 8, 2017 at 10:46 AM Justin Edelson 
wrote:

> Hi,
>
> We solved 6 issues in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12341409
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1831/
>
> You can use this UNIX script to download the release and verify the
> signatures:
>
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>
> Usage:
> sh check_staged_release.sh 1831 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>

Re: [VOTE] Release Apache Sling Models Impl version 1.4.6

[Justin Edelson]

+1

On Tue, Dec 12, 2017 at 10:17 AM Robert Munteanu  wrote:

> On Fri, 2017-12-08 at 15:46 +0000, Justin Edelson wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

Re: [VOTE] Release Apache Sling Models Impl version 1.4.6

[Justin Edelson]

Anyone else care to vote on this? Thanks.

On Fri, Dec 8, 2017 at 11:07 AM Stefan Seifert 
wrote:

> +1
>

[VOTE] Release Apache Sling Models Impl version 1.4.6

[Justin Edelson]

Hi,

We solved 6 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12341409

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1831/

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 1831 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

[jira] [Resolved] (SLING-7292) Only add model object to disposal registry if it is not empty

[Justin Edelson (JIRA)]

 [ 
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 (JIRA)]

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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 

Re: value level encryption

[Justin Edelson]

In AEM, posting encrypted properties to /etc/cloudservices is historically
the primary use case for @Encrypted, but the PostProcessor applies to all
post requests.

I think this would be a useful addition to Sling. We may want to have some
kind of SPI to support different encryption schemes, but that's an
implementation detail.

Regards,
Justin


On Fri, Nov 3, 2017 at 2:48 PM Jason Bailey  wrote:

> They only docs I can find on that, assuming we're talking AEM, mentions it
> only works for posting things into /etc/cloudservices. So that's out.
> It's been a while, but I'm under the impression that all implementations
> of the java platform now come with a certain level of crypto
>
> https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
>
> I'd probably add a configuration so you could define the level of
> cryptography, and then that would allow people who needed a higher level to
> install their own providers. Is this something that Sling would be
> interested in? Since I'm going to be writing this, if you're interested,
> I'd rather write it with the intent of directly donating it.
>
>
>
> -Original Message-
> From: Justin Edelson [mailto:jus...@justinedelson.com]
> Sent: Friday, November 03, 2017 1:35 PM
> To: dev@sling.apache.org
> Subject: Re: value level encryption
>
> EXTERNAL
>
> We have this in our commercial product. At a high level, the way it works
> is that there is a PostProcessor which looks for an @Encrypted postfixed
> property and, if that is present, the corresponding property is stored in
> an encrypted fashion. Decryption is all done manually, although personally
> the idea of an EncryptionValueMap seems really cool to me.
>
> I believe the challenge in bringing this into Sling relates to the
> encryption libraries.
>
> On Fri, Nov 3, 2017 at 8:45 AM Jason Bailey  wrote:
>
> > Here's the use case
> >
> > My organization has decided that to conform to the GDPR, any sensitive
> > data should be encrypted while at rest. From a Sling perspective that
> > is a challenge since we've empowered the authors to create forms the
> > way they want. So to be on the safe side, we're looking at encrypting
> > all form fields as they are persisted, and then decrypting the values
> > from the resource  when we need to processes them.
> >
> > Now I'm thinking of an EncryptionValueMap that will simplify this
> > process and encapsulate the functionality. You guys are usually ahead
> > of me when I come up with this stuff and I don't like replicating
> > effort. So is there any functionality currently or planned to handle
> > encryption of resource values?
> >
> > Thanks
> > Jason
> >
>

Re: value level encryption

[Justin Edelson]

We have this in our commercial product. At a high level, the way it works
is that there is a PostProcessor which looks for an @Encrypted postfixed
property and, if that is present, the corresponding property is stored in
an encrypted fashion. Decryption is all done manually, although personally
the idea of an EncryptionValueMap seems really cool to me.

I believe the challenge in bringing this into Sling relates to the
encryption libraries.

On Fri, Nov 3, 2017 at 8:45 AM Jason Bailey  wrote:

> Here's the use case
>
> My organization has decided that to conform to the GDPR, any sensitive
> data should be encrypted while at rest. From a Sling perspective that is a
> challenge since we've empowered the authors to create forms the way they
> want. So to be on the safe side, we're looking at encrypting all form
> fields as they are persisted, and then decrypting the values from the
> resource  when we need to processes them.
>
> Now I'm thinking of an EncryptionValueMap that will simplify this process
> and encapsulate the functionality. You guys are usually ahead of me when I
> come up with this stuff and I don't like replicating effort. So is there
> any functionality currently or planned to handle encryption of resource
> values?
>
> Thanks
> Jason
>

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Justin Edelson]

+1

Great solution.
On Sat, Oct 21, 2017 at 3:26 PM Robert Munteanu  wrote:

> On Fri, 2017-10-20 at 23:19 +0200, Robert Munteanu wrote:
> > I guess the 'minimal damage' approach would be to switch the main
> > branch and make that empty, with just a README.md .
> >
> > Would need to talk to infra to see how that can happen. Unless anyone
> > is opposed, I would create a branch called 'archived' with the
> > following README.md contents:
>
> Here's how it would look once switched:
>
>   https://github.com/apache/sling/tree/archived
>
> Robert
>

[jira] [Commented] (SLING-7203) Sling Model Request-Scoped Caching Not Effective Across Script Include Boundaries

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 (JIRA)]

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)

Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes

[Justin Edelson]

On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu  wrote:

>
>
> Perhaps the people that actually work with these multi-project
> extensions would like to comment? By a quick check we have:
>
> - models
>
>
The models bundles can be released independently, i.e. I've done a number
of releases of the implementation bundle without touching the API bundle.

While Konrad is correct that ITs are an issue, my strong preference with
Sling Models is to minimize the use of ITs, i.e. use them only for code
paths which are difficult to test via a unit test, so I don't really see
that as an issue.

Regards,
Justin

Re: [NOTICE] Getting ready to start the SVN → Git migration

[Justin Edelson]

On Thu, Oct 12, 2017 at 4:42 PM Stefan Seifert 
wrote:

> >BTW, not sure what the access rule for users@infra are, but you should
> >be able to access https://lists.apache.org/list.html?users@infra.apache
> >.org and then log in with your ASF credentials. I think it works for
> >committers.
>
> even if i login:
> i cannot access https://lists.apache.org/list.html?us...@infra.apache.org
> i can access https://lists.apache.org/list.html?iss...@infra.apache.org
>
> stefan
>

What I see is that when I try to go to
https://lists.apache.org/list.html?us...@infra.apache.org, after
authenticating, I end up on
https://lists.apache.org/list.html?iss...@infra.apache.org

[jira] [Assigned] (SLING-7187) Use of Injector-specific annotation and @Optional results in required-value

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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 (JIRA)]

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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Justin Edelson (JIRA)]

 [ 
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

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)