[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

[Oliver Lietz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966362#comment-15966362
 ] 

Oliver Lietz commented on SLING-6780:
-

[~radu.cotescu], [~vladb]: Do *not* depend on 
{{org.apache.sling.scripting.javascript}} when 
{{org.apache.sling.scripting.sightly.js.provider}} depends in fact on 
{{org.mozilla.javascript}}, see SLING-5731 and SLING-6668.

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: declare an explicit dependency on 
> {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick 
> up the correct version range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Oliver Lietz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966244#comment-15966244
 ] 

Oliver Lietz commented on SLING-6777:
-

bq. Is there any indication this is happening frequently instead of a one-off 
situation and persists after it has happened once?

The error was observed once (which doesn't mean much in this case).

bq. Note that Validation does not see the resolver here, so validation could 
not handle this directly.

We can at least surround {{resourceBundleProvider.getResourceBundle(locale)}} 
with {{try}}/{{catch}} inside the loop and log an error.

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Affects Versions: i18n 2.5.8, Validation 1.0.0
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz updated SLING-6777:

Affects Version/s: i18n 2.5.8
   Validation 1.0.0

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Affects Versions: i18n 2.5.8, Validation 1.0.0
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6085) resource.getValueMap() to unavailable in Sightly JS-code

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu reassigned SLING-6085:
---

Assignee: Radu Cotescu

> resource.getValueMap() to unavailable in Sightly JS-code
> 
>
> Key: SLING-6085
> URL: https://issues.apache.org/jira/browse/SLING-6085
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.2
>Reporter: Feike Visser
>Assignee: Radu Cotescu
> Fix For: Scripting JavaScript 2.0.32
>
>
> In Sightly JS-api you can't use resource.getValueMap() method, looks like it 
> is unavailable.
> There you need to do this workaround to get to the properties
> {code}
> "use strict";
> use(function () {
> var parent = resource.getParent();
> var props = 
> parent.adaptTo(Packages.org.apache.sling.api.resource.ValueMap);
> return props.get("jcr:createdBy","");
> });
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu updated SLING-6780:

Fix Version/s: Scripting HTL JS Use Provider 1.0.22

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: declare an explicit dependency on 
> {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick 
> up the correct version range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu reassigned SLING-6780:
---

Assignee: Radu Cotescu

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: declare an explicit dependency on 
> {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick 
> up the correct version range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu updated SLING-6780:

Summary: org.apache.sling.scripting.sightly.js.provider does not declare a 
version range for the org.mozilla.javascript import  (was: 
org.apache.sling.scripting.sightly.js.provider does not declare an version 
range for org.mozilla.javascript import)

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: declare an explicit dependency on 
> {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick 
> up the correct version range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6761) HTL: uri manipulator breaks query parameter encoding

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu updated SLING-6761:

Environment: (was: AEM 6.1 SP2 - CFP6
AEM 6.2)

> HTL: uri manipulator breaks query parameter encoding
> 
>
> Key: SLING-6761
> URL: https://issues.apache.org/jira/browse/SLING-6761
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2, Scripting Sightly Engine 
> 1.0.18
>Reporter: Robin Brouns
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.34
>
>
> When I try to manipulate a href tag with HTL, and the href contains a query 
> param with encoded percentage sign (%25), the HTL manipulator breaks the URI 
> encoding, resulting in a invalid URI.
> For example when we have a *path* property in the repository, containing the 
> following value:
> {code}
> /example/search?q=6%25-10%25
> {code}
> and use the following HTL code:
> {code}
> Test with @ HTL URI 
> manipulator
> Test without @ HTL URI manipulator
> {code}
> The result will be:
> {code}
> Test with @ HTL URI manipulator
> Test without @ HTL URI manipulator
> {code}
> So the HTL URI manipulation removes the %25 encoding and replaces it with a 
> single percentage sign. Without manipulation the encoding is preserved. Same 
> holds for other HTL uri manipulators like  *@ prependPath*
> Other signs like *%3A* aren't affected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare an version range for org.mozilla.javascript import

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965997#comment-15965997
 ] 

ASF GitHub Bot commented on SLING-6780:
---

GitHub user vladbailescu opened a pull request:

https://github.com/apache/sling/pull/213

SLING-6780 - org.apache.sling.scripting.sightly.js.provider does not …

…declare an version range for org.mozilla.javascript import

* Added dependency to org.apache.sling.scripting.javascript

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vladbailescu/sling issue/SLING-6780

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/213.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #213


commit 21891430ea2b3af8d860db44009a393bfa7de738
Author: vladbailescu 
Date:   2017-04-12T14:56:54Z

SLING-6780 - org.apache.sling.scripting.sightly.js.provider does not 
declare an version range for org.mozilla.javascript import

* Added dependency to org.apache.sling.scripting.javascript




> org.apache.sling.scripting.sightly.js.provider does not declare an version 
> range for org.mozilla.javascript import
> --
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: declare an explicit dependency on 
> {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick 
> up the correct version range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] sling pull request #213: SLING-6780 - org.apache.sling.scripting.sightly.js....

[vladbailescu]

GitHub user vladbailescu opened a pull request:

https://github.com/apache/sling/pull/213

SLING-6780 - org.apache.sling.scripting.sightly.js.provider does not …

…declare an version range for org.mozilla.javascript import

* Added dependency to org.apache.sling.scripting.javascript

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vladbailescu/sling issue/SLING-6780

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/213.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #213


commit 21891430ea2b3af8d860db44009a393bfa7de738
Author: vladbailescu 
Date:   2017-04-12T14:56:54Z

SLING-6780 - org.apache.sling.scripting.sightly.js.provider does not 
declare an version range for org.mozilla.javascript import

* Added dependency to org.apache.sling.scripting.javascript




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare an version range for org.mozilla.javascript import

[Vlad Bailescu (JIRA)]

Vlad Bailescu created SLING-6780:


 Summary: org.apache.sling.scripting.sightly.js.provider does not 
declare an version range for org.mozilla.javascript import
 Key: SLING-6780
 URL: https://issues.apache.org/jira/browse/SLING-6780
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Sightly JS Use Provider 1.0.10
Reporter: Vlad Bailescu


The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not declaring 
a version range for the {{org.mozilla.javascript}} import in its manifest. This 
can become a problem when someone installs an incompatible version. The 
solution is simple: declare an explicit dependency on 
{{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick up 
the correct version range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Event API 1.0.0 (initial release)

[Carsten Ziegeler]

+1

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Comment Edited] (SLING-3014) [build] Generate SCR descriptors using Maven

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965936#comment-15965936
 ] 

Konrad Windszus edited comment on SLING-3014 at 4/12/17 2:33 PM:
-

With the PDE annotation builder the OSGI-INF folder is being placed in the root 
directory of the project. From there it is being picked up from the Eclipse 
Laucher as well. Unfortunately bnd-maven-plugin writes the OSGI-INF always to 
the folder given by configuration {{classesDir}} 
(https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L270).
 Unfortunately {{classesDir}} is not only the used for expanding the JAR but 
also for generating the classpath for Bnd, therefore you cannot simply 
reconfigure that. Also the {{bnd-maven-plugin}} will only write those 
classes/resources which have not been existing in the target directory already 
(to distinguish between files being created by bnd and those which just have 
been wrapped in the JAR). Therefore coming up with a PR for the 
{{bnd-maven-plugin}} which allows to write the OSGI-INF somewhere else is not 
easy. But I found a simple workaround:

{code}

maven-resources-plugin

  
copy-resources

prepare-package

  copy-resources


  ${basedir}/OSGI-INF


  
${project.build.outputDirectory}/OSGI-INF
  false



  

  
{code}

That will copy the OSGI-INF from {{target/classes}} to the root directory of 
the project from where it is being picked up by both PDE and Tycho. Of course 
the OSGI-INF needs to be listed in {{build.properties}} {{bin.includes}} as 
well.


was (Author: kwin):
With the PDE annotation builder the OSGI-INF folder is being placed in the root 
directory of the project. From there it is being picked up from the Eclipse 
Laucher as well. Unfortunately bnd-maven-plugin writes the OSGI-INF always to 
the folder given by configuration {{classesDir}} 
(https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L270).
 Unfortunately {{classesDir}} is not only the used for expanding the JAR but 
also for generating the classpath for Bnd, therefore you cannot simply 
reconfigure that. Also the {{bnd-maven-plugin}} will only write those 
classes/resources which have not been existing in the target directory already 
(to distinguish between files being created by bnd and those which just have 
been wrapped in the JAR). But I found a simple workaround:

{code}

maven-resources-plugin

  
copy-resources

prepare-package

  copy-resources


  ${basedir}/OSGI-INF


  
${project.build.outputDirectory}/OSGI-INF
  false



  

  
{code}

That will copy the OSGI-INF to the root directory of the project from where it 
is being picked up by both PDE and Tycho. Of course the OSGI-INF needs to be 
listed in {{build.properties}} {{bin.includes}} as well.

> [build] Generate SCR descriptors using Maven
> 
>
> Key: SLING-3014
> URL: https://issues.apache.org/jira/browse/SLING-3014
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.2.0
>
> Attachments: SLING-3014-1.patch
>
>
> _Edit_: updated the issue title to reflect the fact that we're looking to use 
> Maven, not a specific plug-in.
> Since we're starting to use SCR descriptors when building the Sling IDE tools 
> it would be nice to generate them using the maven-scr-plugin. I have the 
> build working in the CLI, but not yet in the IDE ( see 
> http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04764.html ). Once that is 
> done I'll commit my changes to trunk.
> Note that plain Maven projects work just fine, this is about Tycho-driven 
> builds.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-3014) [build] Generate SCR descriptors using Maven

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965936#comment-15965936
 ] 

