[jira] [Commented] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL is not properly supported

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6392:
-

[~kwin] Yes, this needs to be done in the OSGi installer core. The provider 
should have no knowledge of what it is delivering, it just detects a change of 
a binary at a given path.
The installer core then needs to execute some logic after the transform phase 
as you mention and then do the right thing. I guess the best way to start this 
work is having a test case in the integration tests

> OSGi Installer: Symbolic name changes on a resource keeping the same URL is 
> not properly supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6396) Set project final name as default model archive name

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6396.
-
Resolution: Fixed

Thanks for your patch [~royteeuwen]. It's applied in rev 1774129

> Set project final name as default model archive name
> 
>
> Key: SLING-6396
> URL: https://issues.apache.org/jira/browse/SLING-6396
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Slingstart Maven Plugin 1.7.0
>
>
> Roy Teeuwen created a pull request to
> set the final name as the default name for the archive:
> https://github.com/apache/sling/pull/192



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6396) Set project final name as default model archive name

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6396:
---

 Summary: Set project final name as default model archive name
 Key: SLING-6396
 URL: https://issues.apache.org/jira/browse/SLING-6396
 Project: Sling
  Issue Type: Improvement
  Components: Maven Plugins and Archetypes
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Slingstart Maven Plugin 1.7.0


Roy Teeuwen created a pull request to
set the final name as the default name for the archive:
https://github.com/apache/sling/pull/192



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6284) PreparePackageMojo.testSubsystemBaseGeneration often fails on Jenkins

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6284:
-

[~rombert] Is there anything else we can/should do here?

> PreparePackageMojo.testSubsystemBaseGeneration often fails on Jenkins
> -
>
> Key: SLING-6284
> URL: https://issues.apache.org/jira/browse/SLING-6284
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.6.0
>Reporter: Robert Munteanu
>  Labels: sling-IT
> Fix For: Slingstart Maven Plugin 1.7.0
>
>
> The test seems to fail every other run. The error is
> {noformat}org.apache.maven.plugin.MojoExecutionException: Problem creating 
> subsystem .esa file 
> /tmp/PreparePackageMojoTest1894864848680720292/slingstart-tmp/test1.subsystem-base
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
>   at java.nio.file.Files.newByteChannel(Files.java:317)
>   at java.nio.file.Files.newByteChannel(Files.java:363)
>   at 
> java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:380)
>   at java.nio.file.Files.newInputStream(Files.java:108)
>   at java.nio.file.Files.copy(Files.java:2895)
>   at 
> org.apache.sling.maven.slingstart.PreparePackageMojo.createSubsystemBaseFile(PreparePackageMojo.java:351)
>   at 
> org.apache.sling.maven.slingstart.PreparePackageMojo.buildSubsystemBase(PreparePackageMojo.java:244)
>   at 
> org.apache.sling.maven.slingstart.PreparePackageMojo.buildContentsMap(PreparePackageMojo.java:224)
>   at 
> org.apache.sling.maven.slingstart.PreparePackageMojo.prepareGlobal(PreparePackageMojo.java:130)
>   at 
> org.apache.sling.maven.slingstart.PreparePackageMojo.execute(PreparePackageMojo.java:120)
>   at 
> org.apache.sling.maven.slingstart.PreparePackageMojoTest.testSubsystemBaseGeneration(PreparePackageMojoTest.java:176){noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Summary: OSGi Installer: Symbolic name changes on a resource keeping the 
same URL is not properly supported  (was: JCR Installer: Symbolic name changes 
on an existing bundle file is not properly supported)

> OSGi Installer: Symbolic name changes on a resource keeping the same URL is 
> not properly supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6395) Reduce cost of JcrResourceBundleProvider.onChange()

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6395.
-
Resolution: Fixed

Thanks for your patch [~mreutegg]. It's applied

> Reduce cost of JcrResourceBundleProvider.onChange()
> ---
>
> Key: SLING-6395
> URL: https://issues.apache.org/jira/browse/SLING-6395
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Reporter: Marcel Reutegger
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: i18n 2.5.6
>
> Attachments: SLING-6395.patch
>
>
> JcrResourceBundleProvider.onChange() is somewhat expensive because it 
> refreshes the resource resolver in every call to isDictionaryResource(). It 
> is sufficient to call it once in onChange().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6395) Reduce cost of JcrResourceBundleProvider.onChange()

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6395:
---

Assignee: Carsten Ziegeler

> Reduce cost of JcrResourceBundleProvider.onChange()
> ---
>
> Key: SLING-6395
> URL: https://issues.apache.org/jira/browse/SLING-6395
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Reporter: Marcel Reutegger
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: i18n 2.5.6
>
> Attachments: SLING-6395.patch
>
>
> JcrResourceBundleProvider.onChange() is somewhat expensive because it 
> refreshes the resource resolver in every call to isDictionaryResource(). It 
> is sufficient to call it once in onChange().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6392) JCR Installer: Symbolic name changes on an existing bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6392:


After thinking about it a littlebit more, this should probably be implemented 
in the OSGi installer rather than in each provider separately.

The installer should take care, that when for the same url the entity id has 
changed (i.e. there are still installed entities with a different id but the 
same url), any previously installed entities having the same url should be 
uninstalled.
This step can only happen after {{transformResources()}} (because only there 
the entity id of the new resource is determined) but before {{computeTasks()}}.
That way there is no change on the persisted resource list (i.e. url stays the 
path as previously) and this has to be implemented only once.

> JCR Installer: Symbolic name changes on an existing bundle file is not 
> properly supported
> -
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6395) Reduce cost of JcrResourceBundleProvider.onChange()

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated SLING-6395:

Flags: Patch

> Reduce cost of JcrResourceBundleProvider.onChange()
> ---
>
> Key: SLING-6395
> URL: https://issues.apache.org/jira/browse/SLING-6395
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: i18n 2.5.6
>
> Attachments: SLING-6395.patch
>
>
> JcrResourceBundleProvider.onChange() is somewhat expensive because it 
> refreshes the resource resolver in every call to isDictionaryResource(). It 
> is sufficient to call it once in onChange().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6395) Reduce cost of JcrResourceBundleProvider.onChange()

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated SLING-6395:

Attachment: SLING-6395.patch

Attached patch with proposed changes.

> Reduce cost of JcrResourceBundleProvider.onChange()
> ---
>
> Key: SLING-6395
> URL: https://issues.apache.org/jira/browse/SLING-6395
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: i18n 2.5.6
>
> Attachments: SLING-6395.patch
>
>
> JcrResourceBundleProvider.onChange() is somewhat expensive because it 
> refreshes the resource resolver in every call to isDictionaryResource(). It 
> is sufficient to call it once in onChange().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6395) Reduce cost of JcrResourceBundleProvider.onChange()

[Marcel Reutegger (JIRA)]

Marcel Reutegger created SLING-6395:
---

 Summary: Reduce cost of JcrResourceBundleProvider.onChange()
 Key: SLING-6395
 URL: https://issues.apache.org/jira/browse/SLING-6395
 Project: Sling
  Issue Type: Improvement
  Components: i18n
Reporter: Marcel Reutegger
Priority: Minor
 Fix For: i18n 2.5.6


JcrResourceBundleProvider.onChange() is somewhat expensive because it refreshes 
the resource resolver in every call to isDictionaryResource(). It is sufficient 
to call it once in onChange().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

The point is _additional_ parameter. The request already says "@Encrypted" and 
indicates what it wants. Adding a second one, with more arbitrary names, and 
which also works if left out, will not help the situation IMO.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6187:
---

bq. Why should an API client know that certain fields are handled by a post 
processor and also pass another parameter where it has to know that the set is 
called xyz? Note that addressing the profile is not different from addressing 
individual post processor names, it is an implementation detail.

By this logic, the operation names are also implementation details. I disagree. 
The name is a abstract concept which is implemented by some particular thing 
with that name.

bq. It should behave like an extra sling post operation, which I believe would 
fail if not present based on the operation name aka suffix name or prefix 
"trick" as in my proposal above.

So is your specific concern that the parameter name refers to "post 
processors"? What if the POST contained something like:

:requiredFeatures=encryptedProperties,audit

Where each feature is just an name representing some capability. For now, this 
would map to post processors, but that could be changed in the future (for 
example, encryptedProperties could be implemented by the Post Servlet directly 
and that feature would always be available).

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

FWIW: All approaches require changes to the requests made by clients anyway.

Except for this one: have the post servlet detect suffixes, have post 
processors indicate their suffixes in a service property, and make it fail if 
no such processor is found.

Suffix detection means:
- there is one property named "xyz"
- AND there is another "xyz@"

Then normal properties containing a @ are still possible. However, all post 
processors handling suffixes are required to be changed and advertise their 
suffix, otherwise their requests will fail.

Upside would be that the request signature would not change at all.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-6187 at 12/14/16 1:26 AM:


My view now is that a post processor that relies on the @Suffix mechanism where 
the properties would be written differently, without failure, if the processor 
is not active, is a problem of the processor. And slightly so for Sling 
encouraging this fragile approach. The Sling Post servlet should have a 
mechanism like I outlined above that gives a clear behavior, without a default 
behavior fallback, without any implementation specific references the client 
has to know about.

Why should an API client know that certain fields are handled by a post 
processor and also pass another parameter where it has to know that the set is 
called xyz? Note that addressing the profile is not different from addressing 
individual post processor names, it is an implementation detail.

It should behave like an extra sling post operation, which I believe would fail 
if not present based on the _operation name_ aka _suffix name_ or prefix 
"trick" as in my proposal above.


