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

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6392:


What about the case that you overwrite a resource which originally contained 
more than one transformed resource? In that case those stale resources would 
not be removed. 
I would propose to move the stale check from {{checkInstallable()}} to 
{{addOrUpdate()}} (because then it is only triggered when new untransformed 
resources have been added). The stale check should then do cover all URLs 
starting(!) with the given URL (i.e. should also cover suffixed URLs).
Sorry that glitch was already contained in my version of the patch, but it 
didn't occur to me earlier.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Karl Pauls
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, 
> SLING-6392-Fragment-v02.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

Re: Parameter Support, Filters and Missing Parameters

[Andreas Schaefer Sr.]

Hi Julian

Thanks for the help.

I tried to figure out how the I18NFilter is registered in Sling but it eludes 
me.
Any hint would be appreciated.

Cheers - Andy

> On Feb 20, 2017, at 1:47 AM, Julian Sedding  wrote:
> 
> Hi Andy
> 
> You can register a javax.servlet.Filter with Sling OR with the Felix
> Whiteboard. If you want to run before the SlingMainServlet, you have
> to register your filter in the Felix whiteboard (which is what the
> I18NFilter does). Note that you will not have access to
> SlingHttpServletRequest objects in that case.
> 
> The documentation for the Felix Whiteboard describes properties to
> select a specific HTTP context[0] by adding some properties. Maybe
> that helps you to get your code working.
> 
> Regards
> Julian
> 
> [0] 
> https://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#filter-service-properties
>  
> 
> 
> 
> On Sat, Feb 18, 2017 at 1:59 AM, Andreas Schaefer Sr.  > wrote:
>> Hi
>> 
>> I tried to create a Filter to showcase the issue but I do fail with the 
>> latest
>> code base.
>> 
>> The reason is that I cannot add a filter ahead of the Sling Main Servlet even
>> though there is the I18N and SSL Filter that are running ahead of it.
>> For a customer I use that in order to adjust the query string and the 
>> parameters
>> and of late also the session timeout (bug in felix).
>> 
>> Funny thing is that my filter is called when I access the OSGi Console then
>> the filter is called just not when I work with a sling page (slingshot).
>> 
>> Question: is is still possible to add a filter ahead of Sling Main Servlet 
>> and if
>> so what are the configuration. This is what I tried:
>> 
>> 1) Does only work if sling some is enabled but then I am not ahead of the 
>> Sling Main Servlet
>> 
>> //@Component( immediate = true, label="Parameter Issue Filter", 
>> description="Filters Requests to demonstrate the Parameter Issue in Sling", 
>> metatype=false )
>> //@Service
>> //@Properties(
>> //{
>> //@Property( name="service.description", value="Parameter Issue 
>> Filter" ),
>> //@Property( name="service.vendor", value="Adobe" ),
>> @Property(name="sling.filter.scope", value="request")
>> //@Property( name="pattern", value="/", propertyPrivate=true )
>> //}
>> //)
>> 
>> 2) Taken from the SslFilter but I am not ahead of the Sling Main Servlet
>> 
>> //@SlingFilter(generateService = true, label = "Parameter Issue Filter",
>> //order = 500, scope = { SlingFilterScope.REQUEST, 
>> SlingFilterScope.ERROR })
>> //@Properties({
>> //@Property(name = "pattern", value="/.*"),
>> //@Property(name = Constants.SERVICE_DESCRIPTION, value = "Filters 
>> Requests to demonstrate the Parameter Issue in Sling"),
>> //@Property(name = Constants.SERVICE_VENDOR, value = "Madplanet.com") })
>> 
>> 2) Taken from the I18NFilter but this one is not called for Sling page
>> 
>> @Component(immediate = true, policy = ConfigurationPolicy.IGNORE, label = 
>> "Parameter Issue Filter")
>> @Service(value = Filter.class)
>> @Properties({
>>@Property(name = "pattern", value = "/.*"),
>>@Property(name = Constants.SERVICE_RANKING, intValue = 0x8100),
>>@Property(name = "service.description", value = "Filters Requests to 
>> demonstrate the Parameter Issue in Sling"),
>>@Property(name = "service.vendor", value = "Madplanet.com")
>> })
>> 
>> I traced it down to the Per Context Handler Registry but I am unable to 
>> register
>> my Filter with the one responsible for Sling pages.
>> 
>> Any help would be greatly appreciated.
>> 
>> This is 3rd client where I had to use a Filter ahead of the Sling Resource 
>> Resolution
>> do make changes to the request before the resource is resolved.
>> 
>> 
>> If that is not possible is there a way to make changes to the sling resource
>> in a filter like when I rewrite the URL to manage (AEM) dispatcher cache
>> for stuff like CSS or images?
>> 
>> Thanks - Andy Schaefer
>> 
>>> On Feb 16, 2017, at 4:05 AM, Robert Munteanu  wrote:
>>> 
>>> Hi Andy,
>>> 
>>> On Tue, 2017-02-14 at 14:05 -0800, Andreas Schaefer Sr. wrote:
 While working on AEM 6.2 SP1 with a Servlet Filter
 I came across issues with the Parameter Support
 as they interfere with the Servlet Filters or at least
 with Servlet Filters that are handled before entering
 the “Sling domain”.
 
 1) Because of the SlingHttpContext.handleSecurity()
 the Parameter Support is created as one of the first
 Servlet Filters.
 2) That Parameter Support reads the parameters from the
 Servlet Input stream
 
 3) The Parameter Support Request Wrapper is ditched later
 
 4) Any later filter will not have access to the parameters
 from the request
 
 5) Any Filter that 

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

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-6392:
--
Attachment: SLING-6392-Fragment-v02.patch

I think we should have a working version of this in the attached 
[^SLING-6392-Fragment-v02.patch] patch. It basically will only add the fragment 
if it is needed (i.e., we have more than one transformation result) and logs an 
error if in that case a transformation result has no id or the id is not 
unique. 