Konrad Windszus edited comment on SLING-3014 at 4/12/17 2:32 PM:
-

With the PDE annotation builder the OSGI-INF folder is being placed in the root 
directory of the project. From there it is being picked up from the Eclipse 
Laucher as well. Unfortunately bnd-maven-plugin writes the OSGI-INF always to 
the folder given by configuration {{classesDir}} 
(https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L270).
 Unfortunately {{classesDir}} is not only the used for expanding the JAR but 
also for generating the classpath for Bnd, therefore you cannot simply 
reconfigure that. Also the {{bnd-maven-plugin}} will only write those 
classes/resources which have not been existing in the target directory already 
(to distinguish between files being created by bnd and those which just have 
been wrapped in the JAR). But I found a simple workaround:

{code}

maven-resources-plugin

  
copy-resources

prepare-package

  copy-resources


  ${basedir}/OSGI-INF


  
${project.build.outputDirectory}/OSGI-INF
  false



  

  
{code}

That will copy the OSGI-INF to the root directory of the project from where it 
is being picked up by both PDE and Tycho. Of course the OSGI-INF needs to be 
listed in {{build.properties}} {{bin.includes}} as well.


was (Author: kwin):
With the PDE annotation builder the OSGI-INF folder is being placed in the root 
directory of the project. From there it is being picked up from the Eclipse 
Laucher as well. Unfortunately bnd-maven-plugin writes the OSGI-INF always to 
the folder given by configuration {{classesDir}} 
(https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L270).
 Unfortunately {{classesDir}} is not only the used for expanding the JAR but 
