[jira] [Commented] (SLING-6963) Service user declaration based on principal names

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6963:
--

Thanks, [~anchela]. I quickly reviewed the patch. Basically I like this idea 
very much.

There are a few comments, though:

* As [~cziegeler] indicated, please refrain from adding the Guava library as a 
dependency to the ServiceUserMapper (unfortunately, this seems to already have 
been made in the jcr.base bundle :-(
* There is a change in semantics in an internal/private method. While it has no 
consequences, I would prefer to not have it (see respective two comments on the 
isValidUser and areValidPrincipals methods)
* I would prefer to not enforce an increased version dependency on the 
ServiceUserMapper service in the jcr.base bundle. Rather I would suggest to 
keep the dependency low and check whether the getServicePrincipalNames method 
is available on the ServiceUserMapper service bound.

> Service user declaration based on principal names
> -
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6702:
--

bq. prevent it from getting unregistering

[~chetanm] This is just not possible: Consider the bundle is stopped and 
restarted.

bq. Note that currently MetricsServiceImpl is not using any OSGi config and has 
no required dependency on any other service.

As you say currently. When you add it and forget to abide by the expectation of 
MetricsServiceFactory, you get a failure.

Your call to ignore this warning, but it is an existing fragility.

> Make MetricsService accessible as easily as a Logger
> 
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Commons Metrics 1.2.2
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the 
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module, 
> usable like
> {code}
>   MetricsService ms = 
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module, 
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.



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

[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6702:
--

I appreciate the idea and I agree it makes a lot of sense.

But the current implementation has a hidden fragility: If the MetricsService is 
unregistered, the MetricsService object handed out will be invalid and cause 
secondary exceptions when recording metrics through it. This is because the 
consumer of the MetricsService object has no knowledge about the service being 
unregistered and the object invalid.

Maybe a wrapper implementation hiding this in the background and automatically 
rewiring when the service comes back, might help.

(and no, please don't add a "MetricsService.isValid" method ;-) )

> Make MetricsService accessible as easily as a Logger
> 
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Commons Metrics 1.2.2
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the 
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module, 
> usable like
> {code}
>   MetricsService ms = 
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module, 
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.



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

[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6609:
--

Thanks, [~kwin]. Looks good except, I'd defer to {{get(String)}} instead of 
{{get(String, Class)}} as with the {{defaultValue}} being {{null}} we don't 
know the desired type and would have to assume {{Object}}, hence no conversion.

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6609:
--

Fully agreed with the safety net for compile time check as well as for 
documentation of adding this annotation.

The question about historic and so is whether this change actually changes 
semantics and/or existing expectations of the API. The documentation is not 
very clear right now, unfortunately.

For example, assume that historically we accepted null as can be seen from the 
ValueMapDecorator implementation. Now, we describe the API to not take null any 
longer. So a new implementation of course will not check for null and run into 
an NPE (which is fine because the API is not used according to the contract) 
while an old consumer who was assuming null to be ok as it has been so far 
might now run into that unexpected NPE.

Maybe you could add the annotation plus add an implementation note, that 
implementations should treat being called with {{defaultValue==null}} 
equivalent to {{get(String)}} and thus to check for {{null}}.

Of course this is debatable and in hind sight we should have properly define 
the API such that defaultValue must not be null (with the respective runtime 
check on implementations). But we are where we are.

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6609:
--

Ah, right, but historically, I am not sure, this really was the intent. 
Particularly if you look at the [ValueMapDecorator 
implementation|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/wrappers/ValueMapDecorator.java#L63]
 where there is an explicit {{null}} guard 

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6609:
--

Actually, I am not entirely sure, whether @Nonnull is technically entirely 
correct: The spec says, to return the named property or the {{defaultValue}}. 
What if the {{defaultValue}} is {{null}} ?

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

bq. Now coming to the point of overloading, if multiple validators register for 
the same "address" (be it based on "service.pid" or some other property), that 
would be already logged 
(https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationModelRetrieverImpl.java#L170).
 Probably it would be good to take the "service.ranking" into consideration for 
those cases, to make sure the highest service ranking get actually bound.

Ok, this is currently just a DEBUG message, which may be changed, of course.

The question remains: Is this a use case ? Or would that be stretching the 
boundaries (and we all know developers love to do that) ?



> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

Hmm, in a private conversation [~cziegeler] mentioned "overloading" of 
validators. Consider a validator x.y.z is configured and provided by bundle 
a.b.c. Now another bundle f.g.h wants to register a different validation 
behaviour for this configured validator x.y.z. So f.g.h registers another 
validator with that name/identity but a higher service ranking value.

In this case, using the service.pid which is defined to be a "unique 
identifier" (but not enforced), is somewhat dubious.

Is that a use case here for validators ?
Don't we make reasonating about which validators actually apply harder ?

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

I don't understand this ?

Is the general use of the service.pid property tied to Configuration Admin ? It 
is not. To the contrary. Configuration Admin is just reusing it for its own 
purposes with two specific services: ManagedService and ManagedServiceFactory.

Configuration Admin does not generalize the use of service.pid.

Declarative Services goes another step by using the component name (or 
configuration-pid) as the identifier for the configuration which causes the 
service.pid to be set as if Configuration Admin would provide configuration to 
ManagedService or ManagedServiceFactory.

This might lead to that misconception. But this is not forced. By simply 
setting a service.pid component property you get the desired result.

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Comment Edited] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6578 at 3/1/17 11:37 AM:
---

bq. service.pid is not reliable - with a DS component you only have a 
service.pid if the component is configurable through an OSGi configuration and 
such a configuration exists.

This is not entirely correct, fortunately. You can very well add a service.pid 
property to the component properties e.g. through the @Property annotation. 
This is actually stipulated by the quote on merging service.pid property values 
in my previous comment.

Using a separate property will just bloat the property space for referring to 
services. You will end with this function using this tada.id property and that 
function using that hurray.id property, etc.

Why not just service.pid ?

Using the PropertyUtil, you can easily just convert the property to a String[] 
and ignore the fact that service.pid may be String, String[] or even 
Collection.


was (Author: fmeschbe):
bq. service.pid is not reliable - with a DS component you only have a 
service.pid if the component is configurable through an OSGi configuration and 
such a configuration exists.

This is not entirely correct, fortunately. You can very well add a service.pid 
property to the component properties e.g. through the @Property annotation. 
This is actually stipulated by the quote on merging service.pid property values 
in my previous comment.

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

bq. service.pid is not reliable - with a DS component you only have a 
service.pid if the component is configurable through an OSGi configuration and 
such a configuration exists.

This is not entirely correct, fortunately. You can very well add a service.pid 
property to the component properties e.g. through the @Property annotation. 
This is actually stipulated by the quote on merging service.pid property values 
in my previous comment.

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Comment Edited] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6578 at 3/1/17 11:09 AM:
---

I like [~olli] idea. The property is easily identified as a filter if it starts 
with an opening bracket {{(}}. Otherwise you may assume a service.pid.


was (Author: fmeschbe):
I like [~olli] idea. The property is easily identified as a filter if it starts 
with an opening bracket {{(}}

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

I like [~olli] idea. The property is easily identified as a filter if it starts 
with an opening bracket {{(}}

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

TL;DR: Suggest to still use the service.pid. Define the function to use the 
service.pid for references and it will be usable.

Well, yes, the service.pid for factory configurations will be automatically 
generated, yet it is stable. And actually, please don't call it UUID. It just 
so happens in the Apache Felix implementations. The specifications just says, 
it must be unique, it could just as well be a counter.

I think we have to make sure to not mix concepts and specifications and 
expectations.

"service.pid" can be assigned to any service as a static identifier. 
Independent of anything else in the OSGi world of specifications and services.

Declarative Services uses the configuration pid which may be the 
configuration-pid or name attribute of the component declaration to link the 
Configuration Admin configuration to the component. Depending on whether the 
configuration pid refers to a factory configuration PID or a singleton 
configurtion PID, multiple component instances or a single component instance 
may be created. So far this has nothing to do with service.pid or 
service.factoryPid. At most it is component.name which is something specific to 
Declarative Services.

Also note that when talking "component", I would expect people to generally 
assume a Declarative Services component. This may or may not be a service (it 
generally is, but there is no requirement). And it has nothing to do with how 
the service is referred to. Declarative Services is just a way to deploy 
services. It is not a prescriptive way of consuming services. And depending on 
Declarative Services for service deployment, when you consume services, is just 
plain wrong (and fragile, and so).

Next in the game is Configuration Admin Service. Configuration Admin Service 
uses the service.pid property of a ManagedService or ManagedServiceFactory 
service to decide what configuration to provide to the respective 
ManagedService\[Factory\]. This is a specifically define use of the service.pid 
property for specific services (ManagedService and ManagedServiceFactory) and 
it is defined how the service.pid value is used in this context. Configuration 
Admin sets a number of properties in the configuration object provided to 
configuration consumers: service.pid to be configuration object identifier, 
service.factoryPid to be the factory configuration (collection of similar 
configurations) identifier and service.bundleLocation to identify the 
configuration "owner".

The complexity that you may encounter stems from the fact, that Declarative 
Services uses all the (public) properties of Configuration Admin Configuration 
as service properties when registering services. This means, that in the 
context of Declarative Services, the service.pid property may be derived from 
the configuration supplied by the Configuration Admin service.

But the Declarative Services specification also states:

{quote}
If the component description specifies multiple configuration PIDs, then the 
order of the service.pid property values from the corresponding configurations 
matches the order the configuration PIDs are specified in the component 
description. The values of the service.pid component property are the values as 
they come from the configuration sources which, for Configuration objects, may 
be more detailed than the configuration PIDs specified in the component 
description.
{quote}

This means, that for a DS component, the service.pid is the combination of the 
service.pid property set as a static component property plus the service.pid 
from the configuration object.

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Comment Edited] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6578 at 3/1/17 11:04 AM:
---

I think we should still use the service.pid. According to the spec:

{quote}
The purpose of a Persistent Identifier (PID) is to identify a service across 
Framework restarts. Services that can reference the same underlying entity 
every time they are registered should therefore use a service property that 
contains a PID. The name of the service property for PID is defined as 
service.pid. The PID is a unique identifier for a service that persists over 
multiple invocations of the Framework. For a given service, the same PID should 
always be used. If the bundle is stopped and later started, the same PID must 
always be used.

The format of the PID should be:
pid ::= symbolic-name   // See 1.3.2
{quote}

Yes, it is optional. But it serves to stably identify the service across 
restarts. Of course you can go ahead and reinvent wheels and define a new 
service property which is expected to be set. But this is exactly the same: It 
is optional and may or may not exist.

Why not just define: service.pid is used. If missing, the service is ignored -- 
which is correct anyway as the service is not "addressable"

Also: I am not entirely sure the SLING-5839 case really applies to this 
discussion.


was (Author: fmeschbe):
I think we should still use the service.pid. According to the spec:

 The purpose of a Persistent Identifier (PID) is to identify a service 
across Framework restarts. Ser-
 vices that can reference the same underlying entity every time they are 
registered should therefore
 use a service property that contains a PID. The name of the service 
property for PID is defined as
 service.pid. The PID is a unique identifier for a service that persists 
over multiple invocations of the
 Framework. For a given service, the same PID should always be used. If the 
bundle is stopped and
 later started, the same PID must always be used.

 The format of the PID should be:
pid ::= symbolic-name   // See 1.3.2

Yes, it is optional. But it serves to stably identify the service across 
restarts. Of course you can go ahead and reinvent wheels and define a new 
service property which is expected to be set. But this is exactly the same: It 
is optional and may or may not exist.

Why not just define: service.pid is used. If missing, the service is ignored -- 
which is correct anyway as the service is not "addressable"

Also: I am not entirely sure the SLING-5839 case really applies to this 
discussion.

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

Beware, though, [~kwin]: "component.name" is only guaranteed to exist for a 
Declarative Services component as it is defined in the context of the 
Declarative Services specification. For any service registered otherwise like 
direct BundleContext.registerService or Blueprint, this property will most 
probably not exist.

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration. The fallback should be the property "component.name" 
> as "service.pid" is not always necessarily set. Basically the validator 
> should be referable via each of those value, i.e. one of the "service.pid"s 
> or the "component.name".



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

[jira] [Comment Edited] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6578 at 3/1/17 9:03 AM:
--

I think we should still use the service.pid. According to the spec:

 The purpose of a Persistent Identifier (PID) is to identify a service 
across Framework restarts. Ser-
 vices that can reference the same underlying entity every time they are 
registered should therefore
 use a service property that contains a PID. The name of the service 
property for PID is defined as
 service.pid. The PID is a unique identifier for a service that persists 
over multiple invocations of the
 Framework. For a given service, the same PID should always be used. If the 
bundle is stopped and
 later started, the same PID must always be used.

 The format of the PID should be:
pid ::= symbolic-name   // See 1.3.2

Yes, it is optional. But it serves to stably identify the service across 
restarts. Of course you can go ahead and reinvent wheels and define a new 
service property which is expected to be set. But this is exactly the same: It 
is optional and may or may not exist.

Why not just define: service.pid is used. If missing, the service is ignored -- 
which is correct anyway as the service is not "addressable"

Also: I am not entirely sure the SLING-5839 case really applies to this 
discussion.


was (Author: fmeschbe):
I think we should still use the service.pid. According to the spec:

 The purpose of a Persistent Identifier (PID) is to identify a service 
across Framework restarts. Ser-
 vices that can reference the same underlying entity every time they are 
registered should therefore
 use a service property that contains a PID. The name of the service 
property for PID is defined as
 service.pid. The PID is a unique identifier for a service that persists 
over multiple invocations of the
 Framework. For a given service, the same PID should always be used. If the 
bundle is stopped and
 later started, the same PID must always be used.

 The format of the PID should be:
pid ::= symbolic-name   // See 1.3.2

Yes, it is optional. But it serves to stably identify the service across 
restarts. Of course you can go ahead and reinvent wheels and define a new 
service property which is expected to be set. But this is exactly the same: It 
is optional and may or may not exist.

Why not just define: service.pid is used. If missing, the service is ignored -- 
which is correct anyway as the service is not "addressable"

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration.



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

[jira] [Commented] (SLING-6578) Use "service.pid" property instead of class name to reference validators

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6578:
--

I think we should still use the service.pid. According to the spec:

 The purpose of a Persistent Identifier (PID) is to identify a service 
across Framework restarts. Ser-
 vices that can reference the same underlying entity every time they are 
registered should therefore
 use a service property that contains a PID. The name of the service 
property for PID is defined as
 service.pid. The PID is a unique identifier for a service that persists 
over multiple invocations of the
 Framework. For a given service, the same PID should always be used. If the 
bundle is stopped and
 later started, the same PID must always be used.

 The format of the PID should be:
pid ::= symbolic-name   // See 1.3.2

Yes, it is optional. But it serves to stably identify the service across 
restarts. Of course you can go ahead and reinvent wheels and define a new 
service property which is expected to be set. But this is exactly the same: It 
is optional and may or may not exist.

Why not just define: service.pid is used. If missing, the service is ignored -- 
which is correct anyway as the service is not "addressable"

> Use "service.pid" property instead of class name to reference validators
> 
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its 
> classname is more stable (even if implementation changes, the PID might stay 
> the same) and also allows for configuration factories to refer to a specific 
> validator configuration.



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

Re: SLING_ prefix for selectors that we use "internally" ?

[Felix Meschberger]

Hi

But if you insiste on a prefix, I suggest to use something nicer looking than 
SLING_.

How about sling. ? Hence sling.bla such as /path/to/resource.sling.bla.html ?

Yet, I agree with Carsten that I am not sure, whether this really is required. 
On the other hand, using a specific selector would make it easier to filter 
selectors through a proxy...

Regards
Felix

> Am 28.02.2017 um 14:24 schrieb Bertrand Delacretaz :
> 
> On Tue, Feb 28, 2017 at 11:44 AM, Carsten Ziegeler  
> wrote:
>> ...The script is usually selected by the combination of resource type, 
>> selector and extension...
> 
> The SlingBindingsVariablesListJsonServlet [1] has to use the
> sling/servlet/default resource type, by design, so I think the prefix
> is useful here.
> 
> -Bertrand
> 
> [1] 
> https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/SlingBindingsVariablesListJsonServlet.java

[jira] [Comment Edited] (SLING-6548) Provide framework extension fragment for Servlet JSP API

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6548 at 2/22/17 2:58 PM:
---

I am not sure, this is a good idea !

JSP API must be isolated from the environment as we implement our own stuff in 
Sling. "Inheriting" from the environment means, that we are starting to mix 
environmental API with implementation requirements.

If you want to leverage the JSP API from the environment this must be properly 
"coupled" to the actual JSP implementation. So, what you might investigate is 
actually trying to replace the Jasper implementation (as part of the Scripting 
JSP bundle) with the JSP API implementation from the environment -- but this 
would require proper hooking into that implementation for the Scripting JSP 
bundle to still work !

Also see my comment in SLING-6502


was (Author: fmeschbe):
I am not sure, this is a good idea !

JSP API must be isolated from the environment as we implement our own stuff in 
Sling. "Inheriting" from the environment means, that we are starting to mix 
environmental API with implementation requirements.

If you want to leverage the JSP API from the environment this must be properly 
"coupled" to the actual JSP implementation. So, what you might investigate is 
actually trying to replace the Jasper implementation (as part of the Scripting 
JSP bundle) with the JSP API implementation from the environment -- but this 
would require proper hooking into that implementation for the Scripting JSP 
bundle to still work !

> Provide framework extension fragment for Servlet JSP API
> 
>
> Key: SLING-6548
> URL: https://issues.apache.org/jira/browse/SLING-6548
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
> Fix For: Framework Extension Fragment Servlet JSP API 1.0.0
>
>
> fragment for {{javax.servlet.jsp}} (Servlet JSP API)



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

[jira] [Commented] (SLING-6549) Provide framework extension fragment for EL API

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6549:
--

[~olli] Thanks for the reference, just commented there

> Provide framework extension fragment for EL API
> ---
>
> Key: SLING-6549
> URL: https://issues.apache.org/jira/browse/SLING-6549
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
> Fix For: Framework Extension Fragment EL API 1.0.0
>
>
> fragment for {{javax.el}} (EL API)



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

[jira] [Commented] (SLING-6502) JSP: java.lang.VerifyError (Bad type on operand stack)

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6502:
--

Hmm, I think the things you are doing here are becoming fragile and needs 
proper vetting.

The Launchpad bundle basically has two artifacts:

  * Standalone Java Application just bridging into the JVM in a controlled way
  * Web Application Archive (WAR), where we bridge to servlet container in 
controlled way by adding the Servlet API (and only the Servlet API) to the 
framework system packages. The EL and JSP API are not bridged because we have 
our own implementation.

I am not sure how the Karaf integration works, but I assume that you have to 
control the API deployed in the Karaf system as you are probably not making use 
of the Launchpad but directly deploy the Sling bundles into the Karaf framework 
as a Karaf feature, right ?

> JSP: java.lang.VerifyError (Bad type on operand stack)
> --
>
> Key: SLING-6502
> URL: https://issues.apache.org/jira/browse/SLING-6502
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.2.6
> Environment: Apache Karaf 4.1.0-SNAPSHOT (Pax Web 6.0.2)
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JSP 2.2.8
>
> Attachments: apis.patch
>
>
> {{org.apache.sling.scripting.jsp}} embeds {{jsp-api}} and {{el-api}} from 
> Apache Tomcat ({{6.0.14}}) which causes this error.
> {noformat}
> [...]
> [httpclient.wire.header] : << "HTTP/1.1 500 Server Error[\r][\n]"
> [httpclient.wire.header] : << "Content-Type: text/html;charset=utf-8[\r][\n]"
> [httpclient.wire.header] : << "Transfer-Encoding: chunked[\r][\n]"
> [httpclient.wire.header] : << "Server: Jetty(9.3.15.v20161220)[\r][\n]"
> [httpclient.wire.header] : << "[\r][\n]"
> [httpclient.wire.content] : << "B"
> [httpclient.wire.content] : << "5"
> [httpclient.wire.content] : << "1"
> [httpclient.wire.content] : << "[\r]"
> [httpclient.wire.content] : << "[\n]"
> [httpclient.wire.content] : << "[\n]"
> [httpclient.wire.content] : << "java.lang.VerifyError: Bad type on operand 
> stack[\n]"
> [httpclient.wire.content] : << "Exception Details:[\n]"
> [httpclient.wire.content] : << "  Location:[\n]"
> [httpclient.wire.content] : << "
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl.createELResolver()Ljavax/el/ELResolver;
>  @28: invokevirtual[\n]"
> [httpclient.wire.content] : << "  Reason:[\n]"
> [httpclient.wire.content] : << "Type 
> javax/servlet/jsp/el/ImplicitObjectELResolver (current frame, 
> stack[1]) is not assignable to javax/el/ELResolver[\n]"
> [httpclient.wire.content] : << "  Current Frame:[\n]"
> [httpclient.wire.content] : << "bci: @28[\n]"
> [httpclient.wire.content] : << "flags: { }[\n]"
> [httpclient.wire.content] : << "locals: { 
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl,
>  javax/el/CompositeELResolver }[\n]"
> [httpclient.wire.content] : << "stack: { 
> javax/el/CompositeELResolver, 
> javax/servlet/jsp/el/ImplicitObjectELResolver }[\n]"
> [httpclient.wire.content] : << "  Bytecode:[\n]"
> [httpclient.wire.content] : << "0x000: 2a04 b500 062a b400 1dc7 0080 
> bb00 1e59[\n]"
> [httpclient.wire.content] : << "0x010: b700 1f4c 2bbb 0020 59b7 0021 
> b600 222a[\n]"
> [httpclient.wire.content] : << "0x020: b400 05b9 0023 0100 4d2c b900 
> 2401 0099[\n]"
> [httpclient.wire.content] : << "0x030: 0013 2b2c b900 2501 00c0 0026 
> b600 22a7[\n]"
> [httpclient.wire.content] : << "0x040: ffea 2bbb 0027 59b7 0028 b600 
> 222b bb00[\n]"
> [httpclient.wire.content] : << "0x050: 2959 b700 2ab6 0022 2bbb 002b 
> 59b7 002c[\n]"
> [httpclient.wire.content] : << "0x060: b600 222b bb00 2d59 b700 2eb6 
> 0022 2bbb[\n]"
> [httpclient.wire.content] : << "0x070: 002f 59b7 0030 b600 222b bb00 
> 3159 b700[\n]"
> [httpclient.wire.content] : << "0x080: 32b6 0022 2a2b b500 1d2a b400 
> 1db0 [\n]"
>

[jira] [Comment Edited] (SLING-6549) Provide framework extension fragment for EL API

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6549 at 2/22/17 2:54 PM:
---

I am not sure, this is a good idea !

EL must be isolated from the environment as we implement our own stuff in 
Sling. "Inheriting" from the environment means, that we are starting to mix 
environmental API with implementation requirements.

If you want to use the environment's EL, then you also would have to use the 
environment's EL implementation, which might collide with our Scripting JSP 
bundle with embedded Jasper.


was (Author: fmeschbe):
I am not sure, this is a good idea !

EL must be isolated from the environment as we implement our own stuff in 
Sling. "Inheriting" from the environment means, that we are starting to mix 
environmental API with implementation requirements.

> Provide framework extension fragment for EL API
> ---
>
> Key: SLING-6549
> URL: https://issues.apache.org/jira/browse/SLING-6549
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
> Fix For: Framework Extension Fragment EL API 1.0.0
>
>
> fragment for {{javax.el}} (EL API)



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

[jira] [Commented] (SLING-6548) Provide framework extension fragment for Servlet JSP API

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6548:
--

I am not sure, this is a good idea !

JSP API must be isolated from the environment as we implement our own stuff in 
Sling. "Inheriting" from the environment means, that we are starting to mix 
environmental API with implementation requirements.

If you want to leverage the JSP API from the environment this must be properly 
"coupled" to the actual JSP implementation. So, what you might investigate is 
actually trying to replace the Jasper implementation (as part of the Scripting 
JSP bundle) with the JSP API implementation from the environment -- but this 
would require proper hooking into that implementation for the Scripting JSP 
bundle to still work !

> Provide framework extension fragment for Servlet JSP API
> 
>
> Key: SLING-6548
> URL: https://issues.apache.org/jira/browse/SLING-6548
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
> Fix For: Framework Extension Fragment Servlet JSP API 1.0.0
>
>
> fragment for {{javax.servlet.jsp}} (Servlet JSP API)



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

[jira] [Commented] (SLING-6549) Provide framework extension fragment for EL API

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6549:
--

I am not sure, this is a good idea !

EL must be isolated from the environment as we implement our own stuff in 
Sling. "Inheriting" from the environment means, that we are starting to mix 
environmental API with implementation requirements.

> Provide framework extension fragment for EL API
> ---
>
> Key: SLING-6549
> URL: https://issues.apache.org/jira/browse/SLING-6549
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
> Fix For: Framework Extension Fragment EL API 1.0.0
>
>
> fragment for {{javax.el}} (EL API)



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

[jira] [Comment Edited] (SLING-6550) Remove Servlet API from org.apache.sling.launcher.system.packages

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6550 at 2/22/17 2:45 PM:
---

Can you elaborate a bit what this is about ?

SlingServletDelegate is the bridge between the embedding Web Application and 
the Sling (Felix Framework) instance. So the Servlet API must not be part as it 
is provided by the Servlet Container.


was (Author: fmeschbe):
Can you elaborate a bit what this is about ?

> Remove Servlet API from org.apache.sling.launcher.system.packages
> -
>
> Key: SLING-6550
> URL: https://issues.apache.org/jira/browse/SLING-6550
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.6.16
>Reporter: Oliver Lietz
>
> remove servlet packages from {{SlingServletDelegate}} and use framework 
> extension fragment (SLING-6547) instead



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

[jira] [Commented] (SLING-6550) Remove Servlet API from org.apache.sling.launcher.system.packages

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6550:
--

Can you elaborate a bit what this is about ?

> Remove Servlet API from org.apache.sling.launcher.system.packages
> -
>
> Key: SLING-6550
> URL: https://issues.apache.org/jira/browse/SLING-6550
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.6.16
>Reporter: Oliver Lietz
>
> remove servlet packages from {{SlingServletDelegate}} and use framework 
> extension fragment (SLING-6547) instead



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

[jira] [Commented] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6046:
--

> The patch we finally applied actually sends Range header for 
> sling.contentlength >100 MB but comment says 100 KB. I believe 100 MB was the 
> real intention or if it was 100 KB , we need to redo the patch.

[~ashokpanghal] Argh. Sorry about that. I only now realize that the 
implementation (constant) was not according to the spec (comment) ...

> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> 
>
> Key: SLING-6046
> URL: https://issues.apache.org/jira/browse/SLING-6046
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Ashok Kumar
>Assignee: Ian Boston
> Fix For: Servlets Get 2.1.20
>
> Attachments: Accept-Range Respone Header from S3.png, 
> NetworkDataS3VideoFromIE11.xml, S3video.html, 
> StreamRendererServlet_100KB.patch
>
>
> Since IE 11 expects "Accept-Ranges" [0] response header to start making 
> requests with Range header, so sling lack in streaming of video content for 
> IE end users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
> Without support of partial content response (206) for IE users, all large 
> video files are being downloaded in single chunk and user need to wait for 
> long to see video content playing. 
> [0] http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11 
>  



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

Re: Exclude IntelliJ Modules Files from rat plugin

[Felix Meschberger]

Hi

Goot point.

And also: Are these files in subversion ? If they are, they should be removed 
and excluded by configuration. They don’t belong there.

Regards
Felix

> Am 27.01.2017 um 11:24 schrieb Clelia Meneghin :
> 
> Hi
> 
> Currently any present IntelliJ Module Files will cause the rat plugin to fail 
> to build. I suggest to exclude them in the parent poms rat plugin 
> configurations.
> 
> I created an issue [0]
> 
> Regards,
> Clelia
> 
> [0] https://issues.apache.org/jira/browse/SLING-6488

Re: Name conventions for our core metrics?

[Felix Meschberger]

Hi

I like hierarchical names for name spacing. But can we do as most people do 
today and just use dots  (thus remove the colon) ?

Not sure whether we should stiplute a relation to the bundle or package name 
they are defined in because that might have negative consequences in case of 
refactorings.

Regards
Felix

> Am 26.01.2017 um 12:13 schrieb Bertrand Delacretaz :
> 
> Hi,
> 
> As mentioned earlier I'll be coaching a small student project in
> March, to start adding metrics to our core as per SLING-5410
> 
> We need to define conventions for the metrics names, currently
> /system/console/slingmetrics shows Oak metrics with names like
> oak:SOME_METRIC
> 
> Do we want to follow that convention or a similar one?
> 
> If similar I suggest hierarchical names like sling:engine.requests.count , 
> WDYT?
> 
> -Bertrand

[jira] [Commented] (SLING-6458) JSP scripting does not support Java 8 features (lambdas, method references, etc)

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6458:
--

Thanks [~cziegeler]. In this case I stand corrected and it really is about 
topic (1): Update Jasper.

> JSP scripting does not support Java 8 features (lambdas, method references, 
> etc)
> 
>
> Key: SLING-6458
> URL: https://issues.apache.org/jira/browse/SLING-6458
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.28, Scripting JSP 2.1.0, Scripting JSP 
> 2.1.4, Scripting JSP 2.1.6, Scripting JSP 2.1.8, Scripting JSP 2.2.0, 
> Scripting JSP 2.2.2, Scripting JSP 2.2.4, Scripting JSP 2.2.6
>Reporter: Henry Kuijpers
>
> When trying to use Java 8 functionality in a JSP file, the Jasper framework 
> in the Sling Scripting bundle fails to compile the JSP file. It seems to get 
> stuck on a Java 8 feature: Lambdas.
> {code}
> <%@page session="false" %>
> <%@ page import="java.util.stream.IntStream" %>
> <%@ page import="java.io.IOException" %>
> <%
> out.println("Lambda test");
> IntStream leip = IntStream.of(1, 2, 3, 4, 5, 6);
> final JspWriter out2 = out;
> leip.forEach(x -> {
> try {
> out2.println(x);
> } catch (IOException e) {
> // Intentionally do nothing
> }
> });
> %>
> {code}
> When we remove the complete "leip.forEach" statement, the code compiles and 
> executes successfully.
> Upon further investigation, I found out that the Jasper compiler that is 
> being used, does not have support for "tag 18", which seems to be the lambda 
> feature in Java 8.
> I could find the constant pool tags over here: 
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4-140 
> Clearly, there is no support for MethodHandle, MethodType, InvokeDynamic.
> I could find a bug report for Tomcat (where Jasper is developed) over here: 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=54475 
> It seems that the issue was fixed in a newer version of Jasper, namely 
> 6.0.40. We are currently using 6.0.14 (which is in Apache Sling Scripting JSP 
> version bundle version 2.1.4). 
> I tried looking at 
> https://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.scripting.jsp
>  but for some reason all newer versions are also embedding Jasper 6.0.14 
> (which does not support Java 8) and in the custom code inside that bundle I 
> also do not see any cases for 18 in the switch statement in 
> SmapUtil$SDEInstaller.copyConstantPool. Nor do I see any traces that look 
> like this fix: 
> https://bz.apache.org/bugzilla/attachment.cgi?id=31416=diff
> See below a stacktrace of what's happening:
> {code}
> 12.01.2017 14:39:19.063 *ERROR* [144.119.190.210 [1484228359038] POST 
> /content/page/sign-up.html HTTP/1.1] 
> org.apache.sling.servlets.get.impl.DefaultGetServlet No renderer for 
> extension html, cannot render resource ResourceWrapper, 
> type=test/components/form/actions/register, 
> path=/content/page/sign-up/jcr:content/par/start, resource=[JcrNodeResource, 
> type=foundation/components/form/start, superType=null, 
> path=/content/page/sign-up/jcr:content/par/start]
> 12.01.2017 14:39:19.079 *ERROR* [144.119.190.210 [1484228359038] POST 
> /content/page/sign-up.html HTTP/1.1] com.day.cq.wcm.tags.IncludeTag Error 
> while executing script 
> /apps/test/components/form/actions/register/post.POST.jsp 
> org.apache.sling.api.scripting.ScriptEvaluationException: 
> org.apache.sling.scripting.jsp.jasper.JasperException: Unable to compile 
> class for JSP
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:388)
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:171)
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:463)
> at com.day.cq.wcm.tags.IncludeTag.includeScript(IncludeTag.java:167)
> at com.day.cq.wcm.tags.IncludeTag.doEndTag(IncludeTag.java:87)
> at 
> org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:50

[jira] [Commented] (SLING-6458) JSP scripting does not support Java 8 features (lambdas, method references, etc)

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6458:
--

There are two topics here:

* First that we are based on an old and venerable Jasper version. Unfortunately 
we have made some changes to Jasper, that are not integrated upstream (as they 
are Sling specific) so upgrading is not trivial. Nevertheless at one point in 
time we should upgrade to a more recent Jasper version, which my gut tells me 
should rather be from the Tomcat 8 or even Tomcat 9 series.
* Second the compiler converting the Java Code generated by Jasper to Byte 
Code. We are embedding the Eclipse compiler and it looks like that version of 
the Compiler does not support Java 8 (yet).

So, my impression for this issue is, that we basically should be upgrading the 
embedded Eclipse Compiler to the most recent version supporting Java 8 (and 
make sure the source/target version numbers for configuration support Java 8 as 
well)

> JSP scripting does not support Java 8 features (lambdas, method references, 
> etc)
> 
>
> Key: SLING-6458
> URL: https://issues.apache.org/jira/browse/SLING-6458
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.28, Scripting JSP 2.1.0, Scripting JSP 
> 2.1.4, Scripting JSP 2.1.6, Scripting JSP 2.1.8, Scripting JSP 2.2.0, 
> Scripting JSP 2.2.2, Scripting JSP 2.2.4, Scripting JSP 2.2.6
>Reporter: Henry Kuijpers
>
> When trying to use Java 8 functionality in a JSP file, the Jasper framework 
> in the Sling Scripting bundle fails to compile the JSP file. It seems to get 
> stuck on a Java 8 feature: Lambdas.
> {code}
> <%@page session="false" %>
> <%@ page import="java.util.stream.IntStream" %>
> <%@ page import="java.io.IOException" %>
> <%
> out.println("Lambda test");
> IntStream leip = IntStream.of(1, 2, 3, 4, 5, 6);
> final JspWriter out2 = out;
> leip.forEach(x -> {
> try {
> out2.println(x);
> } catch (IOException e) {
> // Intentionally do nothing
> }
> });
> %>
> {code}
> When we remove the complete "leip.forEach" statement, the code compiles and 
> executes successfully.
> Upon further investigation, I found out that the Jasper compiler that is 
> being used, does not have support for "tag 18", which seems to be the lambda 
> feature in Java 8.
> I could find the constant pool tags over here: 
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4-140 
> Clearly, there is no support for MethodHandle, MethodType, InvokeDynamic.
> I could find a bug report for Tomcat (where Jasper is developed) over here: 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=54475 
> It seems that the issue was fixed in a newer version of Jasper, namely 
> 6.0.40. We are currently using 6.0.14 (which is in Apache Sling Scripting JSP 
> version bundle version 2.1.4). 
> I tried looking at 
> https://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.scripting.jsp
>  but for some reason all newer versions are also embedding Jasper 6.0.14 
> (which does not support Java 8) and in the custom code inside that bundle I 
> also do not see any cases for 18 in the switch statement in 
> SmapUtil$SDEInstaller.copyConstantPool. Nor do I see any traces that look 
> like this fix: 
> https://bz.apache.org/bugzilla/attachment.cgi?id=31416=diff
> See below a stacktrace of what's happening:
> {code}
> 12.01.2017 14:39:19.063 *ERROR* [144.119.190.210 [1484228359038] POST 
> /content/page/sign-up.html HTTP/1.1] 
> org.apache.sling.servlets.get.impl.DefaultGetServlet No renderer for 
> extension html, cannot render resource ResourceWrapper, 
> type=test/components/form/actions/register, 
> path=/content/page/sign-up/jcr:content/par/start, resource=[JcrNodeResource, 
> type=foundation/components/form/start, superType=null, 
> path=/content/page/sign-up/jcr:content/par/start]
> 12.01.2017 14:39:19.079 *ERROR* [144.119.190.210 [1484228359038] POST 
> /content/page/sign-up.html HTTP/1.1] com.day.cq.wcm.tags.IncludeTag Error 
> while executing script 
> /apps/test/components/form/actions/register/post.POST.jsp 
> org.apache.sling.api.scripting.ScriptEvaluationException: 
> org.apache.sling.scripting.jsp.jasper.JasperException: Unable to compile 
> class for JSP
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSling

[jira] [Commented] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6046:
--

Proposing following patch with a threshold size of 100KB which I think is 
reasonable to fully download.

We can also change this threshold but there is not point in making it 
configurable, at least not for now, I think.

{code}
### Eclipse Workspace Patch 1.0
#P org.apache.sling.servlets.get
Index: 
src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java
===
--- 
src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java
 (Revision 1777535)
+++ 
src/main/java/org/apache/sling/servlets/get/impl/helpers/StreamRendererServlet.java
 (Arbeitskopie)
@@ -73,6 +73,17 @@
  */
 private static final String mimeSeparation = "SLING_MIME_BOUNDARY";
 
+// size threshold for sending an Accept-Ranges header back in the response 
(100KB)
+private static final int ACCEPT_RANGES_THRESHOLD = 100 * 1024 * 1024;
+
+// Accept-Ranges header name
+private static final String ACCEPT_RANGES_HEADER = "Accept-Ranges";
+
+// Accept-Ranges header value
+private static final String ACCEPT_RANGES_BYTES = "bytes";
+
+
+
 /**
  * Full range marker.
  */
@@ -393,6 +404,11 @@
 if (encoding != null) {
 response.setCharacterEncoding(encoding);
 }
+
+// announce support for ranges if we know the size to be larger than 
100KB
+if (meta.getContentLength() > ACCEPT_RANGES_THRESHOLD) {
+response.setHeader(ACCEPT_RANGES_HEADER, ACCEPT_RANGES_BYTES);
+}
 }
 
 /**
{code}

> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> 
>
> Key: SLING-6046
> URL: https://issues.apache.org/jira/browse/SLING-6046
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Ashok Kumar
> Fix For: Servlets Get 2.1.20
>
> Attachments: Accept-Range Respone Header from S3.png, 
> NetworkDataS3VideoFromIE11.xml, S3video.html, StreamRendererServlet.java.patch
>
>
> Since IE 11 expects "Accept-Ranges" [0] response header to start making 
> requests with Range header, so sling lack in streaming of video content for 
> IE end users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
> Without support of partial content response (206) for IE users, all large 
> video files are being downloaded in single chunk and user need to wait for 
> long to see video content playing. 
> [0] http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11 
>  



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

[jira] [Resolved] (SLING-6433) Request Processing Analyzer throws IOOB due to old format assumptions of RequestProgressTracker output

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-6433.
--
Resolution: Fixed
  Assignee: Felix Meschberger

Thanks for providing the patch. I have applied it in Rev. 1777305.

> Request Processing Analyzer throws IOOB due to old format assumptions of 
> RequestProgressTracker output
> --
>
> Key: SLING-6433
> URL: https://issues.apache.org/jira/browse/SLING-6433
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Krystian Nowak
>    Assignee: Felix Meschberger
> Fix For: Request Analyzer 1.0.0
>
> Attachments: SLING-6433-krystian.patch
>
>
> In certain cases Request Processing Analyzer throws IndexOutOfBoundsException 
> and fails to display request details:
> {noformat}
> Exception in thread "AWT-EventQueue-0" 
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>   at java.lang.String.substring(String.java:1931)
>   at 
> org.apache.sling.reqanalyzer.impl.gui.RequestTableModel.addRow(RequestTableModel.java:37)
>   at 
> org.apache.sling.reqanalyzer.impl.gui.RequestTrackerFile.getData(RequestTrackerFile.java:64)
>   at 
> org.apache.sling.reqanalyzer.impl.gui.RequestListSelectionListener.valueChanged(RequestListSelectionListener.java:65)
>   at 
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:184)
>   at 
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:154)
>   at 
> javax.swing.DefaultListSelectionModel.setValueIsAdjusting(DefaultListSelectionModel.java:685)
>   at 
> javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting(BasicTableUI.java:953)
>   at 
> javax.swing.plaf.basic.BasicTableUI$Handler.mouseReleased(BasicTableUI.java:1166)
>   at 
> javax.swing.plaf.basic.BasicTableUI$MouseInputHandler.mouseReleased(BasicTableUI.java:802)
>   at 
> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:290)
>   at java.awt.Component.processMouseEvent(Component.java:6533)
>   at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
>   at java.awt.Component.processEvent(Component.java:6298)
>   at java.awt.Container.processEvent(Container.java:2236)
>   at java.awt.Component.dispatchEventImpl(Component.java:4889)
>   at java.awt.Container.dispatchEventImpl(Container.java:2294)
>   at java.awt.Component.dispatchEvent(Component.java:4711)
>   at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
>   at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
>   at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
>   at java.awt.Container.dispatchEventImpl(Container.java:2280)
>   at java.awt.Window.dispatchEventImpl(Window.java:2746)
>   at java.awt.Component.dispatchEvent(Component.java:4711)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
>   at java.awt.EventQueue$4.run(EventQueue.java:731)
>   at java.awt.EventQueue$4.run(EventQueue.java:729)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> {noformat}
> This is due to an old (pre-SLING-4114) assumptions on RequestProgressTracker 
> out

[jira] [Commented] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-4753:
--

Thanks [~marett]. Looking at the support for the post-factum hook, then IMHO it 
is probably even better to revert this change and go back to the 
"after-customizer-commit".

I would not make that configurable, though, because that might generate 
complicated ordering problems: We call in some order, now there is this config 
flag, which might have an unexpected consequence on this order.

bq.  I mistakenly wrote close when I meant resolve.

Thanks for clarifying.

> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.1.0
>Reporter: Agraj Mangal
>Assignee: Amit Gupta
> Fix For: Tenant 1.1.0
>
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

[jira] [Comment Edited] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-4753 at 12/22/16 7:37 AM:


Hmm, I am a bit concerned, yet, of course, late in the game.

IIRC we explicitly did *not* commit the changes to the Tenant before calling 
the customers to abort/roll-back the creation in case of problems. This change 
of course prevents that from happening.

I am also a bit concerned with the reasoning behind this change: AEM's 
PageManager.createPage method presumably clearing any changes before acting. I 
am not sure, we really want to support such questionable behaviour.

Also, while I agree that is not clearly spec-ed that changes are not persisted 
*before* calling the customizers, there is some indication in that:

* It is clearly stated in the TenantManager.setup method that changes are 
persisted *before* the method returns
* It is clearly stated with the TenantCustomer that ResourceResolver.commit 
must not be called

Particularly from the second statement we could deduce, that also 
ResourceResolver.revert should not be called, hence calling Session.refresh is 
equally unexpected and undesired.

Plus, even if the original creation is persisted, the behaviour could even 
revert any changes that a previous customizer applied. I really think, we 
should fix the problem not the symptom.

As such, the longer I think about it, the longer I have the impression, that 
this change should be reverted.

Last but not least: Do we really close issues before a release has been cut ?

/cc [~marett], [~amitgupt]


was (Author: fmeschbe):
Hmm, I am a bit concerned, yet, of course, late in the game.

IIRC we explicitly did *not* commit the changes to the Tenant before calling 
the customers to abort/roll-back the creation in case of problems. This change 
of course prevents that from happening.

I am also a bit concerned with the reasoning behind this change: AEM's 
PageManager.createPage method presumably clearing any changes before acting. I 
am not sure, we really want to support such questionable behaviour.

Also, while I agree that is not clearly spec-ed that changes are not persisted 
*before* calling the customizers, there is some indication in that:

* It is clearly stated in the TenantManager.setup method that changes are 
persisted *before* the method returns
* It is clearly stated with the TenantCustomer that ResourceResolver.commit 
must not be called

Particularly from the second statement we could deduce, that also 
ResourceResolver.revert should not be called, hence calling Session.refresh is 
equally unexpected and undesired.

As such, the longer I think about it, the longer I have the impression, that 
this change should be reverted.

Last but not least: Do we really close issues before a release has been cut ?

/cc [~marett], [~amitgupt]

> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.1.0
>Reporter: Agraj Mangal
>Assignee: Amit Gupta
> Fix For: Tenant 1.1.0
>
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

[jira] [Reopened] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[Felix Meschberger (JIRA)]

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

Felix Meschberger reopened SLING-4753:
--

Reopening as I think this is not done yet.

> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.1.0
>Reporter: Agraj Mangal
>Assignee: Amit Gupta
> Fix For: Tenant 1.1.0
>
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

[jira] [Commented] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-4753:
--

Hmm, I am a bit concerned, yet, of course, late in the game.

IIRC we explicitly did *not* commit the changes to the Tenant before calling 
the customers to abort/roll-back the creation in case of problems. This change 
of course prevents that from happening.

I am also a bit concerned with the reasoning behind this change: AEM's 
PageManager.createPage method presumably clearing any changes before acting. I 
am not sure, we really want to support such questionable behaviour.

Also, while I agree that is not clearly spec-ed that changes are not persisted 
*before* calling the customizers, there is some indication in that:

* It is clearly stated in the TenantManager.setup method that changes are 
persisted *before* the method returns
* It is clearly stated with the TenantCustomer that ResourceResolver.commit 
must not be called

Particularly from the second statement we could deduce, that also 
ResourceResolver.revert should not be called, hence calling Session.refresh is 
equally unexpected and undesired.

As such, the longer I think about it, the longer I have the impression, that 
this change should be reverted.

Last but not least: Do we really close issues before a release has been cut ?

/cc [~marett], [~amitgupt]

> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.1.0
>Reporter: Agraj Mangal
>Assignee: Amit Gupta
> Fix For: Tenant 1.1.0
>
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

Re: [api] type conversion in ValueMapDecorator

[Felix Meschberger]

Hi

Granted, consolidation probably makes sense, but there are caveats:

* Bloat: Please consider to not bloat the conversion functionality and 
carefully consider which conversion really makes sense and which is just 
nice-to-have-because-JCR-has-it.
* API: I suggest to break this out of the Sling API bundle into a separate 
bundle. One of the problems I see we have with the API bundle is that is 
becoming more and more a collection of API with independent lifecycle. 
Particularly the Resource API has its own life warranting its own bundle. But 
this type conversion is another one. (And yes I know we also have a packaging 
problem in the API bundle, which might have to be fixed)

Regards
Felix

> Am 19.12.2016 um 12:59 schrieb Julian Sedding :
> 
> +1 It sounds sensible to move the logic to Sling API and re-use it in
> the JCR value map.
> 
> Regards
> Julian
> 
> On Mon, Dec 19, 2016 at 12:40 PM, Stefan Seifert  
> wrote:
>> SLING-6416 revealed a problem in the type conversion logic of the 
>> ValueMapDecorator [1] of the Sling API not supporting BigDecimal conversions.
>> 
>> as the TODO indicates (present there for nearly 8 years) the current 
>> conversion logic is not very smart (and not very efficient), and supports 
>> less conversions than the JCR value map implementation. in jcr.resource a 
>> set of internal converters takes care of the conversion (NumberConverter, 
>> CalendarConverter, BooleanConverter etc. [2]).
>> 
>> the contract of the ValueMap interface does not define which conversions 
>> should be supported exactly, but one might expect that a map enhanced with 
>> ValueMapDecorator should behave at least for the conversion rules the same 
>> way as the JCR value map.
>> 
>> in this case we should move these converter implementation to the sling API 
>> and use them in both ValueMapDecorator and jcr.resource implementation.
>> 
>> WDYT?
>> 
>> stefan
>> 
>> [1] 
>> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/wrappers/ValueMapDecorator.java#L64
>> [2] 
>> https://github.com/apache/sling/tree/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper
>> 
>> 

Re: VanityPath and ResourceResolver#map

[Felix Meschberger]

Hi

> Am 16.12.2016 um 13:22 schrieb Carsten Ziegeler :
> 
> Justin Edelson wrote
>> Hi,
>> IIUC, this is by design. Vanity paths are intended for inbound use only.
>> 
> 
> Right, they might not be as "stable" as a mapping, e.g /latestnews might
> point to page A now, but to page B in three hours.

Really ? This might be debatable. But I would not remember having used this as 
a design criteria.

In any case, I just realize it indeed was never the case: We always only 
created the resolve() mapping but not the map() mapping.


I could have sworn we had support for mapping vanity URLs. Ok, so I stand 
corrected.

Regards
Felix


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

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6352:
--

To be honest, I don't exactly remember why we chose embedding. It may be that 
when we began with these bundles, the Jackrabbit libraries have not been proper 
bundles. There may have been other/more reasons.

If now the Jackrabbit libraries are proper bundles with usable package exports, 
it might be worth a try to not embed any more.

> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

Re: [slingstart] Overriding a variable from the command line at runtime

[Felix Meschberger]

Hi

I think this is a good topic to discuss on a broader level.

I once implemented a function with two services configured through OSGi 
Configuration being able to overwritten by framework properties (aka system 
properties). What I did implement is a helper function which first checked the 
system property and if not set would revert to the OSGi configuration and if 
that was also not set revert to a default value.

I wonder, whether we could not make function available on a broader bases, such 
as through the OSGi Configuration Admin Service ?

Of course this has consequences when we start thinking in terms of „and what if 
I update configuration ?“ I think this goes into the discussion of immutable 
systems.

(Yes I know this is not standard, but lets start thinking about it and we might 
make it a standard…)

Regards
Felix

> Am 14.12.2016 um 14:40 schrieb Bertrand Delacretaz :
> 
> On Wed, Dec 14, 2016 at 12:07 PM, Robert Munteanu  wrote:
>> ...The idea is to allow the user to redefine it at runtime via system
>> properties:
>> 
>> java -jar ... -Dmpx.repository.home=/some/place ...
> 
> FWIW the crankstart launcher supports this, I've just added an example
> at http://svn.apache.org/r1774245 as that was not tested for configs
> so far.
> 
> I think it's required for modern operations, where some things are
> known only at runtime.
> 
> -Bertrand

Re: [slingstart] Overriding a variable from the command line at runtime

[Felix Meschberger]

Am 14.12.2016 um 15:38 schrieb Carsten Ziegeler 
<cziege...@apache.org<mailto:cziege...@apache.org>>:

Felix Meschberger wrote
Hi

I think this is a good topic to discuss on a broader level.

I once implemented a function with two services configured through OSGi 
Configuration being able to overwritten by framework properties (aka system 
properties). What I did implement is a helper function which first checked the 
system property and if not set would revert to the OSGi configuration and if 
that was also not set revert to a default value.

I wonder, whether we could not make function available on a broader bases, such 
as through the OSGi Configuration Admin Service ?

Of course this has consequences when we start thinking in terms of „and what if 
I update configuration ?“ I think this goes into the discussion of immutable 
systems.

I guess this can be done with a ConfigurationPlugin transparently

Ah ! Nice catch. And with the updated ConfigurationAdmin specification we can 
be reasonably sure this to be applied to DS configurations as well. Right ?

… and now for some side track coding of this ;-)

Thanks
Felix



Carsten

(Yes I know this is not standard, but lets start thinking about it and we might 
make it a standard…)

Regards
Felix

Am 14.12.2016 um 14:40 schrieb Bertrand Delacretaz 
<bdelacre...@apache.org<mailto:bdelacre...@apache.org>>:

On Wed, Dec 14, 2016 at 12:07 PM, Robert Munteanu 
<romb...@apache.org<mailto:romb...@apache.org>> wrote:
...The idea is to allow the user to redefine it at runtime via system
properties:

java -jar ... -Dmpx.repository.home=/some/place ...

FWIW the crankstart launcher supports this, I've just added an example
at http://svn.apache.org/r1774245 as that was not tested for configs
so far.

I think it's required for modern operations, where some things are
known only at runtime.

-Bertrand





--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org<mailto:cziege...@apache.org>

Re: Provide a way for a POST request to assert a set of required SlingPostProcessors (SLING-6187)

[Felix Meschberger]

Hi Justin

Thanks for the clarification

Am 14.12.2016 um 15:14 schrieb Justin Edelson 
<jus...@justinedelson.com<mailto:jus...@justinedelson.com>>:

Hi Felix,



On Wed, Dec 14, 2016 at 8:46 AM Felix Meschberger 
<fmesc...@adobe.com<mailto:fmesc...@adobe.com>>
wrote:

Hi all

Can we have the discussion on the list instead of the issue ? This makes
it a tad easier to follow and discuss.

My concern was:

Justin Edelson 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 ?

Justin replied:

Felix Meschberger the use case is laid out in the issue description – a
POST request may depend upon the presence of one or more post processors.

Actually, the issue description essentially justs says: I want to
implement a new parameter to list required plugins. This describes the
solution not the problem.


Sorry, I meant the issue *summary* (not description)... "Provide a way for
a POST request to assert a set of required SlingPostProcessors“

Hmm, my concern still holds: This is not a use case but an implementation 
prescription ;-)


Put in more generic terms, a client should be able to assert some set of
preconditions that the server must be able to meet before handling the
request. I was initially only concerned about expressing this precondition
in terms of the availability of a set of SlingPostProcessors, but I can see
the value in expressing this in a more generic term (capabilities,
features, whatever).

Hmm, I think we are starting to tightly couple client to server (am I repeating 
myself ?). As a client it is *not* my concern that the server is properly setup 
and configured. What you are proposing, though, is that the client can 
explicitly request for proper configuration.

As such I have the impression we are also violating the separation of concern 
principle here.



Alex brings up the use case of encryption:

What if the sling post servlet understands the @suffix (in this case
@Encrypted) and detects if no post processor has handled it?

That sounds like a good use case. And also I like the solution much
better. Because it is inline with what already do for typing values with
@TypeHint, and other features.

Justin contends:

I'm trying to solve this problem in a generic way that can be reused
across multiple PostProcessors

I ask: YAGNI ?


Audit is the other case that comes to mind. It is not uncommon in my
experience to use SlingPostProcessors to store audit history. In this case,
there is no @suffix used -- the SlingPostProcessor simply does some
additional record keeping (potentially in an external system). In these
cases, you may need to block POST requests requiring audit if the
AuditPostProcessor wasn't available.

Hmm, audit ? Why is this a concern to me as a client ? I cannot audit the 
server in the least way. Why should I be able to request this for the Sling 
POST Servlet ? Particularly if there are litteraly 10s and 100s of other POST 
request handlers in the same system not even supporting auditing ?

Granted: I am not against auditing. I am very much in favor of properly doing 
it. But again, this is a server concern and at best a contractual concern 
between the client and the server. But it is not an API concern.


This works currently because we assume that the server is correctly
configured at all times. But that is not always the case and, in both the
encryption and audit cases, there needs to be some way of failing requests
if the preconditions aren't met.

Going into the future of immutable servers, we can all the more be certain to 
have that.

If functions are important to be had and this is a concern to the server, then 
server should have a means of defining that the setup is properly done. Maybe 
we need a validation function to define „the server is properly setup and 
everything administratively expected is in place“. But this IMHO cannot be a 
the task of an HTML programmer configuring an HTML form to setup.

Regards
Felix

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

[Felix Meschberger]

Hi all

Can we have the discussion on the list instead of the issue ? This makes it a 
tad easier to follow and discuss.

My concern was:

> Justin Edelson 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 ?

Justin replied:

> Felix Meschberger the use case is laid out in the issue description – a POST 
> request may depend upon the presence of one or more post processors.

Actually, the issue description essentially justs says: I want to implement a 
new parameter to list required plugins. This describes the solution not the 
problem.

Alex brings up the use case of encryption:

> What if the sling post servlet understands the @suffix (in this case 
> @Encrypted) and detects if no post processor has handled it?

That sounds like a good use case. And also I like the solution much better. 
Because it is inline with what already do for typing values with @TypeHint, and 
other features.

Justin contends:

> I'm trying to solve this problem in a generic way that can be reused across 
> multiple PostProcessors 

I ask: YAGNI ?

So, if the problem really is that we want to ensure encryption is handled, we 
could indeed do that with the @Encrypt notation and thrown an error if the 
@Encrypt is not known.

Regards
Felix

[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] [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] [Resolved] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-6378.
--
Resolution: Fixed

Fixed in Rev. 1773793:

* Converted the SlingDavExServlet to be whiteboard registered
* Converted the AuthHttpContext to be a whiteboard registered 
ServletContextHelper used by the SlingDavExServlet

This now ensures the ResourceResolver created during authentication is properly 
removed from the request attributes and closed.

> 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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6378:
--

Thanks for the feedback. I am going for Option (2) then (refactor to be OSGi 
Whiteboard services).

[~jsedding] I agree. I have created FELIX-5446 discuss this.

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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned SLING-6378:


Assignee: Felix Meschberger

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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated SLING-6378:
-
Fix Version/s: JCR Davex 1.3.6

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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6378:
--

The problem is that the traditional {{HttpService}} implementation ignores any 
whiteboard registered listeners including the Sling Auth Core 
{{ServletRequestListener}}. Therefore for the DavEx servlet, the listener is 
not called.

I see two options: (1) Manually cleanup as proposed in the previous comment or 
(2) investigate migrating the DavEx servlet to be a whiteboard servlet.

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

[jira] [Comment Edited] (SLING-6383) Unexpected behavior with left curly bracket in resource resolution

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6383 at 12/9/16 2:14 PM:
---

Could this be that JCR assumes the leading curly brace to introduce the 
expanded name form as per JCR 2 section 3.2.5.1 Expanded Form:

{panel}
*3.2.5.1 Expanded Form*
The expanded form of a JCR name is defined as:

{code}
ExpandedName ::= '{' Namespace '}' LocalName
Namespace ::= /* see §3.2.1 Namespaces */
LocalName ::= /* see §3.2.2 Local Names */
/* See §1.3.1 String Literals in Syntactic Grammars for details on the 
interpretation of string literals in this grammar */
{code}
{panel}

Though I would think that the string "{sub.tidy.json" is not a complete name in 
expanded form and thus should be treated as invalid.

Just an idea.


was (Author: fmeschbe):
Could this be that JCR assumes the leading curly brace to introduce the 
expanded name form as per JCR 2 section 3.2.5.1 Expanded Form:

{panel}
*3.2.5.1 Expanded Form*
The expanded form of a JCR name is defined as:

{code}
ExpandedName ::= '{' Namespace '}' LocalName
Namespace ::= /* see §3.2.1 Namespaces */
LocalName ::= /* see §3.2.2 Local Names */
/* See §1.3.1 String Literals in Syntactic Grammars for details on the 
interpretation of string literals in this grammar */
{code}
{panel}

Though I would think that the string "{sub.tidy.json" is not a complete name in 
expanded form and thus should be treated as invalid.

Just and idea.

> Unexpected behavior with left curly bracket in resource resolution
> --
>
> Key: SLING-6383
> URL: https://issues.apache.org/jira/browse/SLING-6383
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: test.jsp
>
>
> The attached {{test.jsp}} script produces the below output, in which cases 4 
> to 7 are suprising.
> Given an existing resource R (/libs here) it looks like adding a sub-path to 
> R's path which starts with a left curly bracket causes the resolver to return 
> R instead of a non-existing resource. 
> The returned resource has the full path that was resolved, not R's path, but 
> adapTo(Node.class) returns R's node.
> {code}
> 1 /libs
>   (sling:Folder)
>   JCR:/libs
> 2 /libs/sub
>   (sling:nonexisting)
> 3 /libs/sub/end
>   (sling:nonexisting)
> 4 /libs/{end
>   (sling:Folder)
>   JCR:/libs
> 5 /libs/{sub/end
>   (sling:Folder)
>   JCR:/libs
> 6 /libs/{sub/more/end
>   (sling:Folder)
>   JCR:/libs
> 7 /libs/{sub/end
>   (sling:Folder)
>   JCR:/libs
> 8 /libs/}sub/end
>   (sling:nonexisting)
> 9 /libs/{sub}/end
>   (sling:nonexisting)
> 10 /libs/sub/{end
>   (sling:nonexisting)
> 11 /libs/sub/}end
>   (sling:nonexisting)
> 12 /libs/sub/{end}
>   (sling:nonexisting)
> {code}



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

[jira] [Comment Edited] (SLING-6383) Unexpected behavior with left curly bracket in resource resolution

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-6383 at 12/9/16 2:14 PM:
---

Could this be that JCR assumes the leading curly brace to introduce the 
expanded name form as per JCR 2 section 3.2.5.1 Expanded Form:

{panel}
*3.2.5.1 Expanded Form*
The expanded form of a JCR name is defined as:

{code}
ExpandedName ::= '{' Namespace '}' LocalName
Namespace ::= /* see §3.2.1 Namespaces */
LocalName ::= /* see §3.2.2 Local Names */
/* See §1.3.1 String Literals in Syntactic Grammars for details on the 
interpretation of string literals in this grammar */
{code}
{panel}

Though I would think that the string "{sub.tidy.json" is not a complete name in 
expanded form and thus should be treated as invalid.

Just and idea.


was (Author: fmeschbe):
Could this be that JCR assumes the leading curly brace to introduce the 
expanded name form as per JCR 2 section 3.2.5.1 Expanded Form:

{panel}
3.2.5.1 Expanded Form
The expanded form of a JCR name is defined as:

{code}
ExpandedName ::= '{' Namespace '}' LocalName
Namespace ::= /* see §3.2.1 Namespaces */
LocalName ::= /* see §3.2.2 Local Names */
/* See §1.3.1 String Literals in Syntactic Grammars for details on the 
interpretation of string literals in this grammar */
{code}
{panel}

Though I would think that the string "{sub.tidy.json" is not a complete name in 
expanded form and thus should be treated as invalid.

Just and idea.

> Unexpected behavior with left curly bracket in resource resolution
> --
>
> Key: SLING-6383
> URL: https://issues.apache.org/jira/browse/SLING-6383
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: test.jsp
>
>
> The attached {{test.jsp}} script produces the below output, in which cases 4 
> to 7 are suprising.
> Given an existing resource R (/libs here) it looks like adding a sub-path to 
> R's path which starts with a left curly bracket causes the resolver to return 
> R instead of a non-existing resource. 
> The returned resource has the full path that was resolved, not R's path, but 
> adapTo(Node.class) returns R's node.
> {code}
> 1 /libs
>   (sling:Folder)
>   JCR:/libs
> 2 /libs/sub
>   (sling:nonexisting)
> 3 /libs/sub/end
>   (sling:nonexisting)
> 4 /libs/{end
>   (sling:Folder)
>   JCR:/libs
> 5 /libs/{sub/end
>   (sling:Folder)
>   JCR:/libs
> 6 /libs/{sub/more/end
>   (sling:Folder)
>   JCR:/libs
> 7 /libs/{sub/end
>   (sling:Folder)
>   JCR:/libs
> 8 /libs/}sub/end
>   (sling:nonexisting)
> 9 /libs/{sub}/end
>   (sling:nonexisting)
> 10 /libs/sub/{end
>   (sling:nonexisting)
> 11 /libs/sub/}end
>   (sling:nonexisting)
> 12 /libs/sub/{end}
>   (sling:nonexisting)
> {code}



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

[jira] [Commented] (SLING-6383) Unexpected behavior with left curly bracket in resource resolution

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6383:
--

Could this be that JCR assumes the leading curly brace to introduce the 
expanded name form as per JCR 2 section 3.2.5.1 Expanded Form:

{panel}
3.2.5.1 Expanded Form
The expanded form of a JCR name is defined as:

{code}
ExpandedName ::= '{' Namespace '}' LocalName
Namespace ::= /* see §3.2.1 Namespaces */
LocalName ::= /* see §3.2.2 Local Names */
/* See §1.3.1 String Literals in Syntactic Grammars for details on the 
interpretation of string literals in this grammar */
{code}
{panel}

Though I would think that the string "{sub.tidy.json" is not a complete name in 
expanded form and thus should be treated as invalid.

Just and idea.

> Unexpected behavior with left curly bracket in resource resolution
> --
>
> Key: SLING-6383
> URL: https://issues.apache.org/jira/browse/SLING-6383
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: test.jsp
>
>
> The attached {{test.jsp}} script produces the below output, in which cases 4 
> to 7 are suprising.
> Given an existing resource R (/libs here) it looks like adding a sub-path to 
> R's path which starts with a left curly bracket causes the resolver to return 
> R instead of a non-existing resource. 
> The returned resource has the full path that was resolved, not R's path, but 
> adapTo(Node.class) returns R's node.
> {code}
> 1 /libs
>   (sling:Folder)
>   JCR:/libs
> 2 /libs/sub
>   (sling:nonexisting)
> 3 /libs/sub/end
>   (sling:nonexisting)
> 4 /libs/{end
>   (sling:Folder)
>   JCR:/libs
> 5 /libs/{sub/end
>   (sling:Folder)
>   JCR:/libs
> 6 /libs/{sub/more/end
>   (sling:Folder)
>   JCR:/libs
> 7 /libs/{sub/end
>   (sling:Folder)
>   JCR:/libs
> 8 /libs/}sub/end
>   (sling:nonexisting)
> 9 /libs/{sub}/end
>   (sling:nonexisting)
> 10 /libs/sub/{end
>   (sling:nonexisting)
> 11 /libs/sub/}end
>   (sling:nonexisting)
> 12 /libs/sub/{end}
>   (sling:nonexisting)
> {code}



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6378:
--

I quickly looked into the code. The only hint I would have is, that the 
SlingDavExServlet is not registered with the Http Service whiteboard but 
directly. This may cause the listeners to not be properly attached to the 
context.

This needs a bit deeper digging.

Thanks for reporting !

A workaround might be to manually close the RR in an overwritten service method:

{code}
@Override
public void service(ServletRequest req, ServletResponse res) throws 
ServletException, IOException {
try {
super.service(req, res);
} finally {
// workaround: close the ResourceResolver here
// see also SLING-6378
// code copied from SlingAuthenticator.requestDestroyed
Object resolverAttr = 
req.getAttribute(AuthenticationSupport.REQUEST_ATTRIBUTE_RESOLVER);
if (resolverAttr instanceof ResourceResolver) {
((ResourceResolver) resolverAttr).close();

req.removeAttribute(AuthenticationSupport.REQUEST_ATTRIBUTE_RESOLVER);
}
}
}
{code}


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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6378:
--

SlingAuthenticator is a service which is referenced by the AuthHttpContext. The 
service is registered as a ServletRequestListener to all Http Service contexts 
(as of 1.3.18). As such it (a) sets the ResourceResolver in the request as a 
request attribute and (b) should get the requestDestroyed event to close the 
ResourceResolver in the request attribute.

I only have two explanations: (1) the OSGi framework is not properly setup or 
(2) it does not work as expected, but why ?

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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6378:
--

What version of the Sling Authentication Core bundle do you use ? Looking at 
the SVN history, this should work properly at least with 1.3.18 and newer.

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

[jira] [Commented] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6046:
--

I think we should not apply the patch as is. But as discussed along the thread, 
adding the {{Accept-Range: bytes}} header if the content passes a certain 
size-threshold such as 1MB or so (may more) sounds reasonable to me.

In any case, we should not make sending the header contingent on some content 
type, because that is very brittle: It sounds easy for _video/*_ content types 
but there may be vendor content types out there which would fail setting the 
header.

> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> 
>
> Key: SLING-6046
> URL: https://issues.apache.org/jira/browse/SLING-6046
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Ashok Kumar
> Fix For: Servlets Get 2.1.20
>
> Attachments: Accept-Range Respone Header from S3.png, 
> NetworkDataS3VideoFromIE11.xml, S3video.html, StreamRendererServlet.java.patch
>
>
> Since IE 11 expects "Accept-Ranges" [0] response header to start making 
> requests with Range header, so sling lack in streaming of video content for 
> IE end users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
> Without support of partial content response (206) for IE users, all large 
> video files are being downloaded in single chunk and user need to wait for 
> long to see video content playing. 
> [0] http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11 
>  



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

[jira] [Commented] (SLING-5745) Provide a button to clear all registered entities and reinstall those

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-5745:
--

Nice workaround, but ...

Why is the state corrupt in the first place ? I strongly suggest to fix the 
problem and hold back with symptom touching on a broad basis.

If we cannot make the state stable, the bundle must be modified to deal with 
corrupt state.

> Provide a button to clear all registered entities and reinstall those
> -
>
> Key: SLING-5745
> URL: https://issues.apache.org/jira/browse/SLING-5745
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Console 1.0.2
>Reporter: Konrad Windszus
>
> Currently the web console at {{/system/console/osgi-installer}} exposes the 
> history/state of the OSGi installer. In case the state is not reflecting 
> reality for some reason, there should be a possibility to remove that history 
> and restart the according bundles with a button inside that console.
> The actions which should be triggered under the hood should be
> # remove the data file {{RegisteredResourceList.ser}}
> # restart the bundle {{org.apache.sling.installer.core}}
> That should lead to every provider being asked about all entities which are 
> then processed again so you end up with state again where the most 
> prioritized entites are deployed.



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

Re: New JSON library

[Felix Meschberger]

Hi

I like this approach.

As to replacement options: I'd go for Apache Johnzon. First it's Apache hence 
eating our own dogfood. But more importantly, it is an implementation of the 
standard javax.json API. I much prefer standard APIs over the fragmented JSON 
API scene.

Regards
Felix

Von meinem iPad gesendet

> Am 01.12.2016 um 23:14 schrieb Justin Edelson :
> 
> While I think that it is a good idea in theory to remove our custom JSON
> library, I don't think that is practical in the near term. So I think our
> best course of action is a multistep process:
> 
> 1) Rewrite org.apache.commons.json using
> https://github.com/tdunning/open-json.
> 2) Select a new standard library
> 3) Modify internal-usages of org.apache.commons.json to use library from #2.
> 4) Handle API usage of org.apache.commons.json on a case-by-case basis.
> 
> Agree with Stefan that Semantic Versioning is critical for library
> selection. I'm not sure that Jackson actually does this. As far as I can
> tell, they only use SemVer at the bundle level, not the package level.
> 
> 
> On Thu, Dec 1, 2016 at 4:32 PM Stefan Seifert 
> wrote:
> 
>> following [4] it looks that the best options are currently either GSON or
>> Jackson.
>> i think GSON has smaller footprint and is more compact, but both are good
>> options.
>> 
>> another criteria for choosing is: do they publish their APIs following
>> semantic versioning? otherwise we have the same dilemma as with guava.
>> for jackson this is the case, see
>> https://github.com/FasterXML/jackson/wiki/Jackson-Releases
>> for gson i've not found a documentation, but it seems they follow it as
>> well, have not checked in detail.
>> 
>> stefan
>> 
>> 
>>> -Original Message-
>>> From: Robert Munteanu [mailto:rmunt...@adobe.com]
>>> Sent: Monday, November 28, 2016 10:35 PM
>>> To: dev@sling.apache.org
>>> Subject: New JSON library
>>> 
>>> Hi,
>>> 
>>> The JSON license has been moved to 'Category X' [1] which means that we
>>> can no longer use the org.json library. This has been announced on the
>>> legal@ mailing list, please see [2] for the complete picture.
>>> 
>>> We have until 30 Apr 2017 to remove all dependencies and inclusions of
>>> the org.json library. We may decide to do this earlier, of course.
>>> 
>>> I think it's a good time to drive down the TEF [3] of Sling and move to
>>> using a more mainstream JSON library. I don't have a strong opinion on
>>> the replacement, but I added a couple of ideas at [4].
>>> 
>>> Anyone with an opinion, do chime in :-)
>>> 
>>> Thanks,
>>> 
>>> Robert
>>> 
>>> 
>>> [1]: https://www.apache.org/legal/resolved#category-x
>>> [2]: https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b
>>> 885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E
>>> [3]: Technical Exoticity Factory - I made it up on the spot
>>> [4]: https://cwiki.apache.org/confluence/display/SLING/New+JSON+library
>> 

[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6165:
--

Note, that Sling indeed does not do that. This is the task of the Http Service 
implementation integrating with the actual Servlet Container implementation. So 
in the default Sling Launchpad this would be the Felix Http Service.

> Expose a service for Sling Scripting that provides request-scoped Resource 
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.44, Scripting API 2.1.12
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverProvider}}) should 
> be implemented in order to provide access to request-based 
> {{ResourceResolvers}} for solving script dependencies.
> The following method should be available:
> {noformat}
> /**
>  * Provides a request-scoped {@link ResourceResolver} with only read access 
> to the search paths. This resolver should be used for script 
>  * resolution in the context of the same request rendering process. The 
> {@code ResourceResolver} should not be closed by consumers (calling
>  * {@link ResourceResolver#close} doesn't do anything), since this service 
> will handle the closing operation automatically. The 
>  * {@code ResourceResolver} will be shared between scripting dependencies 
> that render parts of the response for the same request.
>  */
> ResourceResolver getRequestScopedResourceResolver()
> {noformat}
> [sling-dev email 
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]



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

Re: How to handle minor version updates in API for provider bundles?

[Felix Meschberger]

> Am 28.11.2016 um 09:50 schrieb Konrad Windszus <konra...@gmx.de>:
> @Felix: Regarding backwards compatibility: There were not tests which had to 
> be adjusted for the change, but in fact there is a semantical change. Please 
> look at https://issues.apache.org/jira/browse/SLING-6327 for further details.

Ok, technically it looks like it is breaking. But I have the impression, this 
makes sense and is more consistent with RR.getResource.

Thanks
Felix

> Konrad
> 
>> On 28 Nov 2016, at 09:42, Felix Meschberger <fmesc...@adobe.com> wrote:
>> 
>> Hi Konrad
>> 
>> Hmm, are these changed semantics backwards compatible ?
>> 
>> I.e. what do existing callers have to expect ?
>> 
>> Regards
>> Felix
>> 
>>> Am 26.11.2016 um 17:18 schrieb Konrad Windszus <konra...@gmx.de>:
>>> 
>>> Moving the Util methods somewhere else (and even making that Util private) 
>>> is fine with me, but would not change anything about the minor version 
>>> number increase in the o.a.s.resource package.
>>> With the change in SLING-6327 the behaviour of Resource.isResourceType and 
>>> ResourceResolver.isResourceType has been changed (semantically) and 
>>> therefore requires at least a minor version upgrade to allow consumers to 
>>> specify a minimal version of that package (in case they rely on the new 
>>> semantics of those methods).
>>> Konrad
>>> 
>>>> Am 26.11.2016 um 16:17 schrieb Julian Sedding <jsedd...@gmail.com>:
>>>> 
>>>> Thinking about this some more. I don't think the added method is
>>>> generally useful for an API user, because the search-paths are
>>>> normally not available. So I could imagine creating a ResourceTypeUtil
>>>> class in the resourceresolver project to hold these new methods. We
>>>> would thus not touch the Sling API and the utility could start out in
>>>> a private package until we identify other places where we would need
>>>> it.
>>>> 
>>>> WDYT?
>>>> 
>>>> Regards
>>>> Julian
>>>> 
>>>> 
>>>> On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding <jsedd...@gmail.com> wrote:
>>>>> I think the core problem is that we have provider-type classes and
>>>>> consumer-type classes mixed in packages of sling.api. Maybe we should
>>>>> start thinking about how to improve the situation there?
>>>>> 
>>>>> For now, I think what we normally do is update everything to snapshots
>>>>> that needs it and then start releasing.
>>>>> 
>>>>> Alternatively, we could stick with the lower dependency and duplicate
>>>>> the method you added until we want to update everything to the new
>>>>> api.
>>>>> 
>>>>> Regards
>>>>> Julian
>>>>> 
>>>>> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus
>>>>> <konrad.winds...@netcentric.biz> wrote:
>>>>>> With https://issues.apache.org/jira/browse/SLING-6327 I increased the 
>>>>>> minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added 
>>>>>> methods to a ResourceUtil). That means that all provider bundles for 
>>>>>> this package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need 
>>>>>> to be recompiled with an updated dependency to the latest API snapshot, 
>>>>>> to make the latest SNAPSHOTs of all bundles compatible with each other 
>>>>>> (and generate the correct import-package version range in the provider 
>>>>>> bundles).
>>>>>> What is the suggested approach for doing that?
>>>>>> Just increase the dependency to the latest API snapshot again in all 
>>>>>> provider bundles for the according packages (although this will be 
>>>>>> prevent those provider bundles from being easily releasable, because API 
>>>>>> would need to be released first) or are there any other suggestions?
>>>>>> Thanks,
>>>>>> Konrad
>>> 
>> 
> 

Re: How to handle minor version updates in API for provider bundles?

[Felix Meschberger]

Hi Konrad

Hmm, are these changed semantics backwards compatible ?

I.e. what do existing callers have to expect ?

Regards
Felix

> Am 26.11.2016 um 17:18 schrieb Konrad Windszus :
> 
> Moving the Util methods somewhere else (and even making that Util private) is 
> fine with me, but would not change anything about the minor version number 
> increase in the o.a.s.resource package.
> With the change in SLING-6327 the behaviour of Resource.isResourceType and 
> ResourceResolver.isResourceType has been changed (semantically) and therefore 
> requires at least a minor version upgrade to allow consumers to specify a 
> minimal version of that package (in case they rely on the new semantics of 
> those methods).
> Konrad
> 
>> Am 26.11.2016 um 16:17 schrieb Julian Sedding :
>> 
>> Thinking about this some more. I don't think the added method is
>> generally useful for an API user, because the search-paths are
>> normally not available. So I could imagine creating a ResourceTypeUtil
>> class in the resourceresolver project to hold these new methods. We
>> would thus not touch the Sling API and the utility could start out in
>> a private package until we identify other places where we would need
>> it.
>> 
>> WDYT?
>> 
>> Regards
>> Julian
>> 
>> 
>> On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding  wrote:
>>> I think the core problem is that we have provider-type classes and
>>> consumer-type classes mixed in packages of sling.api. Maybe we should
>>> start thinking about how to improve the situation there?
>>> 
>>> For now, I think what we normally do is update everything to snapshots
>>> that needs it and then start releasing.
>>> 
>>> Alternatively, we could stick with the lower dependency and duplicate
>>> the method you added until we want to update everything to the new
>>> api.
>>> 
>>> Regards
>>> Julian
>>> 
>>> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus
>>>  wrote:
 With https://issues.apache.org/jira/browse/SLING-6327 I increased the 
 minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added 
 methods to a ResourceUtil). That means that all provider bundles for this 
 package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need to be 
 recompiled with an updated dependency to the latest API snapshot, to make 
 the latest SNAPSHOTs of all bundles compatible with each other (and 
 generate the correct import-package version range in the provider bundles).
 What is the suggested approach for doing that?
 Just increase the dependency to the latest API snapshot again in all 
 provider bundles for the according packages (although this will be prevent 
 those provider bundles from being easily releasable, because API would 
 need to be released first) or are there any other suggestions?
 Thanks,
 Konrad
> 

[jira] [Commented] (SLING-6328) JSP concurrent compiling issue

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6328:
--

[~rombert] According to the bug referenced this is a concurrency issue which 
should be pretty easy to analyse statically.

> JSP concurrent compiling issue
> --
>
> Key: SLING-6328
> URL: https://issues.apache.org/jira/browse/SLING-6328
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.1.6
>Reporter: Sameer Charles
>Priority: Critical
>
> At times JSP fails to compile due to duplicate variable error (Duplicate 
> local variable _jspx_temp0).
> This is suppose to be fixed in jasper (within Tomcat) but not in Sling impl. 
> See https://bz.apache.org/bugzilla/show_bug.cgi?id=45691
> This seems to be the culprit (see line 623) but there might be other issues.
> https://github.com/apache/sling/blob/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/jasper/compiler/JspUtil.java



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

[jira] [Commented] (SLING-6315) o.a.sling.scripting.core: IllegalStateException: The bundle is uninstalled

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6315:
--

bq. Is it still possible to have a race condition

Unless you implement a synchronous event listener, which I strongly discourage, 
yes, there is a chance for a race condition. Is this a problem ? This should be 
rare.

Even this situation that you are trying to fix/workaround should really be 
extremely rare and only on a "flickering" system, which might even hint at a 
problematic underlying provisioning function !

So maybe, it might even make sense to *not* do anything about this problem in 
the event listener but rather seek to fix the "system flickering" in the 
provisioning function ? As in "fix the root not the symptom"

> o.a.sling.scripting.core: IllegalStateException: The bundle is uninstalled
> --
>
> Key: SLING-6315
> URL: https://issues.apache.org/jira/browse/SLING-6315
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
>
> {noformat}
> 18.11.2016 02:58:23.445 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.scripting.core FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is 
> uninstalled.)java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.scripting.core.impl.ScriptEngineManagerFactory.bundleChanged(ScriptEngineManagerFactory.java:158)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (SLING-6315) o.a.sling.scripting.core: IllegalStateException: The bundle is uninstalled

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6315:
--

Rather than try-catching (on every event even !) I suggest to amend the the 
test for the started event with a test for the bundle state, such as :

{code}
if (event == started and bundle.state == active) { ... }
{code}

> o.a.sling.scripting.core: IllegalStateException: The bundle is uninstalled
> --
>
> Key: SLING-6315
> URL: https://issues.apache.org/jira/browse/SLING-6315
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
>
> {noformat}
> 18.11.2016 02:58:23.445 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.scripting.core FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is 
> uninstalled.)java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.scripting.core.impl.ScriptEngineManagerFactory.bundleChanged(ScriptEngineManagerFactory.java:158)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

Re: Ensuring that components have a configuration when started

[Felix Meschberger]

Hi

I suggest to attack the problem at the right place !

When Configuration Admin is active and configuration is stored in Configuration 
Admin, then configuration *is* provided as soon as such components are 
activated. If not, this is an SCR bug.

Now, I assume you have a provisioning problem in that the bundles are started 
and thus the components activated *before* the configuration is actually stored 
in Configuration Admin.

If this is the case, then please fix the initial provisioing process and *not* 
the components.

Regards
Felix

> Am 21.11.2016 um 11:20 schrieb Robert Munteanu :
> 
> Hi,
> 
> I think we have an ongoing problem with components that:
> 
> - are defined with ConfigurationPolicy.OPTIONAL
> - have a configuration defined in the provisioning model
> 
> What can happen is that the component is activated, is referenced and
> used, and at a later time is configured.
> 
> For an example of this see SLING-6305 [1], where the
> LoginAdminWhitelist config is applied too late.
> 
> Top of my head, some (probably bad) ideas are:
> 
> 1) Make the component require a configuration
> 
> This makes the component less flexible and we should aim for a minimal
> configuration with Sling.
> 
> 2) Post-process the configurations using the slingstart-maven-plugin
> and adjust the configurationPolicy to be ConfigurationPolicy.REQUIRED
> 
> This is a bit suprising and makes it harder for components to be
> switched to a default configuration after being provisioned.
> 
> Suggestions would be greatly appreciated :-)
> 
> Thanks,
> 
> Robert
> 
> 
> [1]: https://issues.apache.org/jira/browse/SLING-6305

[jira] [Commented] (SLING-6258) The PackageAdminClassLoader cannot load classes from bundles providing older API versions

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6258:
--

[~radu.cotescu] From what I can tell, this looks good, yes. Thanks.

> The PackageAdminClassLoader cannot load classes from bundles providing older 
> API versions
> -
>
> Key: SLING-6258
> URL: https://issues.apache.org/jira/browse/SLING-6258
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons ClassLoader 1.3.2
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Commons ClassLoader 1.3.6
>
>
> The {{org.apache.sling.commons.classloader.impl.PackageAdminClassLoader}} 
> cannot correctly load classes that exist only in bundles providing older API 
> implementations if another bundle providing the same API, but newer version, 
> exists on the instance.
> Assuming bundles A and B both export {{org.example}}, A with version 
> {{1.0.0}} and B with version {{2.0.0}}, when the 
> {{org.apache.sling.commons.classloader.impl.PackageAdminClassLoader}} is 
> queried to resolve a class only available in A, it will try to resolve it 
> from B. This happens because the 
> {{org.apache.sling.commons.classloader.impl.PackageAdminClassLoader}} only 
> checks the bundle that provides the highest API (in terms of version number) 
> of the class' providing package.



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

Re: [Documentation] Sling Job documentation uses immediate component

[Felix Meschberger]

Hi Justin

EventAdmin will getService and ungetService the matching EventHandler services 
for each event to be dispatched. If the component is a delayed service, which 
as you state is the default, this means the instance is created and dropped for 
every single event. If there are a lot of them, this will place some load on 
the system.

If there are not many events, it might indeed be better to make it a delayed 
service component.

I think there once has been a discussion on some list (I cannot remember where 
or when, sorry) coming to the conclusion, that EventHandler services better be 
immediate.

Regards
Felix

> Am 10.11.2016 um 15:17 schrieb Justin Edelson :
> 
> Hi,
> It has been pointed out to me that on
> https://sling.apache.org/documentation/tutorials-how-tos/how-to-manage-events-in-sling.html#starting-a-job,
> the sample code shows an EventHandler which has @Component(immediate=true).
> 
> As far as I know, this is an anti-pattern. The use of immediate=true is
> unnecessary for EventHandlers (in general) since DS will automatically
> activate them when/if an event matches the filter.
> 
> Is this understanding correct? Is there a reason our documentation has
> immediate=true here?
> 
> Regards,
> Justin

Re: [jira] [Resolved] (SLING-6258) The PackageAdminClassLoader cannot load classes from bundles providing older API versions

[Felix Meschberger]

Hi Radu

Not currently able to log into JIRA.

This fix wrong and fails on you.

First the OSGi spec says to resolve to the highest matching version of a 
package and not just any. So our PackageAdminClassLoader should do the same.

Even ignoring this, you must make sure to always use the same provider for a 
specific package once you decided for one. Otherwise you get incompatible 
classes, hard to trace issues, and split package issues.

Regards
Felix

--
Typos caused by my iPhone

> Am 08.11.2016 um 19:35 schrieb Radu Cotescu (JIRA) :
> 
> 
> [ 
> https://issues.apache.org/jira/browse/SLING-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Radu Cotescu resolved SLING-6258.
> -
>Resolution: Fixed
> 
> Fixed in [r1768759|https://svn.apache.org/r1768759].
> 
>> The PackageAdminClassLoader cannot load classes from bundles providing older 
>> API versions
>> -
>> 
>>Key: SLING-6258
>>URL: https://issues.apache.org/jira/browse/SLING-6258
>>Project: Sling
>> Issue Type: Bug
>> Components: Commons
>>   Affects Versions: Commons ClassLoader 1.3.2
>>   Reporter: Radu Cotescu
>>   Assignee: Radu Cotescu
>>Fix For: Commons ClassLoader 1.3.4
>> 
>> 
>> The {{org.apache.sling.commons.classloader.impl.PackageAdminClassLoader}} 
>> cannot correctly load classes that exist only in bundles providing older API 
>> implementations if another bundle providing the same API, but newer version, 
>> exists on the instance.
>> Assuming bundles A and B both export {{org.example}}, A with version 
>> {{1.0.0}} and B with version {{2.0.0}}, when the 
>> {{org.apache.sling.commons.classloader.impl.PackageAdminClassLoader}} is 
>> queried to resolve a class only available in A, it will try to resolve it 
>> from B. This happens because the 
>> {{org.apache.sling.commons.classloader.impl.PackageAdminClassLoader}} only 
>> checks the bundle that provides the highest API (in terms of version number) 
>> of the class' providing package.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Resolved] (SLING-6253) Make it easier to have single bundle projects

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-6253.
--
   Resolution: Fixed
Fix Version/s: (was: Slingstart Maven Plugin 1.5.0)

Only now realized that this is exactly the goal of SLING-6213. So this issue is 
moot. Thanks.

> Make it easier to have single bundle projects
> -
>
> Key: SLING-6253
> URL: https://issues.apache.org/jira/browse/SLING-6253
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>    Reporter: Felix Meschberger
>
> With SLING-6213 comes support to have single bundle Sling Start projects. 
> This is great for building micro services and moving towards using the Sling 
> Start mechanism for 12factor apps.
> There is a catch, though, as maintenance currently is hard as you have to 
> manually manage the reference to "self" in the provisioning file.
> For example to release you have to follow these steps:
> # Update reference to the release version
> # cut the release with {{mvn release:prepare release:perform}}
> # Update the reference to the next snapshot version
> How about adding a plugin option indicating the bundle artifact to be part of 
> the sling start  and it being added automatically to the deployed 
> provisioning file ?
> Or even automate this in that the packaging plugin understands the build type 
> to be bundle and assuming the bundle to be part of the provisioning ? (ok 
> this might to much magic)



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

[jira] [Assigned] (SLING-6253) Make it easier to have single bundle projects

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned SLING-6253:


Assignee: Felix Meschberger

> Make it easier to have single bundle projects
> -
>
> Key: SLING-6253
> URL: https://issues.apache.org/jira/browse/SLING-6253
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
>
> With SLING-6213 comes support to have single bundle Sling Start projects. 
> This is great for building micro services and moving towards using the Sling 
> Start mechanism for 12factor apps.
> There is a catch, though, as maintenance currently is hard as you have to 
> manually manage the reference to "self" in the provisioning file.
> For example to release you have to follow these steps:
> # Update reference to the release version
> # cut the release with {{mvn release:prepare release:perform}}
> # Update the reference to the next snapshot version
> How about adding a plugin option indicating the bundle artifact to be part of 
> the sling start  and it being added automatically to the deployed 
> provisioning file ?
> Or even automate this in that the packaging plugin understands the build type 
> to be bundle and assuming the bundle to be part of the provisioning ? (ok 
> this might to much magic)



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

[jira] [Closed] (SLING-6253) Make it easier to have single bundle projects

[Felix Meschberger (JIRA)]

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

Felix Meschberger closed SLING-6253.


> Make it easier to have single bundle projects
> -
>
> Key: SLING-6253
> URL: https://issues.apache.org/jira/browse/SLING-6253
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
>
> With SLING-6213 comes support to have single bundle Sling Start projects. 
> This is great for building micro services and moving towards using the Sling 
> Start mechanism for 12factor apps.
> There is a catch, though, as maintenance currently is hard as you have to 
> manually manage the reference to "self" in the provisioning file.
> For example to release you have to follow these steps:
> # Update reference to the release version
> # cut the release with {{mvn release:prepare release:perform}}
> # Update the reference to the next snapshot version
> How about adding a plugin option indicating the bundle artifact to be part of 
> the sling start  and it being added automatically to the deployed 
> provisioning file ?
> Or even automate this in that the packaging plugin understands the build type 
> to be bundle and assuming the bundle to be part of the provisioning ? (ok 
> this might to much magic)



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

[jira] [Created] (SLING-6253) Make it easier to have single bundle projects

[Felix Meschberger (JIRA)]

Felix Meschberger created SLING-6253:


 Summary: Make it easier to have single bundle projects
 Key: SLING-6253
 URL: https://issues.apache.org/jira/browse/SLING-6253
 Project: Sling
  Issue Type: Improvement
  Components: Maven Plugins and Archetypes
Affects Versions: Slingstart Maven Plugin 1.4.4
Reporter: Felix Meschberger
 Fix For: Slingstart Maven Plugin 1.5.0


With SLING-6213 comes support to have single bundle Sling Start projects. This 
is great for building micro services and moving towards using the Sling Start 
mechanism for 12factor apps.

There is a catch, though, as maintenance currently is hard as you have to 
manually manage the reference to "self" in the provisioning file.

For example to release you have to follow these steps:

# Update reference to the release version
# cut the release with {{mvn release:prepare release:perform}}
# Update the reference to the next snapshot version

How about adding a plugin option indicating the bundle artifact to be part of 
the sling start  and it being added automatically to the deployed provisioning 
file ?

Or even automate this in that the packaging plugin understands the build type 
to be bundle and assuming the bundle to be part of the provisioning ? (ok this 
might to much magic)



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

[jira] [Resolved] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-6226.
--
Resolution: Fixed

Thanks [~cziegeler].

Committed the patch in Rev. 1767618

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>    Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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

[jira] [Assigned] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned SLING-6226:


Assignee: Felix Meschberger

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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

Re: [jira] [Created] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger]

Hi all

I think this works as in „works on my machine“.

Can I have someone please review this patch ?

Thanks
Felix

> Am 01.11.2016 um 16:54 schrieb Felix Meschberger (JIRA) <j...@apache.org>:
> 
> Felix Meschberger created SLING-6226:
> 
> 
> Summary: substVars not properly handling unknown properties
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
> 
> 
> Assuming a property in {{sling.properties}} of the form
> 
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> 
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> 
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> 
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Updated] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated SLING-6226:
-
Attachment: SLING-6226.diff

Proposed patch adding the Util class, removing the old substVars 
implementations and providing some test cases.

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>    Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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

[jira] [Updated] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated SLING-6226:
-
Flags: Patch

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>    Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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

[jira] [Created] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

Felix Meschberger created SLING-6226:


 Summary: substVars not properly handling unknown properties
 Key: SLING-6226
 URL: https://issues.apache.org/jira/browse/SLING-6226
 Project: Sling
  Issue Type: Bug
Affects Versions: Launchpad Base 2.6.14
Reporter: Felix Meschberger
 Fix For: Launchpad Base 2.6.16


Assuming a property in {{sling.properties}} of the form

{code}
org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
[%thread] %logger %msg%n
{code}

This will break during Sling startup as the date format of this {{log.pattern}} 
ends with a curly brace but is not matched with a {{ $\{ }}. This is a but in 
the {{substVars}} method.

Another problem is that this method is duplicate in the {{Sling}} and 
{{SlingServlet}} classes where the latter is in the web app class loader while 
the former already is in the launcher class loader.

Proposing a patch taking the latest Felix Framework's Util class creating a new 
{{Util}} class in the shared package.



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

[jira] [Commented] (SLING-6222) [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The bundle is uninstalled.)

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6222:
--

Looks like a concurrency situation with bundles oscillating between being 
resolved and soon uninstalled ...

* I suggest to only catch the registerMimeType line inside the if statement.
* I suggest to not call the message "uninstalled". Just indicate an error 
registering the mime type.
* Maybe add the bundle identification to the log message



> [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The 
> bundle is uninstalled.)
> ---
>
> Key: SLING-6222
> URL: https://issues.apache.org/jira/browse/SLING-6222
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
>
> During startup, the following ERROR randomly appears in the logs:
> {code}
> 25.10.2016 07:57:53.712 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.commons.mime FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is uninstalled.)
> java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.commons.mime.internal.MimeTypeServiceImpl.bundleChanged(MimeTypeServiceImpl.java:249)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

Re: Logback setup

[Felix Meschberger]

Hi Chetan

Here you go: https://issues.apache.org/jira/browse/SLING-6220

Please review. Works in my environment, but … ;-)

Thanks
Felix

Am 01.11.2016 um 05:59 schrieb Chetan Mehrotra 
<chetan.mehro...@gmail.com<mailto:chetan.mehro...@gmail.com>>:

On Fri, Oct 28, 2016 at 9:35 PM, Felix Meschberger 
<fmesc...@adobe.com<mailto:fmesc...@adobe.com>> wrote:
Wouldn’t it be possible to have the initial (re)configuration done 
synchronously from the LogbackManager constructor such that when Sling Commons 
Log is fully started (activator terminated) the logging is configured at least 
according to the framework properties (which is where the sling.properties are 
injected) ?

Makes sense to make initial config setup synchronous. Can you open an
issue for the same?

Chetan Mehrotra

[jira] [Created] (SLING-6220) [log] Perform initial configuration from framework properties synchronously

[Felix Meschberger (JIRA)]

Felix Meschberger created SLING-6220:


 Summary: [log] Perform initial configuration from framework 
properties synchronously
 Key: SLING-6220
 URL: https://issues.apache.org/jira/browse/SLING-6220
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Felix Meschberger


{{LogbackManager}} uses {{LogConfigManager}} to support traditional logging 
configuration including initial (global) configuration from framework 
properties. Once everything is setup the {{LogbackManager.configChanged()}} 
method is called to initiate logging for the first time.

Unfortunately {{configChanged}} is processed asynchronously leading to initial 
configuration to be applied only later - in some special use cases even *after* 
the complete application has already started.

I proposed to replace the call to {{configChanged()}} by a call to 
{{configure()}} which actually implements the configuration change *before* the 
{{started}} flag is set to {{true}}.

Proposed patch:

{code}
Index: 
src/main/java/org/apache/sling/commons/log/logback/internal/LogbackManager.java
===
--- 
src/main/java/org/apache/sling/commons/log/logback/internal/LogbackManager.java 
(Revision 1767024)
+++ 
src/main/java/org/apache/sling/commons/log/logback/internal/LogbackManager.java 
(Arbeitskopie)
@@ -167,8 +167,13 @@
 registerWebConsoleSupport();
 registerEventHandler();
 
+// initial configuration must be done synchronously (aka immediately)
+addInfo("LogbackManager: BEGIN initial configuration");
+configure();
+addInfo("LogbackManager: END initialconfiguration");
+
+// now open the gate for regular configuration
 started = true;
-configChanged();
 }
 
 public void shutdown() {
{code}



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

Logback setup

[Felix Meschberger]

Hi all

I just noted a problem in the way the logging infrastructure is configured 
currently with Sling Commons Log 5.0.

I have a use case, where I have the global configuration provided as properties 
in sling.properties. This configuration is log file name, log format pattern, 
and log file rotation setup. When starting up the system I see logging going to 
stdout until way after the system has started.

Tracking this down I see that the initial (re)configuration of the logging 
system happens *asynchronously* triggered by the call to the configChanged() 
method in the LogbackManager constructor.

Wouldn’t it be possible to have the initial (re)configuration done 
synchronously from the LogbackManager constructor such that when Sling Commons 
Log is fully started (activator terminated) the logging is configured at least 
according to the framework properties (which is where the sling.properties are 
injected) ?

Thanks
Felix

Re: [JSON] Replacing json.org

[Felix Meschberger]

Hi

Yea, johnzon was also mentioned on the Felix Dev list. Like this.

Regardless of the licensing org.json situation, given that there is javax.json 
as a standard API, we should maybe consider anyways to replace our uses of the 
org.json library with javax.json.

As I said, nothing decided yet, but create awareness.

Regards
Felix


> Am 28.10.2016 um 12:57 schrieb Robert Munteanu <romb...@apache.org>:
> 
> On Fri, 2016-10-28 at 08:08 +, Felix Meschberger wrote:
>> Hi all
>> 
>> Over at legal-discuss there is a discussion of whether the json.org
>> library with the amended MIT license (remember the „use for good not
>> evil“ clause ?) should be „banned“ by reconsidering the „A“ rating of
>> this license (assuming the clause is just a joke) and turning it into
>> an „X“ rating (don’t use based on Debian’s and other’s
>> considerations:
>> 
>> https://wiki.debian.org/qa.debian.org/jsonevil
>> https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software
>> /
>> 
>> It is not decided yet. But we should probably be prepared.
> 
> We reference org.json in too many bundles bundles, a quick grep
> revelead:
> 
> - bundles/commons/log-webconsole
> - bundles/commons/metrics
> - contrib/extensions/slf4j-mdc
> - launchpad/builder ( SmokeIT )
> - tooling/ide
> 
> So the effort would not be too great. I guess each of these can get
> blocker issues for the next release, so we don't forget to remove the
> dependency when releasing.
> 
> More problematic however is the bundles/common/json situation, where we
> include the source of some of the json.org classes, which all include
> the provision "The Software shall be used for Good, not Evil." . I am
> not sure what we need to do about that, if anything.
> 
> 
>> Plenty of alternatives exist: Jackson, GSon, and IMHO quite
>> interesting javax.json (https://json-processing-spec.java.net/) with
>> a RI from glassfish (https://jsonp.java.net/).
> 
> For the sake of being complete, there's also
> 
>  http://johnzon.apache.org/
> 
> which implements JSR-353 ( JSON processing 1.0 ) and also targets JSR-
> 374 ( JSON processing 1.1, which is due to be released in Q3 2016 ).
> "Someone" will have to take a look at the libraries and suggest a
> replacement though, there's no point in deploying multiple libraries
> for the same thing.
> 
> 
>> Assuming we would have to change things, I suggest we reimplement the
>> API of our refactoring of the json.org library with javax.json. We
>> could use the RI form glassfish (which is OSGi-ready and includes the
>> API) or implement our own version.
> 
> +1
> 
> But I rather hope that the legal situation is cleared up and we don't
> need to do anything about it.
> 
> Robert
> 
>> 
>> WDYT ?
>> 
>> Regards
>> Felix
> 

[JSON] Replacing json.org

[Felix Meschberger]

Hi all

Over at legal-discuss there is a discussion of whether the json.org library 
with the amended MIT license (remember the „use for good not evil“ clause ?) 
should be „banned“ by reconsidering the „A“ rating of this license (assuming 
the clause is just a joke) and turning it into an „X“ rating (don’t use based 
on Debian’s and other’s considerations:

https://wiki.debian.org/qa.debian.org/jsonevil
https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software/

It is not decided yet. But we should probably be prepared.

Plenty of alternatives exist: Jackson, GSon, and IMHO quite interesting 
javax.json (https://json-processing-spec.java.net/) with a RI from glassfish 
(https://jsonp.java.net/).

Assuming we would have to change things, I suggest we reimplement the API of 
our refactoring of the json.org library with javax.json. We could use the RI 
form glassfish (which is OSGi-ready and includes the API) or implement our own 
version.

WDYT ?

Regards
Felix

[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-5866:
--

The most important uses IIRC for a HEAD request is getting at the Content-Type 
and Content-Length properties. As long as we can ensure these are still set, it 
seems a good idea to do that, indeed.

For implementation: Maybe you can find a solution to share the response header 
setting between doGet and doHead (IOW only the actual transmission of the 
content is special to doGet).

Thanks [~anagarwa]

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Commented] (SLING-5414) Make the contents of the provisioning model available at runtime

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-5414:
--

>From the peanut gallery: Providing the model is ok. Do we also have API to 
>expose this model programmatically ? Such that not everyone goes about trying 
>to find the model and parse the model ...

> Make the contents of the provisioning model available at runtime
> 
>
> Key: SLING-5414
> URL: https://issues.apache.org/jira/browse/SLING-5414
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Slingstart Maven Plugin 1.4.2
>
> Attachments: SLING-5414.patch
>
>
> For SLING-5355 we need to make additional sections from the provisioning 
> model available at runtime, so that ACLs can be set at startup, and also to 
> be able to reuse their definitions later for auditing/verification purposes.
> A simple way to do that is to copy those sections in the sling_bootstrap.txt 
> file. I have created a patch that does that, will attach it here for review.
> _edit: as discussed below, we'll make the full text of the model available at 
> runtime_



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

[jira] [Commented] (SLING-5035) Sling Models Injectors should be queried in the reverse order of their service ranking value

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-5035:
--

Quoting the OSGi Core Specification R6 :

{panel}
*5.2.6 Service Ranking Order*

When registering a service object, a bundle may optionally specify a 
SERVICE_RANKING service property of type Integer. This number specifies a 
ranking order between services. The highest num- ber has the highest ranking 
and the lowest number (including negative numbers) has the lowest ranking. If 
no service.ranking service property is specified or its type is not Integer 
then a ranking of 0 must be used.

The ranking order is defined as follows:

* Sorted on descending ranking number (highest first)
* If the ranking numbers are equal, sorted on ascending service.id property 
(oldest first).

This ordering is complete because service ids are never reused and handed out 
in order of their reg- istration time. That is, a service that is registered 
later will have a higher service id. Therefore, the ranking order is in 
descending service.ranking numeric order where ties give a preference to the 
ear- lier registrant.

The ranking order is the reverse of the natural ordering of a ServiceReference 
object. The purpose of the ranking order is to allow:

* Selection - When a single service must be chosen but multiple services 
qualify then the service with the highest ranking must be selected.
* Ordering - When multiple services must be used in a specified order.
{panel}

So essentially the ranking is from high value to low value, the service 
reference order as per {{compareTo}} is from low value to high value.

What you want here is the ranking order, that is checking the services with the 
higher ranking before the services with lower values.

I think the implementation is wrong and needs to be fixed. At the same time, I 
suggest to negate the service.ranking values for the default injectors and 
third to update the documentation.

Yes, that might give unexpected results for current implementations which 
expect the wrong behaviour -- if such implementations exist I would actually 
expect them to have stumbled upon this wrong behaviour and have broken 
service.ranking values to work around it.

> Sling Models Injectors should be queried in the reverse order of their 
> service ranking value
> 
>
> Key: SLING-5035
> URL: https://issues.apache.org/jira/browse/SLING-5035
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.2.2
>Reporter: Radu Cotescu
> Fix For: Sling Models Impl 1.2.4
>
>
> The current version of the {{ModelAdaptorFactory}} \[0\] queries the 
> Injectors in the ascending order of their service ranking value. However they 
> should be queried in the descending order of the service ranking, to use the 
> same logic as the {{BundleContext#getServiceReference(String)}} method \[1\].
> \[0\] - 
> https://github.com/apache/sling/blob/f56b444b765beb1c31eed01b4c09fbda4013a580/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L411
> \[1\] - 
> https://osgi.org/javadoc/r4v42/org/osgi/framework/BundleContext.html#getServiceReference(java.lang.String)



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

[jira] [Commented] (SLING-4717) Option to indent output in request progress tracker log

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14549941#comment-14549941
 ] 

Felix Meschberger commented on SLING-4717:
--

Ok, its yet another configuration option.

Still, it *is* a normal log file and should be treated as such. If you want to 
display it differently, have the display change this. For now, I am really very 
reluctant to this change. Thanks.

 Option to indent output in request progress tracker log
 ---

 Key: SLING-4717
 URL: https://issues.apache.org/jira/browse/SLING-4717
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Reporter: Alexander Klimetschek
Priority: Minor
 Attachments: SLING-4717.patch, indented-log.png


 For requests with large nested inclusions of resource trees, visually 
 scanning the request progress tracker log is difficult. It would help if it's 
 indented based on the inclusion level.



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

[jira] [Commented] (SLING-4717) Option to indent output in request progress tracker log

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14547593#comment-14547593
 ] 

Felix Meschberger commented on SLING-4717:
--

Sounds interesting at first sight. But I think a log file should not be 
formatted like this.

Please also have a look at the [Request Processing 
Analyzer|http://sling.apache.org/documentation/bundles/request-analysis.html]. 
I would think enhancing that one to improve on presentation would be well worth 
it.

As for the log file, I am not really inclined. This log file has a good 
structure and can easily be automatically processed. Adding indentation makes 
it (somewhat) harder.

 Option to indent output in request progress tracker log
 ---

 Key: SLING-4717
 URL: https://issues.apache.org/jira/browse/SLING-4717
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Reporter: Alexander Klimetschek
Priority: Minor
 Attachments: SLING-4717.patch, indented-log.png


 For requests with large nested inclusions of resource trees, visually 
 scanning the request progress tracker log is difficult. It would help if it's 
 indented based on the inclusion level.



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

[jira] [Updated] (SLING-4656) ProviderHandler implements compareTo incorreclty

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated SLING-4656:
-
Description: 
The implementation of the ResourceResolver's compareTo method is wrong as it 
favors services registered later over services registered earlier, while older 
services should actually be preferred (assuming there sevice.ranking values are 
equal). In essence it implements natural ServiceReference ordering instead of 
ranking order which is the inverse.

Two options to fix:

* Fix ProviderHandler.compareTo to implement service ranking and thus revers of 
natural ordering
* Fix ResourceProviderEntry.conditionalSort to use a reverse comparator

While at it, the extraction of the service.ranking property is overly complex 
since it first checks for null and then for the correct type. This can be 
simplified by just checking for the correct type as a null value never matches 
any type.

  was:
The implementation of the ResourceResolver's compareTo method is wrong as it 
favors services registered later over services registered earlier, while older 
services should actually be preferred (assuming there sevice.ranking values are 
equal).

While at it, the extraction of the service.ranking property is overly complex 
since it first checks for null and then for the correct type. This can be 
simplified by just checking for the correct type as a null value never matches 
any type.


 ProviderHandler implements compareTo incorreclty
 

 Key: SLING-4656
 URL: https://issues.apache.org/jira/browse/SLING-4656
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.4
Reporter: Felix Meschberger
 Fix For: Resource Resolver 1.2.6


 The implementation of the ResourceResolver's compareTo method is wrong as it 
 favors services registered later over services registered earlier, while 
 older services should actually be preferred (assuming there sevice.ranking 
 values are equal). In essence it implements natural ServiceReference ordering 
 instead of ranking order which is the inverse.
 Two options to fix:
 * Fix ProviderHandler.compareTo to implement service ranking and thus revers 
 of natural ordering
 * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator
 While at it, the extraction of the service.ranking property is overly complex 
 since it first checks for null and then for the correct type. This can be 
 simplified by just checking for the correct type as a null value never 
 matches any type.



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

[jira] [Commented] (SLING-4656) ProviderHandler implements compareTo incorreclty

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510660#comment-14510660
 ] 

Felix Meschberger commented on SLING-4656:
--

Thanks for the tests. 

Will fix compareTo as proposed (sounds to be the better option to me as well)

 ProviderHandler implements compareTo incorreclty
 

 Key: SLING-4656
 URL: https://issues.apache.org/jira/browse/SLING-4656
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.4
Reporter: Felix Meschberger
 Fix For: Resource Resolver 1.2.6


 The implementation of the ResourceResolver's compareTo method is wrong as it 
 favors services registered later over services registered earlier, while 
 older services should actually be preferred (assuming there sevice.ranking 
 values are equal). In essence it implements natural ServiceReference ordering 
 instead of ranking order which is the inverse.
 Two options to fix:
 * Fix ProviderHandler.compareTo to implement service ranking and thus revers 
 of natural ordering
 * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator
 While at it, the extraction of the service.ranking property is overly complex 
 since it first checks for null and then for the correct type. This can be 
 simplified by just checking for the correct type as a null value never 
 matches any type.



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

[jira] [Assigned] (SLING-4656) ProviderHandler implements compareTo incorreclty

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned SLING-4656:


Assignee: Felix Meschberger

 ProviderHandler implements compareTo incorreclty
 

 Key: SLING-4656
 URL: https://issues.apache.org/jira/browse/SLING-4656
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.4
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Resource Resolver 1.2.6


 The implementation of the ResourceResolver's compareTo method is wrong as it 
 favors services registered later over services registered earlier, while 
 older services should actually be preferred (assuming there sevice.ranking 
 values are equal). In essence it implements natural ServiceReference ordering 
 instead of ranking order which is the inverse.
 Two options to fix:
 * Fix ProviderHandler.compareTo to implement service ranking and thus revers 
 of natural ordering
 * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator
 While at it, the extraction of the service.ranking property is overly complex 
 since it first checks for null and then for the correct type. This can be 
 simplified by just checking for the correct type as a null value never 
 matches any type.



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

[jira] [Resolved] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-4655.
--
Resolution: Fixed
  Assignee: Felix Meschberger

Fixed in Rev. 1675803:

* Added method to create servie registration properties for
ServletResourceProvider registration
* Added test case for new method

 Servlet Resolver does not use registered servlet's service.ranking property
 ---

 Key: SLING-4655
 URL: https://issues.apache.org/jira/browse/SLING-4655
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Resolver 2.3.6
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Servlets Resolver 2.3.8


 The Servlet Resolver registers a ResourceProvider for each Servlet service 
 registered and handled by the ServletResolver, that is, those with a Sling 
 servlet registration property.
 As the ResourceResolver supports ranking of ResourceProviders with the same 
 root path, the ServletResolver should really register ResourceProvider 
 services for servlets including the servlet service's service ranking 
 property, if available.



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

[jira] [Resolved] (SLING-4656) ProviderHandler implements compareTo incorreclty

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-4656.
--
Resolution: Fixed

Fixed in Rev. 1675805:

* Document natural order of ProviderHandler to be the same as service.ranking 
order. which is the revers of the natural ServiceReference order previously 
implemented
* Added test case by Carsten Ziegeler (thanks)


 ProviderHandler implements compareTo incorreclty
 

 Key: SLING-4656
 URL: https://issues.apache.org/jira/browse/SLING-4656
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.4
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Resource Resolver 1.2.6


 The implementation of the ResourceResolver's compareTo method is wrong as it 
 favors services registered later over services registered earlier, while 
 older services should actually be preferred (assuming there sevice.ranking 
 values are equal). In essence it implements natural ServiceReference ordering 
 instead of ranking order which is the inverse.
 Two options to fix:
 * Fix ProviderHandler.compareTo to implement service ranking and thus revers 
 of natural ordering
 * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator
 While at it, the extraction of the service.ranking property is overly complex 
 since it first checks for null and then for the correct type. This can be 
 simplified by just checking for the correct type as a null value never 
 matches any type.



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

[jira] [Comment Edited] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510658#comment-14510658
 ] 

Felix Meschberger edited comment on SLING-4655 at 4/24/15 8:58 AM:
---

Fixed in Rev. 1675803:

* Added method to create servie registration properties for 
ServletResourceProvider registration
* Added test case for new method


was (Author: fmeschbe):
Fixed in Rev. 1675803:

* Added method to create servie registration properties for
ServletResourceProvider registration
* Added test case for new method

 Servlet Resolver does not use registered servlet's service.ranking property
 ---

 Key: SLING-4655
 URL: https://issues.apache.org/jira/browse/SLING-4655
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Resolver 2.3.6
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Servlets Resolver 2.3.8


 The Servlet Resolver registers a ResourceProvider for each Servlet service 
 registered and handled by the ServletResolver, that is, those with a Sling 
 servlet registration property.
 As the ResourceResolver supports ranking of ResourceProviders with the same 
 root path, the ServletResolver should really register ResourceProvider 
 services for servlets including the servlet service's service ranking 
 property, if available.



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

[jira] [Created] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property

[Felix Meschberger (JIRA)]

Felix Meschberger created SLING-4655:


 Summary: Servlet Resolver does not use registered servlet's 
service.ranking property
 Key: SLING-4655
 URL: https://issues.apache.org/jira/browse/SLING-4655
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Resolver 2.3.6
Reporter: Felix Meschberger


The Servlet Resolver registers a ResourceProvider for each Servlet service 
registered and handled by the ServletResolver, that is, those with a Sling 
servlet registration property.

As the ResourceResolver supports ranking of ResourceProviders with the same 
root path, the ServletResolver should really register ResourceProvider services 
for servlets including the servlet service's service ranking property, if 
available.



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