was (Author: alexander.klimetschek):
My view now is that a post processor that relies on the @Suffix mechanism where 
the properties would be written differently, without failure, if the processor 
is not active, is a problem of the processor. And slightly so for Sling 
encouraging this fragile approach. The Sling Post servlet should have a 
mechanism like I outlined above that gives a clear behavior, without a default 
behavior fallback, without any implementation specific references the client 
has to know about.

Why should an API client know that certain fields are handled by a post 
processor and also pass another parameter where it has to know that the set is 
called xyz? Note that addressing the profile is not different from addressing 
individual post processor names, it is an implementation detail.

It should behave like an extra sling post operation, which I believe would fail 
if not present, but as part of the normal sling post servlet mixed with normal 
properties.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

My view now is that a post processor that relies on the @Suffix mechanism where 
the properties would be written differently, without failure, if the processor 
is not active, is a problem of the processor. And slightly so for Sling 
encouraging this fragile approach. The Sling Post servlet should have a 
mechanism like I outlined above that gives a clear behavior, without a default 
behavior fallback, without any implementation specific references the client 
has to know about.

Why should an API client know that certain fields are handled by a post 
processor and also pass another parameter where it has to know that the set is 
called xyz? Note that addressing the profile is not different from addressing 
individual post processor names, it is an implementation detail.

It should behave like an extra sling post operation, which I believe would fail 
if not present, but as part of the normal sling post servlet mixed with normal 
properties.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6187:
--
Attachment: SLING-6187-profile.diff

updated the patch slightly to permit multiple profiles with the same name, all 
of which must pass for the request to be allowed

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6187:
---

[~alexander.klimetschek] I'm trying to solve this problem in a generic way that 
can be reused across multiple PostProcessors (or, really based on 
[~bdelacretaz]'s feedback multiple 'sets' of PostProcessors). Certainly the AEM 
issue can be solved in a different way by changing how the encryption post 
processing is done to *not* rely on an @Suffix param being handled. That would 
be a very AEM specific (and likely non-backwards compatible change) which we 
should discuss in the proper context.

Personally, I think the functionality described in this issue is important 
regardless of the specifics of the AEM encryption issue.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

What about this alternative?

- these encrypted properties are prefixed with a value like j_ so they do not 
get handled by the normal SlingPostProcessor (or another prefix, configurable 
as per 
https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#omitting-some-parameters
 )
- that post processor in question only handles the ones with prefix to be sure 
they don't get written without it and throws an error otherwise (forces clients 
to change the request, alternatively a warning)
- some new mechanism needs to be added to make the reuqest fail if these 
properties were not processed so the original request can fail if that post 
processor is offline

IMO this needs to be solved on the interface layer (i.e. the request parameters 
etc.), and not be depending on the implementation (who knows, maybe we turn 
such a post processor into a core feature at some point).

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6187:
--
Attachment: SLING-6187-profile.diff

Attached an updated patch. The parameter name is now {{:postProcessorProfile}}.



> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Updating our parent pom

[venkatesha murthy]

I have been following supporting Thymeleaf as an additional scripting
engine supported by Sling. I just wanted to understand the difference
between sightly (AEM HTL) with this scripting support and  what is the
difference PRIMARY between these two scripting languages?.

Any help is really appreciated.

Regards
Venky

On Mon, Jul 18, 2016 at 6:34 AM, Oliver Lietz  wrote:

> On Monday 18 July 2016 11:11:25 Carsten Ziegeler wrote:
> > > On Thursday 14 July 2016 21:43:45 Carsten Ziegeler wrote:
> [...]
> >
> > I've updated the parent pom as outlined above, including #11.
> >
> > It would be great if everyone can have a look before we start a release
>
> LGTM, building Scripting Thymeleaf (which is uses R6 features) with 27-
> SNAPSHOT results in same output except import range for Servlets.
>
> How about adding javax.inject to parent?
>
> Do we still need the plugin configuration for maven-bundle-plugin?
>
> O.
>
> > Thanks
> >
> >  Carsten
>
>

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on an existing bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Component/s: Installer