also for generating the classpath for Bnd, therefore you cannot simply 
reconfigure that. I will try to come up with a PR for {{bnd-maven-plugin}} 
which allows to extract the JAR somewhere else.

> [build] Generate SCR descriptors using Maven
> 
>
> Key: SLING-3014
> URL: https://issues.apache.org/jira/browse/SLING-3014
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.2.0
>
> Attachments: SLING-3014-1.patch
>
>
> _Edit_: updated the issue title to reflect the fact that we're looking to use 
> Maven, not a specific plug-in.
> Since we're starting to use SCR descriptors when building the Sling IDE tools 
> it would be nice to generate them using the maven-scr-plugin. I have the 
> build working in the CLI, but not yet in the IDE ( see 
> http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04764.html ). Once that is 
> done I'll commit my changes to trunk.
> Note that plain Maven projects work just fine, this is about Tycho-driven 
> builds.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-3014) [build] Generate SCR descriptors using Maven

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965936#comment-15965936
 ] 

Konrad Windszus commented on SLING-3014:


With the PDE annotation builder the OSGI-INF folder is being placed in the root 
directory of the project. From there it is being picked up from the Eclipse 
Laucher as well. Unfortunately bnd-maven-plugin writes the OSGI-INF always to 
the folder given by configuration {{classesDir}} 
(https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L270).
 Unfortunately {{classesDir}} is not only the used for expanding the JAR but 
also for generating the classpath for Bnd, therefore you cannot simply 
reconfigure that. I will try to come up with a PR for {{bnd-maven-plugin}} 
which allows to extract the JAR somewhere else.

> [build] Generate SCR descriptors using Maven
> 
>
> Key: SLING-3014
> URL: https://issues.apache.org/jira/browse/SLING-3014
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.2.0
>
> Attachments: SLING-3014-1.patch
>
>
> _Edit_: updated the issue title to reflect the fact that we're looking to use 
> Maven, not a specific plug-in.
> Since we're starting to use SCR descriptors when building the Sling IDE tools 
> it would be nice to generate them using the maven-scr-plugin. I have the 
> build working in the CLI, but not yet in the IDE ( see 
> http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04764.html ). Once that is 
> done I'll commit my changes to trunk.
> Note that plain Maven projects work just fine, this is about Tycho-driven 
> builds.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6733) Metric duration of a request

[Clelia Meneghin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clelia Meneghin updated SLING-6733:
---
Attachment: (was: patchSLING-6733.diff)

> Metric duration of a request
> 
>
> Key: SLING-6733
> URL: https://issues.apache.org/jira/browse/SLING-6733
> Project: Sling
>  Issue Type: Test
>Reporter: Clelia Meneghin
>Priority: Trivial
> Attachments: patch-6732-V2.diff
>
>
> A Metric is added in the sling engine bundle where measure how long a request 
> needs



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965900#comment-15965900
 ] 

Carsten Ziegeler commented on SLING-6777:
-

Is this version used? Clearly it's not the latest i18n version so it might be 
an different validation impl? I think we really need version info here first

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6732) Metric Request per Second Sling has to handle

[Clelia Meneghin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clelia Meneghin updated SLING-6732:
---
Attachment: patch-6732-V2.diff

Meter is removed cause same result with metric timer

> Metric Request per Second Sling has to handle
> -
>
> Key: SLING-6732
> URL: https://issues.apache.org/jira/browse/SLING-6732
> Project: Sling
>  Issue Type: Test
>Reporter: Clelia Meneghin
>Priority: Trivial
> Attachments: patch-6732-V2.diff
>
>
> A Metrik is added to the SlingMainServlet in the engine bundle 
> It s measuring the request per second sling gets



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6732) Metric Request per Second Sling has to handle

[Clelia Meneghin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clelia Meneghin updated SLING-6732:
---
Attachment: (was: patchSLING-6732.diff)

> Metric Request per Second Sling has to handle
> -
>
> Key: SLING-6732
> URL: https://issues.apache.org/jira/browse/SLING-6732
> Project: Sling
>  Issue Type: Test
>Reporter: Clelia Meneghin
>Priority: Trivial
> Attachments: patch-6732-V2.diff
>
>
> A Metrik is added to the SlingMainServlet in the engine bundle 
> It s measuring the request per second sling gets



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6733) Metric duration of a request