The patch also includes the previous test case for the "it" project. 
Subsequently, the it projects passes for me (including the new test cases) as 
well as the launcher integration-tests and some internal test-suites - hence, 
I'm reasonable confident that it doesn't break anything.

Cloud you [~kwin] and hopefully [~cziegeler] as well, please review the patch 
and let us know if this is good to go (in which case I will commit the patch)? 

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Karl Pauls
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, 
> SLING-6392-Fragment-v02.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

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

[Karl Pauls (JIRA)]

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

Karl Pauls reassigned SLING-6392:
-

Assignee: Karl Pauls  (was: Konrad Windszus)

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Karl Pauls
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

Re: [RESULT][VOTE] Release Apache Sling Installer Core version 3.8.6

[Karl Pauls]

Time to call the vote on the Apache Sling Installer Core version 3.8.6 release.

* +1 votes from Robert Munteanu, Carsten Ziegeler, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Release Apache Sling Installer Core version 3.8.6

[Karl Pauls]

+1

regards,

Karl

On Fri, Feb 17, 2017 at 3:16 PM, Daniel Klco  wrote:
> +1 -  Checked signatures and build
>
> On Fri, Feb 17, 2017 at 9:03 AM, Robert Munteanu  wrote:
>
>> On Fri, 2017-02-17 at 14:51 +0100, Karl Pauls wrote:
>> > Please vote to approve this release:
>>
>> +1
>>
>> Robert



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Resolved] (SLING-6535) bin Not Ignored by .gitignore

[Dan Klco (JIRA)]

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

Dan Klco resolved SLING-6535.
-
Resolution: Fixed

Fixed in Rev. 1783784

> bin Not Ignored by .gitignore
> -
>
> Key: SLING-6535
> URL: https://issues.apache.org/jira/browse/SLING-6535
> Project: Sling
>  Issue Type: Task
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Trivial
>
> The current .gitignore does not ignore directories named bin. The following 
> projects will create a bin directory which shows up as an untracked folder 
> when performing Git commands after running a sling build:
>  - bundles/commons/metrics/bin/
>  - bundles/extensions/caconfig/impl/bin/
>  - bundles/jcr/repoinit/bin/
> The pattern bin/ should be added to the .gitignore for Sling to exclude these 
> folders from source control.



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

[jira] [Created] (SLING-6535) bin Not Ignored by .gitignore

[Dan Klco (JIRA)]

Dan Klco created SLING-6535:
---

 Summary: bin Not Ignored by .gitignore
 Key: SLING-6535
 URL: https://issues.apache.org/jira/browse/SLING-6535
 Project: Sling
  Issue Type: Task
Reporter: Dan Klco
Assignee: Dan Klco
Priority: Trivial


The current .gitignore does not ignore directories named bin. The following 
projects will create a bin directory which shows up as an untracked folder when 
performing Git commands after running a sling build:

 - bundles/commons/metrics/bin/
 - bundles/extensions/caconfig/impl/bin/
 - bundles/jcr/repoinit/bin/

The pattern bin/ should be added to the .gitignore for Sling to exclude these 
folders from source control.



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

adaptTo() 2017 Conference in Berlin

[Stefan Seifert]

Good morning everyone,

focusing on Apache Sling, Apache Felix and Apache Jackrabbit, the adaptTo() 
conference in Berlin is aimed at developers using some or all if this stack.

If you are not familiar with our event yet, you might find something 
interesting in the sessions from last year http://adapt.to/2016/schedule

Conference Date is 25-27 September; latest information can be found on 
http://adapt.to
Our Call for Papers is open now until 21 April http://adapt.to/cfp
Early Bird Tickets will save you -15% http://adapt.to/tickets

Have a great week and we look forward to seeing you in Berlin.

Kind regards on behalf of the adaptTo() Team,
Stefan

p.s. Apache Sling/Felix/Jackrabbit Comitters receive a discount - see 
https://adapt.to/conference

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

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6392:
---

Ok. Let me try to work that into the patch. 

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

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

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6392:


This patch looks ok to me as well, except that I want the method {{transform}} 
to explicitly log an error in case a duplicate resource url is being generated 
(in case there is no id and multiple results or in case there is multiple times 
the same id being used).
The only drawback of using the id as suffix is that he id is very often is long 
(i.e. not a perfect match for a suffix) and  duplicates part of the URL. But it 
at least fulfills the necessary requirements for the URL to become unique.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

[jira] [Comment Edited] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not supported

[Karl Pauls (JIRA)]

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

Karl Pauls edited comment on SLING-6392 at 2/20/17 4:27 PM:


The [SLING-6392-Fragment.patch] should do what I was talking about. It 
basically just appends the id of TransformationResults to the url as fragment 
when there is an id.

It seems to work for me. WDYT?


was (Author: karlpauls):
The [~SLING-6392-Fragment.patch] should do what I was talking about. It 
basically just appends the id of TransformationResults to the url as fragment 
when there is an id.

It seems to work for me. WDYT?

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

[jira] [Comment Edited] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not supported

[Karl Pauls (JIRA)]

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

Karl Pauls edited comment on SLING-6392 at 2/20/17 4:26 PM:


The [~SLING-6392-Fragment.patch] should do what I was talking about. It 
basically just appends the id of TransformationResults to the url as fragment 
when there is an id.

It seems to work for me. WDYT?


was (Author: karlpauls):
The [SLING-6392-Fragment.patch] should do what I was talking about. It 
basically just appends the id of TransformationResults to the url as fragment 
when there is an id.

It seems to work for me. WDYT?

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

[jira] [Comment Edited] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not supported

[Karl Pauls (JIRA)]

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

Karl Pauls edited comment on SLING-6392 at 2/20/17 4:26 PM:


The [SLING-6392-Fragment.patch] should do what I was talking about. It 
basically just appends the id of TransformationResults to the url as fragment 
when there is an id.

It seems to work for me. WDYT?


was (Author: karlpauls):
The SLING-6392-Fragment.patch should do what I was talking about. It basically 
just appends the id of TransformationResults to the url as fragment when there 
is an id.

It seems to work for me. WDYT?

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

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

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-6392:
--
Attachment: SLING-6392-Fragment.patch

The SLING-6392-Fragment.patch should do what I was talking about. It basically 
just appends the id of TransformationResults to the url as fragment when there 
is an id.

It seems to work for me. WDYT?

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-Fragment.patch, SLING-6392-test-v01.patch, 
> SLING-6392-test-v02.patch, SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

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

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6392:
---

Well, I'm not sure your patch isn't going beyond what is needed. I'd much 
prefer not making this an api level change. After thinking about it for a bit: 
how about we make it so that we just append the id of TransformationResults to 
the url as a fragment? 

It would basically mean that if a TransformationResult has an id we append it 
to the url as a fragment. If it doesn't have one we do nothing. In the former 
case, its possible to have more than one TransformationResult for a Resource, 
in the latter it is not. 

That seems pretty consistent for me and it wouldn't introduce an API level 
change. I'll try to come-up with a patch.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-test-v01.patch, SLING-6392-test-v02.patch, 
> SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

[jira] [Commented] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6531:


The caching of the result is now tracked in SLING-6534. The threshold handling 
is implemented with [r1783780|http://svn.apache.org/r1783780].

> Do not always throw exceptions to propagate information about failed 
> validations
> 
>
> Key: SLING-6531
> URL: https://issues.apache.org/jira/browse/SLING-6531
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Validation Impl 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
>
> Right now the {{o.a.s.models.validation.impl.ModelValidationImpl}} will 
> always throw an {{InvalidResourceException}} in case the underlying resource 
> is not valid (according to Sling Validation). With the advent of different 
> severities per issue (SLING-5373) this seems a bit too strict because some 
> validators could be used just for informational purposes. Those validations 
> should not prevent the Sling Model from being instantiated.



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

[jira] [Resolved] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6531.

Resolution: Fixed

> Do not always throw exceptions to propagate information about failed 
> validations
> 
>
> Key: SLING-6531
> URL: https://issues.apache.org/jira/browse/SLING-6531
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Validation Impl 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
>
> Right now the {{o.a.s.models.validation.impl.ModelValidationImpl}} will 
> always throw an {{InvalidResourceException}} in case the underlying resource 
> is not valid (according to Sling Validation). With the advent of different 
> severities per issue (SLING-5373) this seems a bit too strict because some 
> validators could be used just for informational purposes. Those validations 
> should not prevent the Sling Model from being instantiated.



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

[jira] [Updated] (SLING-6534) Optionally cache results of ValidationService.validate(Resource, ValidationModel) and expose the cached result via an AdapterFactory

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6534:
---
Summary: Optionally cache results of ValidationService.validate(Resource, 
ValidationModel) and expose the cached result via an AdapterFactory  (was: 
Optionally cache results of {{ValidationService.validate(Resource, 
ValidationModel)}} and expose the cached result via an AdapterFactory)

> Optionally cache results of ValidationService.validate(Resource, 
> ValidationModel) and expose the cached result via an AdapterFactory
> 
>
> Key: SLING-6534
> URL: https://issues.apache.org/jira/browse/SLING-6534
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> At least for the Sling Validation being triggered from the 
> ModelAdapterFactory it would be beneficial to be able to look up the result 
> of the last validation of a specific resource in a cache. That is especially 
> useful when exceptions cannot be used to propagate this information to a 
> different place in the code (e.g. to a Servlet filter). A concrete use case 
> for this is SLING-6531 where the cached result is accessible even if all 
> failures are below the threshold.



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

[jira] [Created] (SLING-6534) Optionally cache results of {{ValidationService.validate(Resource, ValidationModel)}} and expose the cached result via an AdapterFactory

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6534:
--

 Summary: Optionally cache results of 
{{ValidationService.validate(Resource, ValidationModel)}} and expose the cached 
result via an AdapterFactory
 Key: SLING-6534
 URL: https://issues.apache.org/jira/browse/SLING-6534
 Project: Sling
  Issue Type: Improvement
  Components: Validation
Reporter: Konrad Windszus
Assignee: Konrad Windszus
 Fix For: Validation 1.0.0


At least for the Sling Validation being triggered from the ModelAdapterFactory 
it would be beneficial to be able to look up the result of the last validation 
of a specific resource in a cache. That is especially useful when exceptions 
cannot be used to propagate this information to a different place in the code 
(e.g. to a Servlet filter). A concrete use case for this is SLING-6531 where 
the cached result is accessible even if all failures are below the threshold.



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

[jira] [Comment Edited] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6531 at 2/20/17 3:40 PM:
-

The question is, how can the information about the validation be propagated 
without leveraging an exception (in case all failures are below the threshold), 
without having a request at hand and without leveraging a ThreadLocal (compare 
with 
http://apache-sling.73963.n3.nabble.com/RTC-ThreadLocal-for-getting-current-request-in-sling-td4042387.html).
 My proposal is:
Attach the {{ValidationResult}} to the {{Resource}} by leveraging the 
{{Resource.getResourceMetadata().put("sling.validation", validationResult)}}. 
Then make the {{ValidationResult}} accessible by registering an 
{{AdapterFactory}} for adaptations from {{Resource}} to {{ValidationResult}} 
which will expose that object again (by looking it up in the Resources 
metadata).
  


was (Author: kwin):
The question is, how can the information about the validation be propagated 
without leveraging an exception, without having a request at hand and without 
leveraging a ThreadLocal (compare with 
http://apache-sling.73963.n3.nabble.com/RTC-ThreadLocal-for-getting-current-request-in-sling-td4042387.html).
 My proposal is:
Attach the {{ValidationResult}} to the {{Resource}} by leveraging the 
{{Resource.getResourceMetadata().put("sling.validation", validationResult)}}. 
Then make the {{ValidationResult}} accessible by registering an 
{{AdapterFactory}} for adaptations from {{Resource}} to {{ValidationResult}} 
which will expose that object again (by looking it up in the Resources 
metadata).
  

> Do not always throw exceptions to propagate information about failed 
> validations
> 
>
> Key: SLING-6531
> URL: https://issues.apache.org/jira/browse/SLING-6531
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Validation Impl 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
>
> Right now the {{o.a.s.models.validation.impl.ModelValidationImpl}} will 
> always throw an {{InvalidResourceException}} in case the underlying resource 
> is not valid (according to Sling Validation). With the advent of different 
> severities per issue (SLING-5373) this seems a bit too strict because some 
> validators could be used just for informational purposes. Those validations 
> should not prevent the Sling Model from being instantiated.



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

[jira] [Commented] (SLING-6532) No longer add the Felix SCR annotations to the list of dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6532:
-

[~kwin] ok, thanks

> No longer add the Felix SCR annotations to the list of dependencies
> ---
>
> Key: SLING-6532
> URL: https://issues.apache.org/jira/browse/SLING-6532
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> To encourage more modules to switch to OSGi 6 annotations, we should not only 
> mark the dependency with the (invisible) comment {{DEPRECATED}} (as being 
> done with SLING-5857), but instead no longer put that dependency by default 
> into the classpath. Just having that in the dependencyManagement is enough, 
> so that for new modules already leveraging only the new annotations the 
> classpath is no longer polluted by this unnecessary class.



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

[jira] [Commented] (SLING-6532) No longer add the Felix SCR annotations to the list of dependencies

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6532:


[~cziegeler] I just did that for bndlib in SLING-6533.

> No longer add the Felix SCR annotations to the list of dependencies
> ---
>
> Key: SLING-6532
> URL: https://issues.apache.org/jira/browse/SLING-6532
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> To encourage more modules to switch to OSGi 6 annotations, we should not only 
> mark the dependency with the (invisible) comment {{DEPRECATED}} (as being 
> done with SLING-5857), but instead no longer put that dependency by default 
> into the classpath. Just having that in the dependencyManagement is enough, 
> so that for new modules already leveraging only the new annotations the 
> classpath is no longer polluted by this unnecessary class.



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

[jira] [Commented] (SLING-6532) No longer add the Felix SCR annotations to the list of dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6532:
-

[~kwin] I think the same applies to the old bnd annotations. Actually the last 
line (comment) you removed from the pom, was for that dependency :) So let's 
remove that one as well

> No longer add the Felix SCR annotations to the list of dependencies
> ---
>
> Key: SLING-6532
> URL: https://issues.apache.org/jira/browse/SLING-6532
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> To encourage more modules to switch to OSGi 6 annotations, we should not only 
> mark the dependency with the (invisible) comment {{DEPRECATED}} (as being 
> done with SLING-5857), but instead no longer put that dependency by default 
> into the classpath. Just having that in the dependencyManagement is enough, 
> so that for new modules already leveraging only the new annotations the 
> classpath is no longer polluted by this unnecessary class.



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

[jira] [Created] (SLING-6532) No longer add the Felix SCR annotations to the list of dependencies

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6532:
--

 Summary: No longer add the Felix SCR annotations to the list of 
dependencies
 Key: SLING-6532
 URL: https://issues.apache.org/jira/browse/SLING-6532
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Parent 29
Reporter: Konrad Windszus
Assignee: Konrad Windszus
 Fix For: Parent 30


To encourage more modules to switch to OSGi 6 annotations, we should not only 
mark the dependency with the (invisible) comment {{DEPRECATED}} (as being done 
with SLING-5857), but instead no longer put that dependency by default into the 
classpath. Just having that in the dependencyManagement is enough, so that for 
new modules already leveraging only the new annotations the classpath is no 
longer polluted by this unnecessary class.



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

[jira] [Resolved] (SLING-6533) No longer add bndlib to the list of commons dependencies

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6533.

Resolution: Fixed

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

> No longer add bndlib to the list of commons dependencies
> 
>
> Key: SLING-6533
> URL: https://issues.apache.org/jira/browse/SLING-6533
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> The bndlib dependency was used in the past for the semantic versioning 
> annotations. Now that OSGi has its own annotations, that library should no 
> longer be part of the common inherited dependencies.



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

[jira] [Created] (SLING-6533) No longer add bndlib to the list of commons dependencies

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6533:
--

 Summary: No longer add bndlib to the list of commons dependencies
 Key: SLING-6533
 URL: https://issues.apache.org/jira/browse/SLING-6533
 Project: Sling
  Issue Type: Improvement
Affects Versions: Parent 29
Reporter: Konrad Windszus
 Fix For: Parent 30


The bndlib dependency was used in the past for the semantic versioning 
annotations. Now that OSGi has its own annotations, that library should no 
longer be part of the common inherited dependencies.



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

[jira] [Assigned] (SLING-6533) No longer add bndlib to the list of commons dependencies

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-6533:
--

Assignee: Konrad Windszus

> No longer add bndlib to the list of commons dependencies
> 
>
> Key: SLING-6533
> URL: https://issues.apache.org/jira/browse/SLING-6533
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> The bndlib dependency was used in the past for the semantic versioning 
> annotations. Now that OSGi has its own annotations, that library should no 
> longer be part of the common inherited dependencies.



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

[jira] [Resolved] (SLING-6532) No longer add the Felix SCR annotations to the list of dependencies

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6532.

Resolution: Fixed

Fixed in [r1783774|https://svn.apache.org/r1783774].

> No longer add the Felix SCR annotations to the list of dependencies
> ---
>
> Key: SLING-6532
> URL: https://issues.apache.org/jira/browse/SLING-6532
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Parent 29
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Parent 30
>
>
> To encourage more modules to switch to OSGi 6 annotations, we should not only 
> mark the dependency with the (invisible) comment {{DEPRECATED}} (as being 
> done with SLING-5857), but instead no longer put that dependency by default 
> into the classpath. Just having that in the dependencyManagement is enough, 
> so that for new modules already leveraging only the new annotations the 
> classpath is no longer polluted by this unnecessary class.



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

[jira] [Comment Edited] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6531 at 2/20/17 2:25 PM:
-

The question is, how can the information about the validation be propagated 
without leveraging an exception, without having a request at hand and without 
leveraging a ThreadLocal (compare with 
http://apache-sling.73963.n3.nabble.com/RTC-ThreadLocal-for-getting-current-request-in-sling-td4042387.html).
 My proposal is:
Attach the {{ValidationResult}} to the {{Resource}} by leveraging the 
{{Resource.getResourceMetadata().put("sling.validation", validationResult)}}. 
Then make the {{ValidationResult}} accessible by registering an 
{{AdapterFactory}} for adaptations from {{Resource}} to {{ValidationResult}} 
which will expose that object again (by looking it up in the Resources 
metadata).
  


was (Author: kwin):
The question is, how can the information about the validation be propagated 
without leveraging an exception and without having a request/thread at hand 
(compare with 
http://apache-sling.73963.n3.nabble.com/RTC-ThreadLocal-for-getting-current-request-in-sling-td4042387.html).
 My proposal is:
Attach the {{ValidationResult}} to the {{Resource}} by leveraging the 
{{Resource.getResourceMetadata().put("sling.validation", validationResult)}}. 
Then make the {{ValidationResult}} accessible by registering an 
{{AdapterFactory}} for adaptations from {{Resource}} to {{ValidationResult}} 
which will expose that object again (by looking it up in the Resources 
metadata).
  

> Do not always throw exceptions to propagate information about failed 
> validations
> 
>
> Key: SLING-6531
> URL: https://issues.apache.org/jira/browse/SLING-6531
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Validation Impl 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
>
> Right now the {{o.a.s.models.validation.impl.ModelValidationImpl}} will 
> always throw an {{InvalidResourceException}} in case the underlying resource 
> is not valid (according to Sling Validation). With the advent of different 
> severities per issue (SLING-5373) this seems a bit too strict because some 
> validators could be used just for informational purposes. Those validations 
> should not prevent the Sling Model from being instantiated.



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

[jira] [Commented] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6531:


The question is, how can the information about the validation be propagated 
without leveraging an exception and without having a request/thread at hand 
(compare with 
http://apache-sling.73963.n3.nabble.com/RTC-ThreadLocal-for-getting-current-request-in-sling-td4042387.html).
 My proposal is:
Attach the {{ValidationResult}} to the {{Resource}} by leveraging the 
{{Resource.getResourceMetadata().put("sling.validation", validationResult)}}. 
Then make the {{ValidationResult}} accessible by registering an 
{{AdapterFactory}} for adaptations from {{Resource}} to {{ValidationResult}} 
which will expose that object again (by looking it up in the Resources 
metadata).
  

> Do not always throw exceptions to propagate information about failed 
> validations
> 
>
> Key: SLING-6531
> URL: https://issues.apache.org/jira/browse/SLING-6531
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Validation Impl 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
>
> Right now the {{o.a.s.models.validation.impl.ModelValidationImpl}} will 
> always throw an {{InvalidResourceException}} in case the underlying resource 
> is not valid (according to Sling Validation). With the advent of different 
> severities per issue (SLING-5373) this seems a bit too strict because some 
> validators could be used just for informational purposes. Those validations 
> should not prevent the Sling Model from being instantiated.



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

[jira] [Updated] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6531:
---
Description: Right now the 
{{o.a.s.models.validation.impl.ModelValidationImpl}} will always throw an 
{{InvalidResourceException}} in case the underlying resource is not valid 
(according to Sling Validation). With the advent of different severities per 
issue (SLING-5373) this seems a bit too strict because some validators could be 
used just for informational purposes. Those validations should not prevent the 
Sling Model from being instantiated.

> Do not always throw exceptions to propagate information about failed 
> validations
> 
>
> Key: SLING-6531
> URL: https://issues.apache.org/jira/browse/SLING-6531
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Validation Impl 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
>
> Right now the {{o.a.s.models.validation.impl.ModelValidationImpl}} will 
> always throw an {{InvalidResourceException}} in case the underlying resource 
> is not valid (according to Sling Validation). With the advent of different 
> severities per issue (SLING-5373) this seems a bit too strict because some 
> validators could be used just for informational purposes. Those validations 
> should not prevent the Sling Model from being instantiated.



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

[jira] [Created] (SLING-6531) Do not always throw exceptions to propagate information about failed validations

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6531:
--

 Summary: Do not always throw exceptions to propagate information 
about failed validations
 Key: SLING-6531
 URL: https://issues.apache.org/jira/browse/SLING-6531
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Sling Models Validation Impl 1.0.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
 Fix For: Sling Models Validation Impl 1.0.0






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

Re: [RESULT] [VOTE] Release Apache Sling Content Distribution Core 0.2.4

[Timothee Maret]

Thanks Carsten! I have done the remaining steps.

Regards,

Timothee

2017-02-20 12:05 GMT+01:00 Carsten Ziegeler :

> Timothee Maret wrote
> > Hi,
> >
> > The vote has passed with the following result :
> >
> > +1 (binding): Daniel K., Robert M., Carsten Z.
> > +1 (non binding): Tommaso T.
> >
> >
> > @PMC Could someone please copy this release to the Sling dist directory ?
> > I'll take care of the remaining steps beside that one.
> >
> Done
>
>
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Updated] (SLING-4797) Improve handling of Move events

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-4797:
--
Fix Version/s: (was: Content Distribution Core 0.2.4)
   Content Distribution Core 0.2.6

> Improve handling of Move events
> ---
>
> Key: SLING-4797
> URL: https://issues.apache.org/jira/browse/SLING-4797
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.4
>Reporter: Konrad Windszus
> Fix For: Content Distribution Core 0.2.6
>
>
> In case you are moving a node with a lot of subnodes, this leads to a 
> distributed deletion of the node, followed by the distributed addition of the 
> node with all subnodes.
> To improve the performance it would be good, if the move operation would 
> really be distributed through a move event, which means that each receiver 
> would try to move the node (instead of first deleting it and then adding it 
> with all its subnodes).



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

[jira] [Updated] (SLING-5952) Add support for configurable SO and connection timeouts

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5952:
--
Fix Version/s: (was: Content Distribution Core 0.2.4)
   Content Distribution Core 0.2.6

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.6
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



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

[jira] [Updated] (SLING-5760) Allow to support certificate based authentication in Distribution transport

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5760:
--
Fix Version/s: (was: Content Distribution Core 0.2.4)
   Content Distribution Core 0.2.6

> Allow to support certificate based authentication in Distribution transport
> ---
>
> Key: SLING-5760
> URL: https://issues.apache.org/jira/browse/SLING-5760
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.6
>
> Attachments: SLING-5760.patch
>
>
> Certificate based authentication is an alternative to the basic 
> authentication currently available for Distribution transport. Certificate 
> based authentication is done during the SSL handshake iff the target instance 
> is configured to require or accept client client authentication. This client 
> authentication scheme is a logical complement when connecting to endpoints 
> serving over https. This result in authenticating both the source and the 
> target using SSL.
> The client certificate and private key are required to complete the SSL 
> handshake. By default, the JRE will use the default {{KeyStore}} to retrieve 
> those informations. However, in some platforms such as Adobe Granite, there 
> is the ability to specify custom {{KeyStore}} based on user. For those 
> platforms, the custom {{KeyStore}} can be provided with a 
> {{javax.net.ssl.SSLContext}} which also contains a custom {{TrustStore}}.
> This issue tracks allowing to leverage certificate based authentication using 
> a custom {{javax.net.ssl.SSLContext}} in Distribution transport.



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

[jira] [Updated] (SLING-5916) Remove all usages of jobManager.findJobs in SCD

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5916:
--
Fix Version/s: (was: Content Distribution Core 0.2.4)
   Content Distribution Core 0.2.6

> Remove all usages of jobManager.findJobs in SCD
> ---
>
> Key: SLING-5916
> URL: https://issues.apache.org/jira/browse/SLING-5916
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.6
>
>
> Given the latest discussions on the Sling dev@ list it'd be good to stop 
> using {{JobManager#findJobs}} API at all in the SCD code (for the jobs based 
> queues).
> This would require either accepting queues cannot be inspected in detail 
> (which / how many items there are in each queue) or rely on different 
> constructs.



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

[jira] [Updated] (SLING-6211) Clarify AbstractJcrEventTrigger request addition strategy

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-6211:
--
Fix Version/s: (was: Content Distribution Core 0.2.4)
   Content Distribution Core 0.2.6

> Clarify AbstractJcrEventTrigger request addition strategy
> -
>
> Key: SLING-6211
> URL: https://issues.apache.org/jira/browse/SLING-6211
> Project: Sling
>  Issue Type: Task
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.6
>
>
> We should clarify the logic behind 
> [AbstractJcrEventListener#addToList|https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/trigger/impl/AbstractJcrEventTrigger.java#L150]
>  as that the addition mechanism seems to rely on the last request added, 
> which seems wrong as events may come in in an unsorted manner (not consistent 
> with the order the changes they refer to were done).



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

[jira] [Updated] (SLING-6528) Installation of a package through the package manager should trigger a new cycle in the OSGi Installer

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6528:
---
Description: 
Whenever a content-package is lacking some dependencies the installation is 
deferred in 
https://github.com/apache/sling/blob/trunk/installer/factories/packages/src/main/java/org/apache/sling/installer/factory/packages/impl/PackageTransformer.java#L234.
If the dependency is now installed via the package manager directly (instead of 
using the OSGi Installer), the dependent package is not being installed till 
some other event causes the next OSGi Installer cycle, because the OSGi 
Installer simply won't detect that "external" installation.

  was:
Whenever a content-package is lacking some dependencies the installation is 
deferred in 
https://github.com/apache/sling/blob/trunk/installer/factories/packages/src/main/java/org/apache/sling/installer/factory/packages/impl/PackageTransformer.java#L234.
If the dependent package is now installed via the package manager directly 
(instead of using the OSGi Installer), the dependent package is not being 
installed till some other event causes the next OSGi Installer cycle, because 
the OSGi Installer simply won't detect that "external" installation.


> Installation of a package through the package manager should trigger a new 
> cycle in the OSGi Installer
> --
>
> Key: SLING-6528
> URL: https://issues.apache.org/jira/browse/SLING-6528
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Packages Factory 1.0.0
>Reporter: Konrad Windszus
> Fix For: Installer Packages Factory 1.0.0
>
>
> Whenever a content-package is lacking some dependencies the installation is 
> deferred in 
> https://github.com/apache/sling/blob/trunk/installer/factories/packages/src/main/java/org/apache/sling/installer/factory/packages/impl/PackageTransformer.java#L234.
> If the dependency is now installed via the package manager directly (instead 
> of using the OSGi Installer), the dependent package is not being installed 
> till some other event causes the next OSGi Installer cycle, because the OSGi 
> Installer simply won't detect that "external" installation.



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

Re: Removing dependency to org.json

[Chetan Mehrotra]

Thanks Carsten for the example commit. I have changed Log WebConsole
Plugin. However when doing the same for slf4j-mdc I hit FELIX-.
Would see if I can workaround that for now
Chetan Mehrotra


On Mon, Feb 20, 2017 at 1:56 PM, Carsten Ziegeler  wrote:
> Chetan Mehrotra wrote
>> Hi Carsten,
>>
>> I can take care of log,metrics,slf4j-mdc
>>
>> Whats the recommended approach to replace the current usage?
>
> As an exampled I've replaced the usage in the metrics project.
>
> I've also removed the usage from launchpad.
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [RESULT] [VOTE] Release Apache Sling Content Distribution Core 0.2.4

[Carsten Ziegeler]

Timothee Maret wrote
> Hi,
> 
> The vote has passed with the following result :
> 
> +1 (binding): Daniel K., Robert M., Carsten Z.
> +1 (non binding): Tommaso T.
> 
> 
> @PMC Could someone please copy this release to the Sling dist directory ?
> I'll take care of the remaining steps beside that one.
> 
Done


Carsten

 

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

[jira] [Resolved] (SLING-6530) ITWebConsoleRemote fails intermittently

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-6530.

Resolution: Fixed

Done with 1783736

> ITWebConsoleRemote fails intermittently
> ---
>
> Key: SLING-6530
> URL: https://issues.apache.org/jira/browse/SLING-6530
> Project: Sling
>  Issue Type: Test
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log WebConsole 1.0.2
>
>
> ITWebConsoleRemote fails intermittently reporting that appender is not found



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

[jira] [Resolved] (SLING-6529) Remove usage of org.json from Log WebConsole Module

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-6529.

Resolution: Fixed

Done with 1783735

> Remove usage of org.json from Log WebConsole Module
> ---
>
> Key: SLING-6529
> URL: https://issues.apache.org/jira/browse/SLING-6529
> Project: Sling
>  Issue Type: Task
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Log WebConsole 1.0.2
>
>
> We have to replace the usage of org.json. Here we just need to update the 
> dependency to latest Felix WebConsole Bundle which does not depend on org.json



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

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

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6392:
---

Yeah, I agree with your statement above. Sorry for the somewhat bumpy release - 
in case we get this issue fixed I'm more than willing to cut a new one. 
Furthermore, I certainly think we should address this as your underlying patch 
still makes sense to me and I too think that all transformed resources should 
have their own URL. 

Let me have a look at your patch and get back to this issue.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-test-v01.patch, SLING-6392-test-v02.patch, 
> SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

[jira] [Created] (SLING-6530) ITWebConsoleRemote fails intermittently

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-6530:
--

 Summary: ITWebConsoleRemote fails intermittently
 Key: SLING-6530
 URL: https://issues.apache.org/jira/browse/SLING-6530
 Project: Sling
  Issue Type: Test
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: Commons Log WebConsole 1.0.2


ITWebConsoleRemote fails intermittently reporting that appender is not found



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

[jira] [Created] (SLING-6529) Remove usage of org.json from Log WebConsole Module

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-6529:
--

 Summary: Remove usage of org.json from Log WebConsole Module
 Key: SLING-6529
 URL: https://issues.apache.org/jira/browse/SLING-6529
 Project: Sling
  Issue Type: Task
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log WebConsole 1.0.2


We have to replace the usage of org.json. Here we just need to update the 
dependency to latest Felix WebConsole Bundle which does not depend on org.json



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

[jira] [Created] (SLING-6528) Installation of a package through the package manager should trigger a new cycle in the OSGi Installer

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6528:
--

 Summary: Installation of a package through the package manager 
should trigger a new cycle in the OSGi Installer
 Key: SLING-6528
 URL: https://issues.apache.org/jira/browse/SLING-6528
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Packages Factory 1.0.0
Reporter: Konrad Windszus
 Fix For: Installer Packages Factory 1.0.0


Whenever a content-package is lacking some dependencies the installation is 
deferred in 
https://github.com/apache/sling/blob/trunk/installer/factories/packages/src/main/java/org/apache/sling/installer/factory/packages/impl/PackageTransformer.java#L234.
If the dependent package is now installed via the package manager directly 
(instead of using the OSGi Installer), the dependent package is not being 
installed till some other event causes the next OSGi Installer cycle, because 
the OSGi Installer simply won't detect that "external" installation.



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

[RESULT] [VOTE] Release Apache Sling Content Distribution Core 0.2.4

[Timothee Maret]

Hi,

The vote has passed with the following result :

+1 (binding): Daniel K., Robert M., Carsten Z.
+1 (non binding): Tommaso T.


@PMC Could someone please copy this release to the Sling dist directory ?
I'll take care of the remaining steps beside that one.

Regards,

Timothee

[jira] [Updated] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not 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:
---
Attachment: SLING-6392-v02.patch

Attached is a new patch [^SLING-6392-v02.patch] which makes sure that the 
resource transformers create multiple resources with different url suffixes. I 
tested the patch now against the product which failed initially (AEM 6.3 beta) 
and now everything works.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-test-v01.patch, SLING-6392-test-v02.patch, 
> SLING-6392-v01.patch, SLING-6392-v02.patch
>
>
> 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.15#6346)

Re: Parameter Support, Filters and Missing Parameters

[Julian Sedding]

Hi Andy

You can register a javax.servlet.Filter with Sling OR with the Felix
Whiteboard. If you want to run before the SlingMainServlet, you have
to register your filter in the Felix whiteboard (which is what the
I18NFilter does). Note that you will not have access to
SlingHttpServletRequest objects in that case.

The documentation for the Felix Whiteboard describes properties to
select a specific HTTP context[0] by adding some properties. Maybe
that helps you to get your code working.

Regards
Julian

[0] 
https://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#filter-service-properties


On Sat, Feb 18, 2017 at 1:59 AM, Andreas Schaefer Sr.  wrote:
> Hi
>
> I tried to create a Filter to showcase the issue but I do fail with the latest
> code base.
>
> The reason is that I cannot add a filter ahead of the Sling Main Servlet even
> though there is the I18N and SSL Filter that are running ahead of it.
> For a customer I use that in order to adjust the query string and the 
> parameters
> and of late also the session timeout (bug in felix).
>
> Funny thing is that my filter is called when I access the OSGi Console then
> the filter is called just not when I work with a sling page (slingshot).
>
> Question: is is still possible to add a filter ahead of Sling Main Servlet 
> and if
> so what are the configuration. This is what I tried:
>
> 1) Does only work if sling some is enabled but then I am not ahead of the 
> Sling Main Servlet
>
> //@Component( immediate = true, label="Parameter Issue Filter", 
> description="Filters Requests to demonstrate the Parameter Issue in Sling", 
> metatype=false )
> //@Service
> //@Properties(
> //{
> //@Property( name="service.description", value="Parameter Issue 
> Filter" ),
> //@Property( name="service.vendor", value="Adobe" ),
> @Property(name="sling.filter.scope", value="request")
> //@Property( name="pattern", value="/", propertyPrivate=true )
> //}
> //)
>
> 2) Taken from the SslFilter but I am not ahead of the Sling Main Servlet
>
> //@SlingFilter(generateService = true, label = "Parameter Issue Filter",
> //order = 500, scope = { SlingFilterScope.REQUEST, SlingFilterScope.ERROR 
> })
> //@Properties({
> //@Property(name = "pattern", value="/.*"),
> //@Property(name = Constants.SERVICE_DESCRIPTION, value = "Filters 
> Requests to demonstrate the Parameter Issue in Sling"),
> //@Property(name = Constants.SERVICE_VENDOR, value = "Madplanet.com") })
>
> 2) Taken from the I18NFilter but this one is not called for Sling page
>
> @Component(immediate = true, policy = ConfigurationPolicy.IGNORE, label = 
> "Parameter Issue Filter")
> @Service(value = Filter.class)
> @Properties({
> @Property(name = "pattern", value = "/.*"),
> @Property(name = Constants.SERVICE_RANKING, intValue = 0x8100),
> @Property(name = "service.description", value = "Filters Requests to 
> demonstrate the Parameter Issue in Sling"),
> @Property(name = "service.vendor", value = "Madplanet.com")
> })
>
> I traced it down to the Per Context Handler Registry but I am unable to 
> register
> my Filter with the one responsible for Sling pages.
>
> Any help would be greatly appreciated.
>
> This is 3rd client where I had to use a Filter ahead of the Sling Resource 
> Resolution
> do make changes to the request before the resource is resolved.
>
>
> If that is not possible is there a way to make changes to the sling resource
> in a filter like when I rewrite the URL to manage (AEM) dispatcher cache
> for stuff like CSS or images?
>
> Thanks - Andy Schaefer
>
>> On Feb 16, 2017, at 4:05 AM, Robert Munteanu  wrote:
>>
>> Hi Andy,
>>
>> On Tue, 2017-02-14 at 14:05 -0800, Andreas Schaefer Sr. wrote:
>>> While working on AEM 6.2 SP1 with a Servlet Filter
>>> I came across issues with the Parameter Support
>>> as they interfere with the Servlet Filters or at least
>>> with Servlet Filters that are handled before entering
>>> the “Sling domain”.
>>>
>>> 1) Because of the SlingHttpContext.handleSecurity()
>>> the Parameter Support is created as one of the first
>>> Servlet Filters.
>>> 2) That Parameter Support reads the parameters from the
>>> Servlet Input stream
>>>
>>> 3) The Parameter Support Request Wrapper is ditched later
>>>
>>> 4) Any later filter will not have access to the parameters
>>> from the request
>>>
>>> 5) Any Filter that wraps the Servlet Request to change
>>> either the Query String or Parameter(s) will do that in vein
>>> as the stored Parameter Support in 1) will provide the
>>> parameters for anything in Sling
>>>
>>> In my current project I am storing the Query String
>>> which can be quite long in a Session and re-hydrate
>>> that in a Filter. This worked in AEM 6.0 but now fails
>>> due to the issues from above.
>>>
>>> I don’t mind the Parameter Support but it should
>>> check in the getInstance() method if the request was wrapped
>>> and if then 

Re: Removing dependency to org.json

[Carsten Ziegeler]

Chetan Mehrotra wrote
> Hi Carsten,
> 
> I can take care of log,metrics,slf4j-mdc
> 
> Whats the recommended approach to replace the current usage?

As an exampled I've replaced the usage in the metrics project.

I've also removed the usage from launchpad.

Regards
Carsten

 

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

[jira] [Resolved] (SLING-6527) Remove usage of org.json from metrics module

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6527.
-
Resolution: Fixed

Replaced in rev 1783721

> Remove usage of org.json from metrics module
> 
>
> Key: SLING-6527
> URL: https://issues.apache.org/jira/browse/SLING-6527
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Commons Metrics 1.2.2
>
>
> We have to replace the usage of org.json.
> In this case we can easily embed the JSONWriter from the Apache Felix Utils 
> module



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

[jira] [Created] (SLING-6527) Remove usage of org.json from metrics module

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6527:
---

 Summary: Remove usage of org.json from metrics module
 Key: SLING-6527
 URL: https://issues.apache.org/jira/browse/SLING-6527
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Commons Metrics 1.2.2


We have to replace the usage of org.json.

In this case we can easily embed the JSONWriter from the Apache Felix Utils 
module



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