> JCR Installer: Symbolic name changes on an existing bundle file is not 
> properly supported
> -
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on an existing bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Description: 
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
correctly being picked up by the JcrInstaller or FileInstaller and deployed in 
Apache Felix. Now the symbolic name has been changed to {{B}} and the updated 
JAR has been deployed to the same location in the JCR  
{{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.
It would actually be expected that {{A}} is uninstalled, while {{B}} is getting 
installed!


Such a change can happen if you use the {{maven-bundle-plugin}} with a default 
configuration and you just change the groupId of the underlying maven project. 
That will not affect the finalName of the artifact (by default artifactId) but 
the symbolic name of the bundle (see 
http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).

  was:
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
correctly being picked up by the JcrInstaller or FileInstaller and deployed in 
Apache Felix. Now the symbolic name has been changed to {{B}} and the updated 
JAR has been deployed to the same location in the JCR  
{{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.
It would actually be expected that {{A}} is uninstalled, while {{B}} is getting 
installed!


Such a change can happen if you use the {{maven-bundle-plugin}} with a default 
configuration and you change the groupId of the underlying maven project. That 
will not affect the finalName of the artifact (by default artifactId) but the 
symbolic name of the bundle (see 
http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).


> JCR Installer: Symbolic name changes on an existing bundle file is not 
> properly supported
> -
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on an existing bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Description: 
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
correctly being picked up by the JcrInstaller or FileInstaller and deployed in 
Apache Felix. Now the symbolic name has been changed to {{B}} and the updated 
JAR has been deployed to the same location in the JCR  
{{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.
It would actually be expected that {{A}} is uninstalled, while {{B}} is getting 
installed!


Such a change can happen if you use the {{maven-bundle-plugin}} with a default 
configuration and you change the groupId of the underlying maven project. That 
will not affect the finalName of the artifact (by default artifactId) but the 
symbolic name of the bundle (see 
http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).

  was:
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
correctly being picked up by the JcrInstaller or FileInstaller and deployed in 
Apache Felix. Now the symbolic name has been changed to {{B}} and the updated 
JAR has been deployed to the same location in the JCR  
{{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.
It would actually be expected that {{A}} is uninstalled, while {{B}} is getting 
installed!


> JCR Installer: Symbolic name changes on an existing bundle file is not 
> properly supported
> -
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on an existing bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Summary: JCR Installer: Symbolic name changes on an existing bundle file is 
not properly supported  (was: JCR Installer: Symbolic name changes on a bundle 
file is not properly supported)

> JCR Installer: Symbolic name changes on an existing bundle file is not 
> properly supported
> -
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on a bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Description: 
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
correctly being picked up by the JcrInstaller or FileInstaller and deployed in 
Apache Felix. Now the symbolic name has been changed to {{B}} and the updated 
JAR has been deployed to the same location in the JCR  
{{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.
It would actually be expected that {{A}} is uninstalled, while {{B}} is getting 
installed!

  was:
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
the updated JAR deployed to the same JCR location  
{{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.


> JCR Installer: Symbolic name changes on a bundle file is not properly 
> supported
> ---
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on a bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Affects Version/s: (was: Installer Core 3.6.8)
   File Installer 1.1.2

> JCR Installer: Symbolic name changes on a bundle file is not properly 
> supported
> ---
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Installer 3.1.18, File Installer 1.1.2
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
> deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
> the updated JAR deployed to the same JCR location  
> {{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-6392) JCR Installer: Symbolic name changes on a bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6392 at 12/13/16 5:26 PM:
--

The reason for that is that 
{{o.a.s.installer.provider.jcr.impl.FileNodeConverter}} return in its convert 
method a {{InstallableResource}} with an id equal to the path. This is for sure 
not uniquely identifying a bundle, because the path may stay the same although 
the symbolic bundle name may change. It would be good to evaluate the manifest 
header in case you are dealing with a bundle and to at least include the 
symbolic name in the {{InstallableResource}} id. That is necessary because 
based on the ID it is determined whether a bundle has been remove/added or 
upgraded.
[~cziegeler] You are most familiar with the code, does the change of the 
{{InstallableResource.id}} sound reasonable to you? What about compatibility if 
we now change the id?


was (Author: kwin):
The reason for that is that 
{{o.a.s.installer.provider.jcr.impl.FileNodeConverter}} return 
{{InstallableResource}} with an id equal to the path. This is for sure not 
uniquely identifying a bundle, because the path may stay the same although the 
symbolic bundle name may change. It would be good to evaluate the manifest 
header in case you are dealing with a bundle and to at least include the 
symbolic name in the {{InstallableResource}} id. That is necessary because 
based on the ID it is determined whether a bundle has been remove/added or 
upgraded.
[~cziegeler] You are most familiar with the code, does the change of the 
{{InstallableResource.id}} sound reasonable to you? What about compatibility if 
we now change the id?

> JCR Installer: Symbolic name changes on a bundle file is not properly 
> supported
> ---
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Installer Core 3.6.8, JCR Installer 3.1.18
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
> deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
> the updated JAR deployed to the same JCR location  
> {{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6392) JCR Installer: Symbolic name changes on a bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6392:


The reason for that is that 
{{o.a.s.installer.provider.jcr.impl.FileNodeConverter}} return 
{{InstallableResource}} with an id equal to the path. This is for sure not 
uniquely identifying a bundle, because the path may stay the same although the 
symbolic bundle name may change. It would be good to evaluate the manifest 
header in case you are dealing with a bundle and to at least include the 
symbolic name in the {{InstallableResource}} id. That is necessary because 
based on the ID it is determined whether a bundle has been remove/added or 
upgraded.
[~cziegeler] You are most familiar with the code, does the change of the 
{{InstallableResource.id}} sound reasonable to you? What about compatibility if 
we now change the id?

> JCR Installer: Symbolic name changes on a bundle file is not properly 
> supported
> ---
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Installer Core 3.6.8, JCR Installer 3.1.18
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
> deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
> the updated JAR deployed to the same JCR location  
> {{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

[~fmeschbe] The problem is if you have an important "add-on" post processor, 
for example one that encrypts properties server side before storing them in the 
JCR, and for some reason it's not active (bundle restarting etc.). Since it's 
"add-on", it would happily store the unprocessed (e.g. unencrypted) value and 
return without an error.

Maybe the source of the issue is the add-on character of such a post processor 
as in the encryption case. If it would be something that does not work at all 
if the post processor (or whatever pluggable interface) is not found, you 
automatically get an error.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6394) SlingAuthenticatior#getAnonymousResolver doesn't take in consideration vanityPath

[Antonio Sanso (JIRA)]

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

Antonio Sanso resolved SLING-6394.
--
Resolution: Won't Fix

resolving as won't fix if this is by design.

thanks [~fmeschbe]

> SlingAuthenticatior#getAnonymousResolver doesn't take in consideration 
> vanityPath
> -
>
> Key: SLING-6394
> URL: https://issues.apache.org/jira/browse/SLING-6394
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Reporter: Antonio Sanso
>
> SlingAuthenticatior#getAnonymousResolver doesn't take in consideration 
> vanityPath . This leads to cases where a resource called with a vanityPath 
> rather then the real path is considered not existing.
>  Test case to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6394) SlingAuthenticatior#getAnonymousResolver doesn't take in consideration vanityPath

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6394:
--

Yes, that's correct because the Sling Authenticator has no clue about path 
mapping done by the ResourceResolver. The Sling Authenticator just sees the raw 
request URL and has to make assumptions on that. I don't think we can and 
should do something about that.

The only way to probably approach this would be to register login requirements 
for the vanity path(s).

> SlingAuthenticatior#getAnonymousResolver doesn't take in consideration 
> vanityPath
> -
>
> Key: SLING-6394
> URL: https://issues.apache.org/jira/browse/SLING-6394
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Reporter: Antonio Sanso
>
> SlingAuthenticatior#getAnonymousResolver doesn't take in consideration 
> vanityPath . This leads to cases where a resource called with a vanityPath 
> rather then the real path is considered not existing.
>  Test case to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson reopened SLING-6187:
---

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6187:
---

[~bdelacretaz] I'm not comfortable adding a delimiter to the operation name 
since we've never said that you can't put a + (or any other character) in an 
operation name. I would be OK with a new parameter 
{{requiredPostProcessorProfile}} whose value corresponds to the configuration 
object you're suggesting. WDYT?

[~fmeschbe] the use case is laid out in the issue description -- a POST request 
may depend upon the presence of one or more post processors. Currently, if 
these post processors are not present, there is no way for the client to ensure 
that the request is handled properly and this issue is about allowing the 
client to make assertions about the way the request is handled. Keying this off 
of resource type or node types won't work because this isn't about the target 
resource, it is about the POST request itself. Two different POSTs to the same 
resource (even with the same operation) may have a different set of expected 
post processors.

>From my perspective, no additional implementation detail is leaked -- this is 
>no different than the extant {{:operation}} parameter. Just like we fail if 
>the {{:operation}} is not present, we should fail if there is a required post 
>processor which isn't present. I fail to see the difference.

I have reverted the commit for now while I look at implementing the profile 
("flavor" implies that post processors are tied to operations when they are 
orthogonal) suggestion from [~bdelacretaz]. IMHO, it appears at first glance to 
be adding significantly more complexity than is warranted. But if that is what 
is needed to obtain consensus, so be it.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6394) SlingAuthenticatior#getAnonymousResolver doesn't take in consideration vanityPath

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-6394:


 Summary: SlingAuthenticatior#getAnonymousResolver doesn't take in 
consideration vanityPath
 Key: SLING-6394
 URL: https://issues.apache.org/jira/browse/SLING-6394
 Project: Sling
  Issue Type: Bug
  Components: Authentication
Reporter: Antonio Sanso


SlingAuthenticatior#getAnonymousResolver doesn't take in consideration 
vanityPath . This leads to cases where a resource called with a vanityPath 
rather then the real path is considered not existing.
 Test case to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6187:
--

[~justinedelson] I share [~alexander.klimetschek]'s concerns (and sorry for 
being late to the party as well). Somehow this really smells very badly. It's 
like exposing some implementation and machine details. It ties clients into 
explicit implementations. Basically I allows for close coupling of clients with 
post processor implementations. It think this is wrong.

Maybe I don't understand the use case fully (I just read the proposed 
implementation). What problem does this solution try to solve ?

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6187:


Sorry for chiming in late, just saw this now - how about using a different 
operation name to point to a specific list of post processors?

I.e. instead of using {{myop}} use {{myop+myflavor}} where "myflavor" is a 
parameter for a configurable service that checks that all required post 
processors for "myflavor" are present.

I think what's triggering alarms is pointing directly to a list of post 
processors, instead of a more abstract concept like "the processors required to 
do X".

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5226) Remove loginAdministrative() usage from org.apache.sling.servlets.post

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-5226:
--
Fix Version/s: (was: Servlets Post 2.3.16)

removing Fix Version since nothing actually changed here.

> Remove loginAdministrative() usage from org.apache.sling.servlets.post 
> ---
>
> Key: SLING-5226
> URL: https://issues.apache.org/jira/browse/SLING-5226
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Antonio Sanso
>
> Counted 1 occurrence



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5226) Remove loginAdministrative() usage from org.apache.sling.servlets.post

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-5226.
---
Resolution: Won't Fix

> Remove loginAdministrative() usage from org.apache.sling.servlets.post 
> ---
>
> Key: SLING-5226
> URL: https://issues.apache.org/jira/browse/SLING-5226
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Antonio Sanso
>
> Counted 1 occurrence



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-5226) Remove loginAdministrative() usage from org.apache.sling.servlets.post

[Justin Edelson (JIRA)]

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

Justin Edelson reopened SLING-5226:
---

> Remove loginAdministrative() usage from org.apache.sling.servlets.post 
> ---
>
> Key: SLING-5226
> URL: https://issues.apache.org/jira/browse/SLING-5226
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Antonio Sanso
>
> Counted 1 occurrence



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-6187.
---
Resolution: Fixed

patch applied in r1774040 

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch edited comment on SLING-6393 at 12/13/16 3:26 PM:
---

Extended description.


was (Author: elemer):
Sure, bear with me just a little bit..

> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node:
> Reproducible on RDMBK-DB2 cluster environment.
> {noformat}
> 06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
> org.apache.sling.audit.osgi.installer Installed configuration 
> org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
>  from resource 
> TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
>  
> entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log,
>  state=INSTALL, 
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
> service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
> service.pid=audit.log], digest=562d244ccd03c4e8b208ec6e8488a131)
> 06.12.2016 16:46:56.140 *INFO* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering 
> resource with OSGi installer: [InstallableResource, priority=200, 
> id=/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config]
> 06.12.2016 16:46:56.176 *INFO* [OsgiInstallerImpl] 
> org.apache.sling.audit.osgi.installer Installed configuration 
> org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
>  from resource 
> TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
>  
> entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log,
>  state=INSTALL, 
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
> service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
> service.pid=audit.log], digest=24ee5abae6a89146693d896e8376f046)
> 06.12.2016 16:48:55.674 *INFO* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering 
> resource with OSGi installer: [InstallableResource, priority=200, 
> id=/apps/system/config/org.apache.sling.commons.log.LogManager.config]
> 06.12.2016 16:48:55.715 *INFO* [OsgiInstallerImpl] 
> org.apache.sling.audit.osgi.installer Installed configuration 
> org.apache.sling.commons.log.LogManager from resource 
> TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.config,
>  entity=config:org.apache.sling.commons.log.LogManager, state=INSTALL, 
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
> service.pid=org.apache.sling.commons.log.LogManager], 
> digest=ab4ea1c2827b4a27163236320694c81d)
> 06.12.2016 17:00:30.004 *INFO* [pool-11-thread-3] 
> com.adobe.granite.taskmanagement.impl.jcr.TaskArchiveService archiving tasks 
> at: 'Tue Dec 06 17:00:30 CET 2016'
> {noformat}
> {noformat}
> Suse-001:/data/software/wlp/usr/servers/server1 # cd -
> /data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
> Suse-001:/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
>  # ls -lart
> total 28
> -rw-r--r-- 1 root root 377 Jun 11 2015 
> 8ab79cc1-780e-4f4d-b967-c95774fb2bcb.config
> -rw-r--r-- 1 root root 375 Jun 11 2015 
> 31887166-1934-4f82-9420-0146bcb8d20c.config
> -rw-r--r-- 1 root root 413 Jun 11 2015 
> 40697bf8-0ffc-47e9-b8f3-08a0d3b36511.config
> -rw-r--r-- 1 root root 505 Jun 11 2015 
> 3ffce209-310b-448b-9d0b-b5d0ea33f1f2.config
> drwxr-xr-x 4 root root 96 Jun 11 2015 ..
> -rw-r--r-- 1 root root 435 Jun 11 2015 
> 36b4a289-61ee-4fc2-a71d-fa5445cb9b5d.config
> -rw-r- 1 root root 653 Nov 11 15:32 factory.config
> -rw-r- 1 root root 352 Dec 6 16:46 
> 8af9a8a1-a3ad-4699-980d-6494aad6314e.config
> drwxr-xr-x 2 root root 464 Dec 6 16:46 .
> {noformat}
> Please have a look at the 16:46 occurrence. Just changing on the secondary 
> cluster via OSGi Console, e.g. the audit.log log level from INFO to ERROR, 
> you should get the same duplication.
> FI-like VMs :
> root/cold!
> primary:

[jira] [Updated] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Description: 
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

Reproducible on RDMBK-DB2 cluster environment.

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=562d244ccd03c4e8b208ec6e8488a131)
06.12.2016 16:46:56.140 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config]
06.12.2016 16:46:56.176 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=24ee5abae6a89146693d896e8376f046)
06.12.2016 16:48:55.674 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.config]
06.12.2016 16:48:55.715 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.config,
 entity=config:org.apache.sling.commons.log.LogManager, state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.pid=org.apache.sling.commons.log.LogManager], 