[Clelia Meneghin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clelia Meneghin updated SLING-6733:
---
Attachment: patch-6732-V2.diff

renamed metric

> Metric duration of a request
> 
>
> Key: SLING-6733
> URL: https://issues.apache.org/jira/browse/SLING-6733
> Project: Sling
>  Issue Type: Test
>Reporter: Clelia Meneghin
>Priority: Trivial
> Attachments: patch-6732-V2.diff, patchSLING-6733.diff
>
>
> A Metric is added in the sling engine bundle where measure how long a request 
> needs



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-3014) [build] Generate SCR descriptors using Maven

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965853#comment-15965853
 ] 

Konrad Windszus commented on SLING-3014:


Have you tried enabling the PDE builder for DS on the project 
(https://www.eclipse.org/eclipse/news/4.6/pde.php#ds-annotations) in addition? 
That way even within Eclipse the annotations should be usable. I am wondering 
though why the result being created from bnd-maven-plugin is not used from 
within Eclipse itself.

> [build] Generate SCR descriptors using Maven
> 
>
> Key: SLING-3014
> URL: https://issues.apache.org/jira/browse/SLING-3014
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.2.0
>
> Attachments: SLING-3014-1.patch
>
>
> _Edit_: updated the issue title to reflect the fact that we're looking to use 
> Maven, not a specific plug-in.
> Since we're starting to use SCR descriptors when building the Sling IDE tools 
> it would be nice to generate them using the maven-scr-plugin. I have the 
> build working in the CLI, but not yet in the IDE ( see 
> http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04764.html ). Once that is 
> done I'll commit my changes to trunk.
> Note that plain Maven projects work just fine, this is about Tycho-driven 
> builds.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965825#comment-15965825
 ] 

Konrad Windszus commented on SLING-6777:


bq. This could also be a bug in the validation service holding a stale 
ResourceBundleProvider
Indeed it could be, but I currently fail to see how this can happen. The 
{{ValidationServiceImpl}} holds a volatile dynamic reference to all 
{{ResourceBundleProviders}} in 
https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java#L101.
 This is used in {{getDefaultResourceBundle}} to get a  resource bundle. This 
resource bundle is not cached and also the stack trace from this issue actually 
includes {{getDefaultResourceBundle}} so I am wondering, how the 
{{ResourceBundleProvider}} could have been deactivated here.

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-4043) The JCR properties view does not display escaped properties with escaped values correctly

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965812#comment-15965812
 ] 

Konrad Windszus commented on SLING-4043:


I made a proposal on a refactored API and {{ResourceProxy}} in 
https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+Tooling+-+API+Refactoring.
 That is kind of a prerequisite for this issue to be solved.

> The JCR properties view does not display escaped properties with escaped 
> values correctly
> -
>
> Key: SLING-4043
> URL: https://issues.apache.org/jira/browse/SLING-4043
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Consider a property serialized as 
> {noformat}org.apache.sling.commons.log.pattern="\{0,date,-MM-dd 
> HH:mm:ss.SSS} {4} [{3}] {5}"{noformat}
> The value displayed by the JCR properties view is {noformat}{4} [{3}] 
> {5}{noformat}, while the value displayed when editing is 
> {noformat}\{0,date,-MM-dd HH:mm:ss.SSS} {4} [{3}] {5}{noformat}
> In fact, both the display and edit modes should work with the unescaped value 
> {noformat}{0,date,-MM-dd HH:mm:ss.SSS} {4} [{3}] {5}{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Sling IDE API - Refactoring

[Konrad Windszus]

In the context of https://issues.apache.org/jira/browse/SLING-4043 I had a 
closer look at the Sling IDE Tooling API again and made a new proposal on it in 
https://cwiki.apache.org/confluence/x/eAsjB.
That should solve several of the issues we had with the API in the past.
It would be good to hear some feedback on that, some parts are only roughly 
outlined up till now, especially the SerializationManager part seems to be a 
tricky one.
I would like to hear some feedback on the proposal before I go ahead and 
implement that in a dedicated feature branch on Github.
Thanks,
Konrad

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965749#comment-15965749
 ] 

Carsten Ziegeler commented on SLING-6777:
-

I agree, we should in general avoid long running sessions/resource resolvers. I 
can't see any bug in wrt this behaviour in the current code; the resource 
resolver is only closed on deactivate. It would be good to know the i18n and 
validation version used. This could also be a bug in the validation service 
holding a stale ResourceBundleProvider

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

[Justin Edelson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Edelson updated SLING-6778:
--
Attachment: SLING-6778.diff

updated diff

> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff, SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type {{myco/somethingelse}} 
> and that {{myco/something}} is the super type of {{myco/somethingelse}}.
> In order to create a model class associated with {{myco/somethingelse}} and 
> have that model class access the original class using the Delegate pattern, 
> it is quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = ResourceSuperType.class)
> private Something delegate;
> {code}
> Assuming you wanted the super type
> We could also support manually setting the resource type, i.e.
> {code}
> @Self @Via(value = “some/other/resourceType”, type = 
> ForcedResourceType.class)
> private Something delegate;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

[Justin Edelson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Edelson updated SLING-6778:
--
Description: 
Consider this interface:

{code}
public interface Something {

String getText();

String getOther();

}
{code}

With this model implementation:

{code}
@Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
"myco/something")
public class SomethingImpl implements Something {

@Inject
private String text;

@Inject
private String other;

public String getText() {
return text;
}
public String getOther() {
return other;
 }

}
{code}

And let's say that there is a resource with the type {{myco/somethingelse}} and 
that {{myco/something}} is the super type of {{myco/somethingelse}}.

In order to create a model class associated with {{myco/somethingelse}} and 
have that model class access the original class using the Delegate pattern, it 
is quite difficult to do so since you need to manually create a wrapping 
resource and then adapt that. I think we can facilitate this pattern through 
SLING-5739 and a new @Via provider.

The syntax would be something along the lines of

{code}
@Self @Via(type = ResourceSuperType.class)
private Something delegate;
{code}

Assuming you wanted the super type

We could also support manually setting the resource type, i.e.

{code}
@Self @Via(value = “some/other/resourceType”, type = 
ForcedResourceType.class)
private Something delegate;
{code}

  was:
Consider this interface:

{code}
public interface Something {

String getText();

String getOther();

}
{code}

With this model implementation:

{code}
@Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
"myco/something")
public class SomethingImpl implements Something {

@Inject
private String text;

@Inject
private String other;

public String getText() {
return text;
}
public String getOther() {
return other;
 }

}
{code}

And let's say that there is a resource with the type {{myco/somethingelse}} and 
that {{myco/something}} is the super type of {{myco/somethingelse}}.

In order to create a model class associated with {{myco/somethingelse}} and 
have that model class access the original class using the Delegate pattern, it 
is quite difficult to do so since you need to manually create a wrapping 
resource and then adapt that. I think we can facilitate this pattern through 
SLING-5739 and a new @Via provider.

The syntax would be something along the lines of

{code}
@Self @Via(type = SuperResourceType.class)
private Something delegate;
{code}

Assuming you wanted the super type

We could also support manually setting the resource type, i.e.

{code}
@Self @Via(value = “some/other/resourceType”, type = 
ForcedResourceType.class)
private Something delegate;
{code}


> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type {{myco/somethingelse}} 
> and that {{myco/something}} is the super type of {{myco/somethingelse}}.
> In order to create a model class associated with {{myco/somethingelse}} and 
> have that model class access the original class using the Delegate pattern, 
> it is quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = ResourceSuperType.class)
> private Something delegate;
> {code}
> Assuming you wanted the 

[jira] [Commented] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965717#comment-15965717
 ] 

Justin Edelson commented on SLING-6778:
---

nice catch [~royteeuwen]

> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type {{myco/somethingelse}} 
> and that {{myco/something}} is the super type of {{myco/somethingelse}}.
> In order to create a model class associated with {{myco/somethingelse}} and 
> have that model class access the original class using the Delegate pattern, 
> it is quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = SuperResourceType.class)
> private Something delegate;
> {code}
> Assuming you wanted the super type
> We could also support manually setting the resource type, i.e.
> {code}
> @Self @Via(value = “some/other/resourceType”, type = 
> ForcedResourceType.class)
> private Something delegate;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Alexander Klimetschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965637#comment-15965637
 ] 

Alexander Klimetschek edited comment on SLING-6777 at 4/12/17 10:06 AM:


At first, I can only see this happening on bundle restarts or component 
restarts due to configuration changes (i.e. the {{JcrResourceBundleProvider}} 
restarting), while some request using the {{ValidationService}} is still being 
processed and still has a reference on the closing provider. Where I don't 
think much can be done. It's a somewhat typical issue you often get during 
restarts.

Is there any indication this is happening frequently instead of a one-off 
situation and persists after it has happened once?

{quote}we should handle closed resolvers in Validation gracefully{quote}
Note that Validation does not see the resolver here, so validation could not 
handle this directly.