digest=ab4ea1c2827b4a27163236320694c81d)
06.12.2016 17:00:30.004 *INFO* [pool-11-thread-3] 
com.adobe.granite.taskmanagement.impl.jcr.TaskArchiveService archiving tasks 
at: 'Tue Dec 06 17:00:30 CET 2016'
{noformat}

{noformat}
Suse-001:/data/software/wlp/usr/servers/server1 # cd -
/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
Suse-001:/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
 # ls -lart
total 28
-rw-r--r-- 1 root root 377 Jun 11 2015 
8ab79cc1-780e-4f4d-b967-c95774fb2bcb.config
-rw-r--r-- 1 root root 375 Jun 11 2015 
31887166-1934-4f82-9420-0146bcb8d20c.config
-rw-r--r-- 1 root root 413 Jun 11 2015 
40697bf8-0ffc-47e9-b8f3-08a0d3b36511.config
-rw-r--r-- 1 root root 505 Jun 11 2015 
3ffce209-310b-448b-9d0b-b5d0ea33f1f2.config
drwxr-xr-x 4 root root 96 Jun 11 2015 ..
-rw-r--r-- 1 root root 435 Jun 11 2015 
36b4a289-61ee-4fc2-a71d-fa5445cb9b5d.config
-rw-r- 1 root root 653 Nov 11 15:32 factory.config
-rw-r- 1 root root 352 Dec 6 16:46 
8af9a8a1-a3ad-4699-980d-6494aad6314e.config
drwxr-xr-x 2 root root 464 Dec 6 16:46 .
{noformat}

Please have a look at the 16:46 occurrence. Just changing on the secondary 
cluster via OSGi Console, e.g. the audit.log log level from INFO to ERROR, you 
should get the same duplication.

FI-like VMs :
root/cold!

primary:
http://10.36.65.97:9081/cq-quickstart-6.0.0/system/console/slinglog
secondary:
http://10.36.65.186:9081/cq-quickstart-6.0.0/system/console/slinglog





  was:
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

To No 3 above:

Reproducible on RDMBK-DB2 cluster environment:

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 

[jira] [Updated] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Description: 
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

To No 3 above:

Reproducible on RDMBK-DB2 cluster environment:

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=562d244ccd03c4e8b208ec6e8488a131)
06.12.2016 16:46:56.140 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config]
06.12.2016 16:46:56.176 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=24ee5abae6a89146693d896e8376f046)
06.12.2016 16:48:55.674 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.config]
06.12.2016 16:48:55.715 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.config,
 entity=config:org.apache.sling.commons.log.LogManager, state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.pid=org.apache.sling.commons.log.LogManager], 
digest=ab4ea1c2827b4a27163236320694c81d)
06.12.2016 17:00:30.004 *INFO* [pool-11-thread-3] 
com.adobe.granite.taskmanagement.impl.jcr.TaskArchiveService archiving tasks 
at: 'Tue Dec 06 17:00:30 CET 2016'
{noformat}

{noformat}
Suse-001:/data/software/wlp/usr/servers/server1 # cd -
/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
Suse-001:/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
 # ls -lart
total 28
-rw-r--r-- 1 root root 377 Jun 11 2015 
8ab79cc1-780e-4f4d-b967-c95774fb2bcb.config
-rw-r--r-- 1 root root 375 Jun 11 2015 
31887166-1934-4f82-9420-0146bcb8d20c.config
-rw-r--r-- 1 root root 413 Jun 11 2015 
40697bf8-0ffc-47e9-b8f3-08a0d3b36511.config
-rw-r--r-- 1 root root 505 Jun 11 2015 
3ffce209-310b-448b-9d0b-b5d0ea33f1f2.config
drwxr-xr-x 4 root root 96 Jun 11 2015 ..
-rw-r--r-- 1 root root 435 Jun 11 2015 
36b4a289-61ee-4fc2-a71d-fa5445cb9b5d.config
-rw-r- 1 root root 653 Nov 11 15:32 factory.config
-rw-r- 1 root root 352 Dec 6 16:46 
8af9a8a1-a3ad-4699-980d-6494aad6314e.config
drwxr-xr-x 2 root root 464 Dec 6 16:46 .
{noformat}

Please have a look at the 16:46 occurrence. Just changing on the secondary 
cluster via OSGi Console, e.g. the audit.log log level from INFO to ERROR, you 
should get the same duplication.

FI-like VMs :
root/cold!

primary:
http://10.36.65.97:9081/cq-quickstart-6.0.0/system/console/slinglog
secondary:
http://10.36.65.186:9081/cq-quickstart-6.0.0/system/console/slinglog





  was:
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

To No 3 above:

Reproducible on the FI-like environment:

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 

[jira] [Updated] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Description: 
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

To No 3 above:

Reproducible on the FI-like environment:

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=562d244ccd03c4e8b208ec6e8488a131)
06.12.2016 16:46:56.140 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config]
06.12.2016 16:46:56.176 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=24ee5abae6a89146693d896e8376f046)
06.12.2016 16:48:55.674 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.config]
06.12.2016 16:48:55.715 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.config,
 entity=config:org.apache.sling.commons.log.LogManager, state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.pid=org.apache.sling.commons.log.LogManager], 
digest=ab4ea1c2827b4a27163236320694c81d)
06.12.2016 17:00:30.004 *INFO* [pool-11-thread-3] 
com.adobe.granite.taskmanagement.impl.jcr.TaskArchiveService archiving tasks 
at: 'Tue Dec 06 17:00:30 CET 2016'
{noformat}

{noformat}
Suse-001:/data/software/wlp/usr/servers/server1 # cd -
/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
Suse-001:/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
 # ls -lart
total 28
-rw-r--r-- 1 root root 377 Jun 11 2015 
8ab79cc1-780e-4f4d-b967-c95774fb2bcb.config
-rw-r--r-- 1 root root 375 Jun 11 2015 
31887166-1934-4f82-9420-0146bcb8d20c.config
-rw-r--r-- 1 root root 413 Jun 11 2015 
40697bf8-0ffc-47e9-b8f3-08a0d3b36511.config
-rw-r--r-- 1 root root 505 Jun 11 2015 
3ffce209-310b-448b-9d0b-b5d0ea33f1f2.config
drwxr-xr-x 4 root root 96 Jun 11 2015 ..
-rw-r--r-- 1 root root 435 Jun 11 2015 
36b4a289-61ee-4fc2-a71d-fa5445cb9b5d.config
-rw-r- 1 root root 653 Nov 11 15:32 factory.config
-rw-r- 1 root root 352 Dec 6 16:46 
8af9a8a1-a3ad-4699-980d-6494aad6314e.config
drwxr-xr-x 2 root root 464 Dec 6 16:46 .
{noformat}

Please have a look at the 16:46 occurrence. Just changing on the secondary 
cluster via OSGi Console, e.g. the audit.log log level from INFO to ERROR, you 
should get the same duplication.

FI-like VMs :
root/cold!

primary:
http://10.36.65.97:9081/cq-quickstart-6.0.0/system/console/slinglog
secondary:
http://10.36.65.186:9081/cq-quickstart-6.0.0/system/console/slinglog





  was:
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node





> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> 

[jira] [Commented] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch commented on SLING-6393:
-

Sure, bear with me just a little bit..

> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6393:


Can you please add some more information?

# is this a DocumentNodeStore-based cluster?
# how are the configurations changed?
# any relevant error log entries?

> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Description: 
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node




  was:
Steps to reproduce, inside `launchpad/builder`

{noformat}
mvn clean package
java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
# wait for Sling to start up properly, stop it with CTRL-C
truncate --size=-1 sling/installer/RegisteredResourceList.ser
java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
# wait for Sling to start up properly, stop it with CTRL-C
java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
{noformat}

The following exceptions are logged in the last run:

{noformat}21.11.2016 14:32:26.538 *ERROR* [CM Configuration Updater 
(ManagedServiceFactory Update: 
factoryPid=[org.apache.sling.commons.log.LogManager.factory.config])] 
org.apache.felix.configadmin Service 
[org.apache.felix.cm.ConfigurationAdmin,28, 
[org.osgi.service.cm.ConfigurationAdmin]] 
[org.osgi.service.cm.ManagedServiceFactory, id=19, 
bundle=8/slinginstall:org.apache.sling.commons.log-5.0.1-SNAPSHOT.jar]: 
Updating property org.apache.sling.commons.log.names of configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
 caused a problem: Category log.request already defined by configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
 (org.osgi.service.cm.ConfigurationException: 
org.apache.sling.commons.log.names : Category log.request already defined by 
configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9)
org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.names 
: Category log.request already defined by configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
at 
org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:36)
at 
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
at 
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
at 
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1611)
at 
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1554)
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
at java.lang.Thread.run(Thread.java:745)
Caused by: 
org.apache.sling.commons.log.logback.internal.config.ConfigurationException: 
at 
org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLoggerConfiguration(LogConfigManager.java:533)
at 
org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:34)
... 7 common frames omitted{noformat}


> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Summary: Sling installer can duplicate factory configurations on opposite 
node if configuration is changed on local cluster node  (was: CLONE - Sling 
installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node)

> Sling installer can duplicate factory configurations on opposite node if 
> configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> Steps to reproduce, inside `launchpad/builder`
> {noformat}
> mvn clean package
> java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
> # wait for Sling to start up properly, stop it with CTRL-C
> truncate --size=-1 sling/installer/RegisteredResourceList.ser
> java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
> # wait for Sling to start up properly, stop it with CTRL-C
> java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
> {noformat}
> The following exceptions are logged in the last run:
> {noformat}21.11.2016 14:32:26.538 *ERROR* [CM Configuration Updater 
> (ManagedServiceFactory Update: 
> factoryPid=[org.apache.sling.commons.log.LogManager.factory.config])] 
> org.apache.felix.configadmin Service 
> [org.apache.felix.cm.ConfigurationAdmin,28, 
> [org.osgi.service.cm.ConfigurationAdmin]] 
> [org.osgi.service.cm.ManagedServiceFactory, id=19, 
> bundle=8/slinginstall:org.apache.sling.commons.log-5.0.1-SNAPSHOT.jar]: 
> Updating property org.apache.sling.commons.log.names of configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
>  caused a problem: Category log.request already defined by configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
>  (org.osgi.service.cm.ConfigurationException: 
> org.apache.sling.commons.log.names : Category log.request already defined by 
> configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9)
> org.osgi.service.cm.ConfigurationException: 
> org.apache.sling.commons.log.names : Category log.request already defined by 
> configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
>   at 
> org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:36)
>   at 
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
>   at 
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1611)
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1554)
>   at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
>   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: 
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException: 
>   at 
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLoggerConfiguration(LogConfigManager.java:533)
>   at 
> org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:34)
>   ... 7 common frames omitted{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6393) CLONE - Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Fix Version/s: (was: Installer Core 3.8.2)

> CLONE - Sling installer can duplicate factory configurations on opposite node 
> if configuration is changed on local cluster node
> ---
>
> Key: SLING-6393
> URL: https://issues.apache.org/jira/browse/SLING-6393
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Elemer Kisch
>Assignee: Robert Munteanu
>
> Steps to reproduce, inside `launchpad/builder`
> {noformat}
> mvn clean package
> java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
> # wait for Sling to start up properly, stop it with CTRL-C
> truncate --size=-1 sling/installer/RegisteredResourceList.ser
> java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
> # wait for Sling to start up properly, stop it with CTRL-C
> java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
> {noformat}
> The following exceptions are logged in the last run:
> {noformat}21.11.2016 14:32:26.538 *ERROR* [CM Configuration Updater 
> (ManagedServiceFactory Update: 
> factoryPid=[org.apache.sling.commons.log.LogManager.factory.config])] 
> org.apache.felix.configadmin Service 
> [org.apache.felix.cm.ConfigurationAdmin,28, 
> [org.osgi.service.cm.ConfigurationAdmin]] 
> [org.osgi.service.cm.ManagedServiceFactory, id=19, 
> bundle=8/slinginstall:org.apache.sling.commons.log-5.0.1-SNAPSHOT.jar]: 
> Updating property org.apache.sling.commons.log.names of configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
>  caused a problem: Category log.request already defined by configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
>  (org.osgi.service.cm.ConfigurationException: 
> org.apache.sling.commons.log.names : Category log.request already defined by 
> configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9)
> org.osgi.service.cm.ConfigurationException: 
> org.apache.sling.commons.log.names : Category log.request already defined by 
> configuration 
> org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
>   at 
> org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:36)
>   at 
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
>   at 
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1611)
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1554)
>   at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
>   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: 
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException: 
>   at 
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLoggerConfiguration(LogConfigManager.java:533)
>   at 
> org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:34)
>   ... 7 common frames omitted{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6393) CLONE - Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

Elemer Kisch created SLING-6393:
---

 Summary: CLONE - Sling installer can duplicate factory 
configurations on opposite node if configuration is changed on local cluster 
node
 Key: SLING-6393
 URL: https://issues.apache.org/jira/browse/SLING-6393
 Project: Sling
  Issue Type: Bug
  Components: Installer
Reporter: Elemer Kisch
Assignee: Robert Munteanu
 Fix For: Installer Core 3.8.2


Steps to reproduce, inside `launchpad/builder`

{noformat}
mvn clean package
java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
# wait for Sling to start up properly, stop it with CTRL-C
truncate --size=-1 sling/installer/RegisteredResourceList.ser
java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
# wait for Sling to start up properly, stop it with CTRL-C
java -jar target/org.apache.sling.launchpad-9-SNAPSHOT.jar
{noformat}

The following exceptions are logged in the last run:

{noformat}21.11.2016 14:32:26.538 *ERROR* [CM Configuration Updater 
(ManagedServiceFactory Update: 
factoryPid=[org.apache.sling.commons.log.LogManager.factory.config])] 
org.apache.felix.configadmin Service 
[org.apache.felix.cm.ConfigurationAdmin,28, 
[org.osgi.service.cm.ConfigurationAdmin]] 
[org.osgi.service.cm.ManagedServiceFactory, id=19, 
bundle=8/slinginstall:org.apache.sling.commons.log-5.0.1-SNAPSHOT.jar]: 
Updating property org.apache.sling.commons.log.names of configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
 caused a problem: Category log.request already defined by configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
 (org.osgi.service.cm.ConfigurationException: 
org.apache.sling.commons.log.names : Category log.request already defined by 
configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9)
org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.names 
: Category log.request already defined by configuration 
org.apache.sling.commons.log.LogManager.factory.config.b4cf7982-9af0-40a1-b720-3e83a9f9e7f9
at 
org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:36)
at 
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
at 
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
at 
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1611)
at 
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1554)
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
at java.lang.Thread.run(Thread.java:745)
Caused by: 
org.apache.sling.commons.log.logback.internal.config.ConfigurationException: 
at 
org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLoggerConfiguration(LogConfigManager.java:533)
at 
org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:34)
... 7 common frames omitted{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.2.0, OSGi Mock 2.2.2, OSGi Mock 1.9.2, Sling Mock 2.2.2, Sling Mock 1.9.2, JUnit Core 1.0.20

[Radu Cotescu]

+1

On Tue, 13 Dec 2016 at 13:30 Stefan Seifert  wrote:

> 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.
>
> stefan
>
>

Re: [VOTE] Release Apache Sling Context-Aware Configuration API 1.1.0, Context-Aware Configuration SPI 1.2.0, Context-Aware Configuration Impl 1.2.0, Context-Aware Configuration bnd Plugin 1.0.2, Cont

[Radu Cotescu]

+1

On Tue, 13 Dec 2016 at 12:58 Stefan Seifert  wrote:

> 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.
>
> stefan
>
>

Re: [VOTE] Release Apache Sling JCR Resource 2.9.0

[Radu Cotescu]

+1

On Tue, 13 Dec 2016 at 11:54 Carsten Ziegeler  wrote:

> 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.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Sling Scripting JSP 2.2.2

[Radu Cotescu]

+1

On Tue, 13 Dec 2016 at 14:01 Carsten Ziegeler  wrote:

> 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.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Sling Provisioning Model 1.8.0

[Radu Cotescu]

+1

On Tue, 13 Dec 2016 at 14:04 Carsten Ziegeler  wrote:

> 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.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Sling Scripting Java 2.1.2

[Radu Cotescu]

+1

On Tue, 13 Dec 2016 at 14:03 Carsten Ziegeler  wrote:

> 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.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Sling JCR Resource 2.9.0

[Julian Sedding]

+1 (non binding)

Regards
Julian

On Tue, Dec 13, 2016 at 12:21 PM, Carsten Ziegeler  wrote:
> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Allow PaxExam to consume provisioning models

[Bertrand Delacretaz]

Hi,

On Tue, Dec 13, 2016 at 10:02 AM, Julian Sedding  wrote:
> ...I started thinking that it would be very convenient
> to have a utility that can consume a provisioning file and use the
> contained information as Pax-Exam-Options during the construction of a
> test case

I know we have too many testing tools already, but note that the
Crankstart launcher allows you to create tests driven by provisioning
models. It's used in the contrib/commons/mom/jobs/it module for
example.

-Bertrand

RE: [VOTE] Release Apache Sling Provisioning Model 1.8.0

[Stefan Seifert]

+1 

RE: [VOTE] Release Apache Sling Scripting Java 2.1.2

[Stefan Seifert]

+1 

RE: [VOTE] Release Apache Sling Scripting JSP 2.2.2

[Stefan Seifert]

+1 

Re: [VOTE] Release Apache Sling Provisioning Model 1.8.0

[Carsten Ziegeler]

+1

 

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

[VOTE] Release Apache Sling Provisioning Model 1.8.0

[Carsten Ziegeler]

Hi,

We solved 3 issues in this release

https://issues.apache.org/jira/browse/SLING/fixforversion/12338688

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

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 1595 /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.

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

Re: [VOTE] Release Apache Sling Scripting Java 2.1.2

[Carsten Ziegeler]

+1

 

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

Re: [VOTE] Release Apache Sling Scripting JSP 2.2.2

[Carsten Ziegeler]

+1

 

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

[VOTE] Release Apache Sling Scripting Java 2.1.2

[Carsten Ziegeler]

Hi,

We solved 2 issues in this release

https://issues.apache.org/jira/browse/SLING/fixforversion/12338546

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

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 1594 /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.

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

[VOTE] Release Apache Sling Scripting JSP 2.2.2

[Carsten Ziegeler]

Hi,

We solved 2 issues in this release

https://issues.apache.org/jira/browse/SLING/fixforversion/12338545

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

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 1593 /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.

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

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.2.0, OSGi Mock 2.2.2, OSGi Mock 1.9.2, Sling Mock 2.2.2, Sling Mock 1.9.2, JUnit Core 1.0.20

[Carsten Ziegeler]

+1


 

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

Re: [VOTE] Release Apache Sling Context-Aware Configuration API 1.1.0, Context-Aware Configuration SPI 1.2.0, Context-Aware Configuration Impl 1.2.0, Context-Aware Configuration bnd Plugin 1.0.2, Cont

[Carsten Ziegeler]

+1

 

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

RE: [VOTE] Release Apache Sling Testing JCR Mock 1.2.0, OSGi Mock 2.2.2, OSGi Mock 1.9.2, Sling Mock 2.2.2, Sling Mock 1.9.2, JUnit Core 1.0.20

[Stefan Seifert]

+1

[VOTE] Release Apache Sling Testing JCR Mock 1.2.0, OSGi Mock 2.2.2, OSGi Mock 1.9.2, Sling Mock 2.2.2, Sling Mock 1.9.2, JUnit Core 1.0.20

[Stefan Seifert]

Hi,

Testing JCR Mock 1.2.0  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338263

Testing OSGi Mock 2.2.2  (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338803

Testing OSGi Mock 1.9.2  (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338802

Testing Sling Mock 2.2.2  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338805

Testing Sling Mock 1.9.2  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338804

JUnit Core 1.0.20  (3 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338259

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

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 1592 /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.

stefan

[jira] [Updated] (SLING-6388) Support tracking changes of JCR Mock MockSession

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6388:
--
Issue Type: New Feature  (was: Improvement)

> Support tracking changes of JCR Mock MockSession
> 
>
> Key: SLING-6388
> URL: https://issues.apache.org/jira/browse/SLING-6388
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.16
>Reporter: Dirk Rudolph
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Testing JCR Mock 1.2.0
>
>
> {{org.apache.sling.testing.mock.jcr.MockSession#hasPendingChanges}} always 
> returns {{false}}. This causes the {{ResourceResolver}} to return {{false}} 
> for {{hasChanges()}} as well, making it difficult to use the JCR Mock 
> {{ResourceResolverType}} for tests of transactional implementations using 
> {{ResourceResolver}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [VOTE] Release Apache Sling Context-Aware Configuration API 1.1.0, Context-Aware Configuration SPI 1.2.0, Context-Aware Configuration Impl 1.2.0, Context-Aware Configuration bnd Plugin 1.0.2, Cont

[Stefan Seifert]

+1

[VOTE] Release Apache Sling Context-Aware Configuration API 1.1.0, Context-Aware Configuration SPI 1.2.0, Context-Aware Configuration Impl 1.2.0, Context-Aware Configuration bnd Plugin 1.0.2, Context-

[Stefan Seifert]

Hi,

Context-Aware Configuration API 1.1.0  (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338408

Context-Aware Configuration SPI 1.2.0  (9 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338673

Context-Aware Configuration Impl 1.2.0  (15 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338674

Context-Aware Configuration bnd Plugin 1.0.2  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338445

Context-Aware Configuration Mock Plugin 1.0.0  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338796

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

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 1591 /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.

stefan

Re: Allow PaxExam to consume provisioning models

[Julian Sedding]

Hi Robert

Yes, I am aware of the utilities you mention, and they are useful. I
especially like the utility methods that allow installing a group of
bundles that belong together (i.e. that form a feature).

However, the "dependency-management" (aka SlingVersionResolver[0]) is
based on a hardcoded list of bundle versions (generated from Karaf
features, as you say, in a way that is unknown to me). This means in
many cases that for this VersionResolver to be useful, it needs to be
kept in sync with the launchpad provisioning model, because that is
de-facto the "single source of truth" regarding the most recent
collection of bundles.

So refactoring or enhancing the SlingVersionResolver to allow loading
a provisioning model into it would be a start. However, the
provisioning model also provides configurations, creates service users
etc. Currently we cannot re-use these definitions, but we have to
duplicate them. The main goal of integrating the provisioning model
would be to avoid this duplication.

Regards
Julian

[0] 
https://github.com/apache/sling/blob/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingVersionResolver.java


On Tue, Dec 13, 2016 at 12:19 PM, Robert Munteanu  wrote:
> Hi,
>
> On Tue, 2016-12-13 at 10:02 +0100, Julian Sedding wrote:
>> Hi all
>>
>> I looked at a PaxExam-based i18n test yesterday[0]. It was failing
>> due
>> to missing service user + configuration amendment, which was already
>> adjusted for the launchpad.
>>
>> Furthermore noticing the long list of bundles installed into the
>> PaxExam container, I started thinking that it would be very
>> convenient
>> to have a utility that can consume a provisioning file and use the
>> contained information as Pax-Exam-Options during the construction of
>> a
>> test case. This way tests could depend on a released or snapshot
>> version of the launchpad[1], as well as defining their own
>> provisioning model.
>>
>> It may also be helpful to allow re-using the versions of the bundles
>> defined in a provisioning model, but only installing the ones whose
>> grouId+artifactId are explicitly mentioned in the test.
>
> There are some helper utilities for Pax-Exam at [1] and [2] which
> should help make pax-based tests simpler.
>
>
> I think [1] does mostly what you propose, but based on Karaf features
> rather than the provisioning model.
>
> (Not saying that we should do it one way or the other, just pointing
> out existing code)
>
> Robert
>
> [1]: https://github.com/apache/sling/tree/trunk/testing/org.apache.slin
> g.testing.paxexam
> [2]: https://github.com/apache/sling/tree/trunk/testing/sling-pax-util
>
>>
>> WDYT?
>>
>> Regards
>> Julian
>>
>> [0] https://github.com/apache/sling/blob/trunk/bundles/extensions/i18
>> n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.jav
>> a#L165
>> [1] https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.
>> launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt
>

Re: Release of org.apache.sling.i18n

[Julian Sedding]

Hi Timothee

You need the instance logs to fully analyze the root cause, I think it
may be in target/failsafe-reports/*-output.txt.

In any case, I suspect the issue may be related to repository startup.
I recently made repo startup asynchronous in bundles/jcr/base (no
release yet), which allows additional services (e.g. service user
amendments, login admin whitelist fragments, repository initializers)
to be bound while the repo starts up (which can be a few seconds). As
a side-effect, this seems to have improved the chances of the system
being ready by the time tests are run.

Regards
Julian


On Tue, Dec 13, 2016 at 11:45 AM, Timothee Maret  wrote:
> Hi all,
>
> One thing that prevents me from running the release:prepare command for the
> i18n bundle is that the Pax Exam seem to fail from time to time on my
> machine. When it fails, it is because PaxExam can't find the remote
> framework (the i18n tests run in a forked vm) [0].
>
> Is this a known issue or something that needs to be investigated ? Does
> someone experience this as well (could be my environment) ?
>
> Regards,
>
> Timothee
>
> [0]
>
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 86.166 sec
> <<< FAILURE! - in org.apache.sling.i18n.it.ResourceBundleProviderIT
> org.apache.sling.i18n.it.ResourceBundleProviderIT  Time elapsed: 86.165 sec
>  <<< ERROR!
> org.ops4j.pax.exam.TestContainerException: cannot find remote framework in
> RMI registry
> at
> org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(ForkedFrameworkFactory.java:235)
> at
> org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(ForkedFrameworkFactory.java:124)
> at
> org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:162)
> at
> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
> at
> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
> at
> org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:448)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.rmi.ConnectException: Connection refused to host:
> 192.168.59.100; nested exception is:
> java.net.ConnectException: Operation timed out
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>
> 2016-12-12 21:30 GMT+01:00 Robert Munteanu :
>
>> On Mon, 2016-12-12 at 20:39 +0100, Timothee Maret wrote:
>> > Thanks Julian & Robert for your insight!
>> >
>> > The tests are fixed in r1773859 according to the successful run at
>> > [2]
>> > I'll follow [1] in order to eventually cut the release.
>>
>> Great, thanks for the quick turnaround!
>>
>> Robert
>>
>> >
>> > Regards,
>> >
>> > Timothee
>> >
>> > [2]
>> > https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-bun
>> > dles-extensions-i18n-1.8/7/
>> >
>> > 2016-12-12 14:39 GMT+01:00 Julian Sedding :
>> >
>> > > I think the failure is due to the fact the no
>> > > "org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.ame
>> > > nded"
>> > > configuration is present for the Pax integration test in the i18n
>> > > module.
>> > >
>> > > Regards
>> > > Julian
>> > >
>> > > On Mon, Dec 12, 2016 at 2:20 PM, Robert Munteanu > > > g>
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > On Mon, 2016-12-12 at 11:03 +0100, Timothee Maret wrote:
>> > > > > Hi,
>> > > > >
>> > > > > We fixed two bugs for org.apache.sling.i18n v 2.5.6 [0] and no
>> > > > > issue
>> > > > > is
>> > > > > still opened.
>> > > > > I think it'd make sense to cut a release for it, however I
>> > > > > wonder
>> > > > > how/who
>> > > > > should do the release.
>> > > > >
>> > > > > Is someone assigned to releasing that bundle ? If not should I
>> > > > > follow
>> > > > > the
>> > > > > instructions from [1] in order to propose/cut the release ?
>> > > >
>> > > > The Jenkins jobs for the i18n bundle have recently started
>> > > > failing
>> > > >
>> > > > - https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sli
>> > > > ng-bun
>> > > > dles-extensions-i18n-1.7/
>> > > > - https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sli
>> > > > ng-bun
>> > > > dles-extensions-i18n-1.8/

Re: [VOTE] Release Apache Sling JCR Resource 2.9.0

[Carsten Ziegeler]

+1

 

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

Re: Allow PaxExam to consume provisioning models

[Robert Munteanu]

Hi,

On Tue, 2016-12-13 at 10:02 +0100, Julian Sedding wrote:
> Hi all
> 
> I looked at a PaxExam-based i18n test yesterday[0]. It was failing
> due
> to missing service user + configuration amendment, which was already
> adjusted for the launchpad.
> 
> Furthermore noticing the long list of bundles installed into the
> PaxExam container, I started thinking that it would be very
> convenient
> to have a utility that can consume a provisioning file and use the
> contained information as Pax-Exam-Options during the construction of
> a
> test case. This way tests could depend on a released or snapshot
> version of the launchpad[1], as well as defining their own
> provisioning model.
> 
> It may also be helpful to allow re-using the versions of the bundles
> defined in a provisioning model, but only installing the ones whose
> grouId+artifactId are explicitly mentioned in the test.

There are some helper utilities for Pax-Exam at [1] and [2] which
should help make pax-based tests simpler.


I think [1] does mostly what you propose, but based on Karaf features
rather than the provisioning model.

(Not saying that we should do it one way or the other, just pointing
out existing code)

Robert

[1]: https://github.com/apache/sling/tree/trunk/testing/org.apache.slin
g.testing.paxexam
[2]: https://github.com/apache/sling/tree/trunk/testing/sling-pax-util

> 
> WDYT?
> 
> Regards
> Julian
> 
> [0] https://github.com/apache/sling/blob/trunk/bundles/extensions/i18
> n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.jav
> a#L165
> [1] https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.
> launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt

RE: [VOTE] Release Apache Sling JCR Resource 2.9.0

[Stefan Seifert]

+1 

[VOTE] Release Apache Sling JCR Resource 2.9.0

[Carsten Ziegeler]

Hi,

We solved 2 issues in this release

https://issues.apache.org/jira/browse/SLING/fixforversion/12338712

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

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 1590 /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.

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

Re: Release of org.apache.sling.i18n

[Timothee Maret]

Hi all,

One thing that prevents me from running the release:prepare command for the
i18n bundle is that the Pax Exam seem to fail from time to time on my
machine. When it fails, it is because PaxExam can't find the remote
framework (the i18n tests run in a forked vm) [0].

Is this a known issue or something that needs to be investigated ? Does
someone experience this as well (could be my environment) ?

Regards,

Timothee

[0]

Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 86.166 sec
<<< FAILURE! - in org.apache.sling.i18n.it.ResourceBundleProviderIT
org.apache.sling.i18n.it.ResourceBundleProviderIT  Time elapsed: 86.165 sec
 <<< ERROR!
org.ops4j.pax.exam.TestContainerException: cannot find remote framework in
RMI registry
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(ForkedFrameworkFactory.java:235)
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(ForkedFrameworkFactory.java:124)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:162)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:448)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.rmi.ConnectException: Connection refused to host:
192.168.59.100; nested exception is:
java.net.ConnectException: Operation timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)

2016-12-12 21:30 GMT+01:00 Robert Munteanu :

> On Mon, 2016-12-12 at 20:39 +0100, Timothee Maret wrote:
> > Thanks Julian & Robert for your insight!
> >
> > The tests are fixed in r1773859 according to the successful run at
> > [2]
> > I'll follow [1] in order to eventually cut the release.
>
> Great, thanks for the quick turnaround!
>
> Robert
>
> >
> > Regards,
> >
> > Timothee
> >
> > [2]
> > https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-bun
> > dles-extensions-i18n-1.8/7/
> >
> > 2016-12-12 14:39 GMT+01:00 Julian Sedding :
> >
> > > I think the failure is due to the fact the no
> > > "org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.ame
> > > nded"
> > > configuration is present for the Pax integration test in the i18n
> > > module.
> > >
> > > Regards
> > > Julian
> > >
> > > On Mon, Dec 12, 2016 at 2:20 PM, Robert Munteanu  > > g>
> > > wrote:
> > > > Hi,
> > > >
> > > > On Mon, 2016-12-12 at 11:03 +0100, Timothee Maret wrote:
> > > > > Hi,
> > > > >
> > > > > We fixed two bugs for org.apache.sling.i18n v 2.5.6 [0] and no
> > > > > issue
> > > > > is
> > > > > still opened.
> > > > > I think it'd make sense to cut a release for it, however I
> > > > > wonder
> > > > > how/who
> > > > > should do the release.
> > > > >
> > > > > Is someone assigned to releasing that bundle ? If not should I
> > > > > follow
> > > > > the
> > > > > instructions from [1] in order to propose/cut the release ?
> > > >
> > > > The Jenkins jobs for the i18n bundle have recently started
> > > > failing
> > > >
> > > > - https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sli
> > > > ng-bun
> > > > dles-extensions-i18n-1.7/
> > > > - https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sli
> > > > ng-bun
> > > > dles-extensions-i18n-1.8/
> > > >
> > > > It would be good to have them stable before a release.
> > > >
> > > > Robert
>
>

[jira] [Commented] (SLING-6372) OSGi Mocks - Correctly handle static, greedy references

[Francesco Mari (JIRA)]

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

Francesco Mari commented on SLING-6372:
---

[~sseif...@pro-vision.de], it would be nice to have a release of - at least - 
the 1.x branch to unlock the patch at OAK-5273.

> OSGi Mocks - Correctly handle static, greedy references
> ---
>
> Key: SLING-6372
> URL: https://issues.apache.org/jira/browse/SLING-6372
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.9.0, Testing OSGi Mock 2.2.0
>Reporter: Francesco Mari
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing OSGi Mock 1.9.2, Testing OSGi Mock 2.2.2
>
>
> If a component A has a static, greedy reference to another component/service 
> B (independently from the cardinality), A should react when new, better 
> instances of B are registered.
> Example. A has an optional, static, greedy reference to B. A is first 
> registered and - being the reference optional - is correctly activated. Then, 
> an instance of B is registered. A should be deactivated, its bind method for 
> B should be called, and A should be activated again.
> This behaviour is currently only supported for dynamic references, but I 
> think it should be extended to static (and greedy) references too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Allow PaxExam to consume provisioning models

[Timothee Maret]

Hi Julian,

I think this is a great idea. It would increase the integration of modules
by defining common combinations of bundles to test on and simplify the
maintenance significantly (the combination of bundle is sorted out at a
single location).

Regards,

Timothee

2016-12-13 10:02 GMT+01:00 Julian Sedding :

> Hi all
>
> I looked at a PaxExam-based i18n test yesterday[0]. It was failing due
> to missing service user + configuration amendment, which was already
> adjusted for the launchpad.
>
> Furthermore noticing the long list of bundles installed into the
> PaxExam container, I started thinking that it would be very convenient
> to have a utility that can consume a provisioning file and use the
> contained information as Pax-Exam-Options during the construction of a
> test case. This way tests could depend on a released or snapshot
> version of the launchpad[1], as well as defining their own
> provisioning model.
>
> It may also be helpful to allow re-using the versions of the bundles
> defined in a provisioning model, but only installing the ones whose
> grouId+artifactId are explicitly mentioned in the test.
>
> WDYT?
>
> Regards
> Julian
>
> [0] https://github.com/apache/sling/blob/trunk/bundles/
> extensions/i18n/src/test/java/org/apache/sling/i18n/it/
> ResourceBundleProviderIT.java#L165
> [1] https://repo1.maven.org/maven2/org/apache/sling/org.
> apache.sling.launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt
>

[jira] [Comment Edited] (SLING-6390) Remove metatype info for some HTL OSGi configurations

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6390 at 12/13/16 9:54 AM:
--

At least the Engine configuration is useful during development and it is handy 
to have a UI for the configuration here to quickly toggle some flags. Please 
keep at least that metatype info. Only the ones exposing just the 
service.ranking should be removed IMHO.


was (Author: kwin):
At least the Engine configuration is useful during development and it is handy 
to have a UI for the configuration here to quickly toggle some flags. Please 
keep at least that metatype info.

> Remove metatype info for some HTL OSGi configurations
> -
>
> Key: SLING-6390
> URL: https://issues.apache.org/jira/browse/SLING-6390
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.18, Scripting HTL 
> Engine 1.0.28, Scripting HTL Models Use Provider 1.0.6
>
>
> The following components should be modified so that they don't provide any 
> configuration metatype information any more, eliminating the complexity of 
> having too many configurations in the System Console:
> {noformat}
> org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration
> org.apache.sling.scripting.sightly.impl.engine.extension.use.JavaUseProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.ResourceUseProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.ScriptUseProvider
> org.apache.sling.scripting.sightly.js.impl.JsUseProvider
> org.apache.sling.scripting.sightly.models.impl.SlingModelsUseProvider
> {noformat}
> Advanced users will still have the possibility to configure the components by 
> using {{sling:OsgiConfig}} nodes, however they provide reasonable and tested 
> default values.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6390) Remove metatype info for some HTL OSGi configurations

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6390:


At least the Engine configuration is useful during development and it is handy 
to have a UI for the configuration here to quickly toggle some flags. Please 
keep at least that metatype info.

> Remove metatype info for some HTL OSGi configurations
> -
>
> Key: SLING-6390
> URL: https://issues.apache.org/jira/browse/SLING-6390
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.18, Scripting HTL 
> Engine 1.0.28, Scripting HTL Models Use Provider 1.0.6
>
>
> The following components should be modified so that they don't provide any 
> configuration metatype information any more, eliminating the complexity of 
> having too many configurations in the System Console:
> {noformat}
> org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration
> org.apache.sling.scripting.sightly.impl.engine.extension.use.JavaUseProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.ResourceUseProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.ScriptUseProvider
> org.apache.sling.scripting.sightly.js.impl.JsUseProvider
> org.apache.sling.scripting.sightly.models.impl.SlingModelsUseProvider
> {noformat}
> Advanced users will still have the possibility to configure the components by 
> using {{sling:OsgiConfig}} nodes, however they provide reasonable and tested 
> default values.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on a bundle file is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Summary: JCR Installer: Symbolic name changes on a bundle file is not 
properly supported  (was: JCR Installer: Symbolic name changes on the JAR file 
with the same name is not properly supported)

> JCR Installer: Symbolic name changes on a bundle file is not properly 
> supported
> ---
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Installer Core 3.6.8, JCR Installer 3.1.18
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
> deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
> the updated JAR deployed to the same JCR location  
> {{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6392) JCR Installer: Symbolic name changes on the JAR file with the same name is not properly supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6392:
---
Description: 
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
the updated JAR deployed to the same JCR location  
{{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
state {{Installed}} but the /system/console/bundle only shows bundle {{A}} but 
not {{B}}.

  was:
After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
deploy to the same JCR location  {{/apps/myapp/install/mybundle.jar}} the 
bundle is not correctly deployed.
The OSGI installer console exposes that both bundles have been in state 
installed but the /system/console/bundle only shows {{A}} but not {{B}}.


> JCR Installer: Symbolic name changes on the JAR file with the same name is 
> not properly supported
> -
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Installer Core 3.6.8, JCR Installer 3.1.18
>Reporter: Konrad Windszus
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
> deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
> the updated JAR deployed to the same JCR location  
> {{/apps/myapp/install/mybundle.jar}} the bundle is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6392) JCR Installer: Symbolic name changes on the JAR file with the same name is not properly supported

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6392:
--

 Summary: JCR Installer: Symbolic name changes on the JAR file with 
the same name is not properly supported
 Key: SLING-6392
 URL: https://issues.apache.org/jira/browse/SLING-6392
 Project: Sling
  Issue Type: Bug
Affects Versions: JCR Installer 3.1.18, Installer Core 3.6.8
Reporter: Konrad Windszus


After deploying bundle with symbolic name {{A}} to JCR location 
{{/apps/myapp/install/mybundle.jar}} it is correctly being picked up and 
deployed in Apache Felix. Now the symbolic name has been changed to {{B}} and 
deploy to the same JCR location  {{/apps/myapp/install/mybundle.jar}} the 
bundle is not correctly deployed.
The OSGI installer console exposes that both bundles have been in state 
installed but the /system/console/bundle only shows {{A}} but not {{B}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6391) DefaultDistributionConfigurationManager overrides existing persisted properties

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SLING-6391:


made some adjustments in r1773933.

> DefaultDistributionConfigurationManager overrides existing persisted 
> properties
> ---
>
> Key: SLING-6391
> URL: https://issues.apache.org/jira/browse/SLING-6391
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{DefaultDistributionConfigurationManager}} doesn't take care of existing 
> properties in the resource tree, so that persisted configs are not merged.
> Also defaults sometimes override actual parameters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6391) DefaultDistributionConfigurationManager overrides existing persisted properties

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6391:
--

 Summary: DefaultDistributionConfigurationManager overrides 
existing persisted properties
 Key: SLING-6391
 URL: https://issues.apache.org/jira/browse/SLING-6391
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution 0.2.0


{{DefaultDistributionConfigurationManager}} doesn't take care of existing 
properties in the resource tree, so that persisted configs are not merged.
Also defaults sometimes override actual parameters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6332) Configurations with same PID but different features/run modes in provisioning model are ignored

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6332:
---

I think the expectation is that we can define multiple features in a single 
maven module. IIUC different features can be activated using different 
run-modes.

The use-case would be to have a "base" feature and then a variation/extension 
of this feature, without requiring duplication of all the definitions. E.g. a 
maven module might define a "launchpad" and a "testing" feature. The "testing" 
feature would inherit all definitions from the "launchpad" feature, but add a 
configuration property to a configuration and a few bundles to be installed.

Is that an accurate description of the use-case [~rombert]?

> Configurations with same PID but different features/run modes in provisioning 
> model are ignored 
> 
>
> Key: SLING-6332
> URL: https://issues.apache.org/jira/browse/SLING-6332
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Reporter: Robert Munteanu
> Fix For: Sling Provisioning Model 1.8.0
>
>
> I have the following scenario:
> # {{launchpad/builder}} defines an OSGi config for 
> {{org.apache.sling.jcr.base.internal.LoginAdminWhitelist}}, setting the 
> {{whitelist.bundles.additional}} property
> # {{launchpad/testing}} depends on {{launchpad/builder}} and defines an the 
> same config with {{[mode=merge]}} and sets the {{whitelist.bundles.regexp}} 
> property
> When building {{launchpad/testing}}, the configuration from this project is 
> ignored completely and the one from {{launchpad/builder}} is picked up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Allow PaxExam to consume provisioning models

[Julian Sedding]

Hi all

I looked at a PaxExam-based i18n test yesterday[0]. It was failing due
to missing service user + configuration amendment, which was already
adjusted for the launchpad.

Furthermore noticing the long list of bundles installed into the
PaxExam container, I started thinking that it would be very convenient
to have a utility that can consume a provisioning file and use the
contained information as Pax-Exam-Options during the construction of a
test case. This way tests could depend on a released or snapshot
version of the launchpad[1], as well as defining their own
provisioning model.

It may also be helpful to allow re-using the versions of the bundles
defined in a provisioning model, but only installing the ones whose
grouId+artifactId are explicitly mentioned in the test.

WDYT?

Regards
Julian

[0] 
https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java#L165
[1] 
https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt

[jira] [Created] (SLING-6390) Remove metatype info for some HTL OSGi configurations

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-6390:
---

 Summary: Remove metatype info for some HTL OSGi configurations
 Key: SLING-6390
 URL: https://issues.apache.org/jira/browse/SLING-6390
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL JS Use Provider 1.0.18, Scripting HTL 
Engine 1.0.28, Scripting HTL Models Use Provider 1.0.6


The following components should be modified so that they don't provide any 
configuration metatype information any more, eliminating the complexity of 
having too many configurations in the System Console:
{noformat}
org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration
org.apache.sling.scripting.sightly.impl.engine.extension.use.JavaUseProvider
org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider
org.apache.sling.scripting.sightly.impl.engine.extension.use.ResourceUseProvider
org.apache.sling.scripting.sightly.impl.engine.extension.use.ScriptUseProvider
org.apache.sling.scripting.sightly.js.impl.JsUseProvider
org.apache.sling.scripting.sightly.models.impl.SlingModelsUseProvider
{noformat}

Advanced users will still have the possibility to configure the components by 
using {{sling:OsgiConfig}} nodes, however they provide reasonable and tested 
default values.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6378:
---

Great! Thanks for the fix [~fmeschbe]!

> Unclosed ResourceResolver in davex AuthHttpContext
> --
>
> Key: SLING-6378
> URL: https://issues.apache.org/jira/browse/SLING-6378
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Davex 1.3.4
>Reporter: Julian Sedding
>Assignee: Felix Meschberger
> Fix For: JCR Davex 1.3.6
>
>
> The changes in SLING-6375 reveal an unclosed ResourceResolver in 
> {{org.apache.sling.jcr.davex.impl.servlets.AuthHttpContext}}. The 
> {{AuthHttpContext}} delegates to {{SlingAuthenticator}} to open the RR. 
> However, {{SlingAuthenticator}} relies on 
> {{ServletRequestListener##requestDestroyed}} to be called in order to close 
> the RR. It seems that this does not happen in this case, as 
> {{SlingAuthenticator}} is called directly in this case.
> {noformat}
> 08.12.2016 14:43:19.385 *INFO* [Apache Sling Resource Resolver Finalizer 
> Thread] 
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl 
> Unclosed ResourceResolver was created here: 
> java.lang.Exception: null
> at 
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl$ResolverReference.(CommonResourceResolverFactoryImpl.java:466)
> at 
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.register(CommonResourceResolverFactoryImpl.java:200)
> at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:117)
> at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:110)
> at 
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:245)
> at 
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolver(CommonResourceResolverFactoryImpl.java:155)
> at 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getResourceResolver(ResourceResolverFactoryImpl.java:101)
> at 
> org.apache.sling.auth.core.impl.SlingAuthenticator.getAnonymousResolver(SlingAuthenticator.java:869)
> at 
> org.apache.sling.auth.core.impl.SlingAuthenticator.doHandleSecurity(SlingAuthenticator.java:500)
> at 
> org.apache.sling.auth.core.impl.SlingAuthenticator.handleSecurity(SlingAuthenticator.java:459)
> at 
> org.apache.sling.jcr.davex.impl.servlets.AuthHttpContext.handleSecurity(AuthHttpContext.java:85)
> at 
> org.apache.felix.http.base.internal.service.ServletContextImpl.handleSecurity(ServletContextImpl.java:421)
> at 
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:57)
> at 
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:128)
> at 
> org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.java:49)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:523)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at 
>