{quote}Should we switch to short running resolver in i18n{quote}
Seems possible. It is long running because it was originally used for JCR 
observation. But since SLING-4186 and [this 
change|https://github.com/apache/sling/commit/a30af93968405819c1b607e89ff7b5371f74533d],
 it leverages the Sling Resource Change stuff, which I believe has its own 
listener session(s).


was (Author: alexander.klimetschek):
At first, I can only see this happening on bundle restarts or component 
restarts due to configuration changes (i.e. the {{JcrResourceBundleProvider}} 
restarting), while some request using the {{ValidationService}} is still being 
processed and still has a reference on the closing provider. Where I don't 
think much can be done. It's a somewhat typical issue you often get during 
restarts.

Is there any indication this is happening frequently instead of a one-off 
situation and persists once it has happened once?

{quote}we should handle closed resolvers in Validation gracefully{quote}
Note that Validation does not see the resolver here, so validation could not 
handle this directly.

{quote}Should we switch to short running resolver in i18n{quote}
Seems possible. It is long running because it was originally used for JCR 
observation. But since SLING-4186 and [this 
change|https://github.com/apache/sling/commit/a30af93968405819c1b607e89ff7b5371f74533d],
 it leverages the Sling Resource Change stuff, which I believe has its own 
listener session(s).

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Alexander Klimetschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965637#comment-15965637
 ] 

Alexander Klimetschek commented on SLING-6777:
--

At first, I can only see this happening on bundle restarts or component 
restarts due to configuration changes (i.e. the {{JcrResourceBundleProvider}} 
restarting), while some request using the {{ValidationService}} is still being 
processed and still has a reference on the closing provider. Where I don't 
think much can be done. It's a somewhat typical issue you often get during 
restarts.

Is there any indication this is happening frequently instead of a one-off 
situation and persists once it has happened once?

{quote}we should handle closed resolvers in Validation gracefully{quote}
Note that Validation does not see the resolver here, so validation could not 
handle this directly.

{quote}Should we switch to short running resolver in i18n{quote}
Seems possible. It is long running because it was originally used for JCR 
observation. But since SLING-4186 and [this 
change|https://github.com/apache/sling/commit/a30af93968405819c1b607e89ff7b5371f74533d],
 it leverages the Sling Resource Change stuff, which I believe has its own 
listener session(s).

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-6739:
---
Description: 
Currently sling.event contains both API and implementation. In order to support 
different implementation variants it would be good to have two separate 
bundles, one containing just the API and one with the (current) implementation. 
I would suggest to create

bundles/extensions/event/api
bundles/extensions/event/resource

and to remove the current

bundles/extensions/event

  was:
Currently sling.event contains both API and implementation. In order to support 
different implementation variants it would be good to have two separate 
bundles, one containing just the API and one with the (current) implementation. 
I would suggest to create

bundles/extensions/event-api
bundles/extensions/event-impl

and to remove the current

bundles/extensions/event


> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event/api
> bundles/extensions/event/resource
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-6739:
---
Summary: split sling.event into event.api and event.resource (was: 
event.impl)  (was: split sling.event into event.api and event.impl)

> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6296) DefaultThreadPool causes warning when minPoolSize == 0

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965565#comment-15965565
 ] 

Konrad Windszus edited comment on SLING-6296 at 4/12/17 8:52 AM:
-

Fixed with [r1791093|http://svn.apache.org/r1791093].


was (Author: kwin):
This does no longer apply since {{ThreadExpiringThreadPool}} has been removed 
with SLING-6261.

> DefaultThreadPool causes warning when minPoolSize == 0
> --
>
> Key: SLING-6296
> URL: https://issues.apache.org/jira/browse/SLING-6296
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Rob Ryan
>Assignee: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
>
> DefaultThreadPool inappropriately emits a warning when a pool has a min pool 
> size of 0.
> A min pool size of 0 is supported by the downstream ThreadExpiringThreadPool, 
> and is logically useful when 'empty' is a reasonable size of a pool, e.g. 
> when no work is apriori expected for the pool.
> The code in question is:
>  // Min pool size
> if (this.configuration.getMinPoolSize() < 1) {
> this.configuration.setMinPoolSize(1);
> this.logger.warn("min-pool-size < 1 for pool \"" + this.name + 
> "\". Set to 1");
> }
> The downstream code in ThreadExpiringThreadPool only enforces this value is 
> >= 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6296) DefaultThreadPool causes warning when minPoolSize == 0

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned SLING-6296:
--

Assignee: Konrad Windszus

> DefaultThreadPool causes warning when minPoolSize == 0
> --
>
> Key: SLING-6296
> URL: https://issues.apache.org/jira/browse/SLING-6296
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Rob Ryan
>Assignee: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
>
> DefaultThreadPool inappropriately emits a warning when a pool has a min pool 
> size of 0.
> A min pool size of 0 is supported by the downstream ThreadExpiringThreadPool, 
> and is logically useful when 'empty' is a reasonable size of a pool, e.g. 
> when no work is apriori expected for the pool.
> The code in question is:
>  // Min pool size
> if (this.configuration.getMinPoolSize() < 1) {
> this.configuration.setMinPoolSize(1);
> this.logger.warn("min-pool-size < 1 for pool \"" + this.name + 
> "\". Set to 1");
> }
> The downstream code in ThreadExpiringThreadPool only enforces this value is 
> >= 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6296) DefaultThreadPool causes warning when minPoolSize == 0

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved SLING-6296.

Resolution: Fixed

> DefaultThreadPool causes warning when minPoolSize == 0
> --
>
> Key: SLING-6296
> URL: https://issues.apache.org/jira/browse/SLING-6296
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Rob Ryan
> Fix For: Commons Threads 3.2.8
>
>
> DefaultThreadPool inappropriately emits a warning when a pool has a min pool 
> size of 0.
> A min pool size of 0 is supported by the downstream ThreadExpiringThreadPool, 
> and is logically useful when 'empty' is a reasonable size of a pool, e.g. 
> when no work is apriori expected for the pool.
> The code in question is:
>  // Min pool size
> if (this.configuration.getMinPoolSize() < 1) {
> this.configuration.setMinPoolSize(1);
> this.logger.warn("min-pool-size < 1 for pool \"" + this.name + 
> "\". Set to 1");
> }
> The downstream code in ThreadExpiringThreadPool only enforces this value is 
> >= 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6296) DefaultThreadPool causes warning when minPoolSize == 0

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965565#comment-15965565
 ] 

Konrad Windszus commented on SLING-6296:


This does no longer apply since {{ThreadExpiringThreadPool}} has been removed 
with SLING-6261.

> DefaultThreadPool causes warning when minPoolSize == 0
> --
>
> Key: SLING-6296
> URL: https://issues.apache.org/jira/browse/SLING-6296
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Rob Ryan
> Fix For: Commons Threads 3.2.8
>
>
> DefaultThreadPool inappropriately emits a warning when a pool has a min pool 
> size of 0.
> A min pool size of 0 is supported by the downstream ThreadExpiringThreadPool, 
> and is logically useful when 'empty' is a reasonable size of a pool, e.g. 
> when no work is apriori expected for the pool.
> The code in question is:
>  // Min pool size
> if (this.configuration.getMinPoolSize() < 1) {
> this.configuration.setMinPoolSize(1);
> this.logger.warn("min-pool-size < 1 for pool \"" + this.name + 
> "\". Set to 1");
> }
> The downstream code in ThreadExpiringThreadPool only enforces this value is 
> >= 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6261) ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved SLING-6261.

Resolution: Fixed

Fixed in [r1791091|http://svn.apache.org/r1791091].

> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a 
> {{RuntimeException}} with message "Kill old thread" is used in 
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a 
> suspension of the thread when debugging with Eclipse (as since Neon JDT will 
> suspend the thread on all uncaught exceptions). More information is available 
> in 
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
>  There should be a different mechanism to kill the thread than an uncaught 
> exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6261) ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned SLING-6261:
--

Assignee: Konrad Windszus

> ThreadExpiringThreadPool is relying on uncaught exceptions to kill threads
> --
>
> Key: SLING-6261
> URL: https://issues.apache.org/jira/browse/SLING-6261
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Threads 3.2.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Commons Threads 3.2.8
>
> Attachments: SLING-6261-v01.patch
>
>
> In {{o.a.s.commons.threads.impl.ThreadExpiringThreadPool}} a 
> {{RuntimeException}} with message "Kill old thread" is used in 
> {{checkMaxThreadAge(final Thread thread)}}. This leads by default to a 
> suspension of the thread when debugging with Eclipse (as since Neon JDT will 
> suspend the thread on all uncaught exceptions). More information is available 
> in 
> http://stackoverflow.com/questions/6290470/eclipse-debugger-always-blocks-on-threadpoolexecutor-without-any-obvious-excepti.
>  There should be a different mechanism to kill the thread than an uncaught 
> exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Oliver Lietz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965552#comment-15965552
 ] 

Oliver Lietz commented on SLING-6777:
-

The error was reported by a client and I don't have much more information other 
than {{ValidationService}} is used in a (Sling-) POST-Servlet.
Whatever the root issue is (suspecting _i18n_ also), we should handle closed 
resolvers in Validation gracefully.

I never had good experience with long running resource resolvers and try to 
avoid whenever possible. Should we switch to short running resolver in _i18n_ 
(opening/closing when used or per thread)? WDYT, [~cziegeler]?

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[VOTE] Release Apache Sling Event API 1.0.0 (initial release)

[Stefan Egli]

Hi,

This is about the first (API) part of splitting Sling Event into two
bundles (API and Impl). Since it is an initial release it might make sense
to review the pom extra this time. This split is tracked in:

https://issues.apache.org/jira/browse/SLING-6739

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

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1686 /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.

Cheers,
Stefan

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965548#comment-15965548
 ] 

Stefan Egli commented on SLING-6739:


h6. step 10: sling.event.api 1.0.0 released (staging repo 
[1686|https://repository.apache.org/content/repositories/orgapachesling-1686/]),
 vote pending

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965530#comment-15965530
 ] 

Stefan Egli commented on SLING-6739:


h6. step 9: event/api/pom.xml : port-java8 and surefire-plugin removed 
(http://svn.apache.org/viewvc?rev=1791086=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965521#comment-15965521
 ] 

Stefan Egli commented on SLING-6739:


h6. step 8: event/api/pom.xml : site.jira.version.id set to Event API 1.0.0 
(http://svn.apache.org/viewvc?rev=1791084=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-6739:
---
Fix Version/s: Event API 1.0.0

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6751) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz resolved SLING-6751.
-
Resolution: Done

[r1791083|https://svn.apache.org/r1791083]

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6751
> URL: https://issues.apache.org/jira/browse/SLING-6751
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JavaScript 2.0.32
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6779) [htl-maven-plugin] No warning / error on wrong options

[Feike Visser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Feike Visser updated SLING-6779:

Description: 
I have the following code 

{code}
${currentPage.title @ contex = 'scriptString'}
{code}

No warning or error is given for the wrong option @ contex

  was:
I have the following code 

{code}

${currentPage.title @ contex = 'scriptString'}

{code}

No warning or error is given for the wrong option @ contex


> [htl-maven-plugin] No warning / error on wrong options
> --
>
> Key: SLING-6779
> URL: https://issues.apache.org/jira/browse/SLING-6779
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: HTL Maven Plugin 1.0.6
>Reporter: Feike Visser
>
> I have the following code 
> {code}
> ${currentPage.title @ contex = 'scriptString'}
> {code}
> No warning or error is given for the wrong option @ contex



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965513#comment-15965513
 ] 

Konrad Windszus commented on SLING-6777:


[~olli] The service resource resolver used by i18n is opened in the 
{{activate}} and closed in the {{deactivate}}. So how did you trigger this 
exception exactly? I wonder if this rather is a bug in Sling i18n.

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6779) [htl-maven-plugin] No warning / error on wrong options

[Feike Visser (JIRA)]

Feike Visser created SLING-6779:
---

 Summary: [htl-maven-plugin] No warning / error on wrong options
 Key: SLING-6779
 URL: https://issues.apache.org/jira/browse/SLING-6779
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: HTL Maven Plugin 1.0.6
Reporter: Feike Visser


I have the following code 

{code}

${currentPage.title @ contex = 'scriptString'}

{code}

No warning or error is given for the wrong option @ contex



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6751) Migrate to OSGi R6 annotations

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz reassigned SLING-6751:
---

Assignee: Oliver Lietz

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6751
> URL: https://issues.apache.org/jira/browse/SLING-6751
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JavaScript 2.0.32
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz updated SLING-6777:

Component/s: Validation

> ValidationServiceImpl breaks when hitting closed resolver for resource 
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
>   at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
>   at 
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6778) [Sling Models] Support Delegate Pattern for Models adapted from interfaces

[Roy Teeuwen (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965489#comment-15965489
 ] 

Roy Teeuwen commented on SLING-6778:


Hey [~justinedelson],

Please change your annotation name from SuperResourceType to ResourceSuperType, 
it is also sling:resourceSuperType, so this would make it very confusing, I 
have seen developers try and use sling:superResourceType, which of course does 
not work

Greets,
Roy

> [Sling Models] Support Delegate Pattern for Models adapted from interfaces
> --
>
> Key: SLING-6778
> URL: https://issues.apache.org/jira/browse/SLING-6778
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-6778.diff
>
>
> Consider this interface:
> {code}
> public interface Something {
>   
>   String getText();
> String getOther();
> }
> {code}
> With this model implementation:
> {code}
> @Model(adaptable = Resource.class, adapter = Something.class, resourceType = 
> "myco/something")
> public class SomethingImpl implements Something {
>   
>   @Inject
>   private String text;
> @Inject
> private String other;
>   public String getText() {
>   return text;
>   }
> public String getOther() {
> return other;
>  }
> }
> {code}
> And let's say that there is a resource with the type {{myco/somethingelse}} 
> and that {{myco/something}} is the super type of {{myco/somethingelse}}.
> In order to create a model class associated with {{myco/somethingelse}} and 
> have that model class access the original class using the Delegate pattern, 
> it is quite difficult to do so since you need to manually create a wrapping 
> resource and then adapt that. I think we can facilitate this pattern through 
> SLING-5739 and a new @Via provider.
> The syntax would be something along the lines of
> {code}
> @Self @Via(type = SuperResourceType.class)
> private Something delegate;
> {code}
> Assuming you wanted the super type
> We could also support manually setting the resource type, i.e.
> {code}
> @Self @Via(value = “some/other/resourceType”, type = 
> ForcedResourceType.class)
> private Something delegate;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6776) Rename ValidationContextImpl to ValidatorContextImpl

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved SLING-6776.

Resolution: Fixed

Fixed in [r1791074|http://svn.apache.org/r1791074].

> Rename ValidationContextImpl to ValidatorContextImpl
> 
>
> Key: SLING-6776
> URL: https://issues.apache.org/jira/browse/SLING-6776
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Affects Versions: Validation 1.0.0
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation Core 1.0.2
>
>
> {{ValidationContextImpl}} implements {{ValidatorContext}} and should be named 
> accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6776) Rename ValidationContextImpl to ValidatorContextImpl

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned SLING-6776:
--

Assignee: Konrad Windszus

> Rename ValidationContextImpl to ValidatorContextImpl
> 
>
> Key: SLING-6776
> URL: https://issues.apache.org/jira/browse/SLING-6776
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Affects Versions: Validation 1.0.0
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation Core 1.0.2
>
>
> {{ValidationContextImpl}} implements {{ValidatorContext}} and should be named 
> accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6776) Rename ValidationContextImpl to ValidatorContextImpl

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-6776:
---
Fix Version/s: Validation Core 1.0.2

> Rename ValidationContextImpl to ValidatorContextImpl
> 
>
> Key: SLING-6776
> URL: https://issues.apache.org/jira/browse/SLING-6776
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Affects Versions: Validation 1.0.0
>Reporter: Oliver Lietz
> Fix For: Validation Core 1.0.2
>
>
> {{ValidationContextImpl}} implements {{ValidatorContext}} and should be named 
> accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[RESULT] [VOTE] Release Apache Sling Validation version 1.0.0

[Konrad Windszus]

Hi, 
The vote has passed with the following result : 
+1 (binding): Carsten, Stefan and myself

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

Konrad

Re: [VOTE] Release Apache Sling Validation version 1.0.0

[Konrad Windszus]

+1

> On 5. Apr 2017, at 15:50, Konrad Windszus  wrote:
> 
> Hi, 
> This is first release of Apache Sling Validation, namely of the modules 
> validation.api, validation.core and validation.test-services.
> 
> We solved quite some issues in this first release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12328980
> There are two outstanding issues:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true=hide=component+%3D+Validation+AND+project+%3D+SLING+AND+resolution+%3D+Unresolved+ORDER+BY+priority+DESC
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1684/
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh 
> Usage:
> sh check_staged_release.sh 1684 /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.