[jira] [Commented] (SLING-6963) Service user declaration based on principal names
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[ 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
[ 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
[ 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
[ 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
[ 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
[
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
[
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
[
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
[
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
[ 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
[ 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
[ 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)
[jira] [Comment Edited] (SLING-6548) Provide framework extension fragment for Servlet JSP API
[
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
[
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)
[
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]"
> [httpclient.wire.content] : << " Stackmap Table:[\n]"
> [httpclient.wire.content] : << "
> append_frame(@41,Object[#112],Object[#113])[\n]"
> [httpclient.wire.content] : << "chop_frame(@66,1)[\n]"
> [httpclient.wire.content] : << "chop_frame(@137,1)[\n]"
> [httpclient.wire.content] : << "[\n]"
> [httpclient.wire.content] : << "[\n]"
> [...]
> {noformat}
> {noformat}
> java.lang.VerifyError: Bad type on operand stack
> Exception Details:
> Location:
>
> org/apache/sling/scripting/jsp/jasper/runtime/JspApplicationContextImpl.createELResolver()Ljavax/el/ELResolver;
> @28: invokevirtual
> Reason:
> Type javax/servlet/jsp/el/ImplicitObjectELResolver (current
> frame, stack[1]) is not assignable to
[jira] [Comment Edited] (SLING-6549) Provide framework extension fragment for EL API
[
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
[
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
[
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
[
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
[
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]
[ 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)
[jira] [Commented] (SLING-6458) JSP scripting does not support Java 8 features (lambdas, method references, etc)
[
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:502)
> at
> org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:449)
> at
> org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:281)
> at
> org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:102)
> at
>
[jira] [Commented] (SLING-6458) JSP scripting does not support Java 8 features (lambdas, method references, etc)
[
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(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
[jira] [Commented] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]
[
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
[
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
> output.
> SLING-4114 removed date and time fields which were ending in closing
> parenthesis but the analyzer is still looking for it while calculating string
> index. In most of the cases the request details are just wrongly displayed,
> but when the closing
[jira] [Commented] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations
[ 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
[ 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
[ 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
[ 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)
[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases
[ 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)
[jira] [Commented] (SLING-6394) SlingAuthenticatior#getAnonymousResolver doesn't take in consideration vanityPath
[ 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
[
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
[
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.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
[jira] [Commented] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext
[
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)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
>
[jira] [Assigned] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext
[
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.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
>
[jira] [Updated] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext
[
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.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
>
[jira] [Commented] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext
[
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 org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
>
[jira] [Comment Edited] (SLING-6383) Unexpected behavior with left curly bracket in resource resolution
[
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
[
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
[
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
[
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)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
>
[jira] [Commented] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext
[
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)
> 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
>
[jira] [Commented] (SLING-6378) Unclosed ResourceResolver in davex AuthHttpContext
[
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.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
>
[jira] [Commented] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]
[
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
[
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)
[jira] [Commented] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies
[
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)
[jira] [Commented] (SLING-6328) JSP concurrent compiling issue
[ 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
[
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
[
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)
[jira] [Commented] (SLING-6258) The PackageAdminClassLoader cannot load classes from bundles providing older API versions
[
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)
[jira] [Resolved] (SLING-6253) Make it easier to have single bundle projects
[
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
[
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
[
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 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
[
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
[
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)
[jira] [Updated] (SLING-6226) substVars not properly handling unknown properties
[
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
[
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 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.)
[
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)
[jira] [Created] (SLING-6220) [log] Perform initial configuration from framework properties synchronously
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)
[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD
[ 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
[ 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
[
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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)
[jira] [Created] (SLING-4656) ProviderHandler implements compareTo incorreclty
Felix Meschberger created SLING-4656: Summary: 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 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
[
https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510524#comment-14510524
]
Felix Meschberger commented on SLING-4655:
--
Simple patch:
{noformat}
Index:
src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java
===
---
src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java
(Revision 1675785)
+++
src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java
(Arbeitskopie)
@@ -1000,6 +1000,12 @@
params.put(Constants.SERVICE_DESCRIPTION, ServletResourceProvider for
Servlets at
+ Arrays.asList(provider.getServletPaths()));
+// inherit service ranking
+Object rank = reference.getProperty(Constants.SERVICE_RANKING);
+if (rank instanceof Integer) {
+params.put(Constants.SERVICE_RANKING, rank);
+}
+
final ServiceRegistration reg = context.getBundleContext()
.registerService(ResourceProvider.SERVICE_NAME, provider,
params);
{noformat}
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)
[jira] [Commented] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493824#comment-14493824
]
Felix Meschberger commented on SLING-4544:
--
bq. Well, this is internal API as the class is not exported. So we can change
it anyway we see fit and adapt the callers
Nope, this is exported API:
http://sling.apache.org/apidocs/sling5/org/apache/sling/api/request/RequestProgressTracker.html
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where 1-5% of the rendering time is spent in
MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4616) Investigate support for WebSocket in the Sling Web App
Felix Meschberger created SLING-4616: Summary: Investigate support for WebSocket in the Sling Web App Key: SLING-4616 URL: https://issues.apache.org/jira/browse/SLING-4616 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.5.8 Reporter: Felix Meschberger For Sling Standalone we can deploy the Apache Felix Http Service with support for WebSockets based on the Jetty servlet container. For the Sling Web Application Web Socket support needs to be configured in a descriptor. It should be investigated whether and how this configuration can be added to the Sling Web Application such as to * Enable WebSocket support in Sling if the servlet container supports * Ignore WebSocket support if the servlet container does not support it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494037#comment-14494037
]
Felix Meschberger commented on SLING-4544:
--
Thanks for providing the patch. Yet it keeps hard references to the argument
objects which may keep those objects from being collected. As such I don't
think we should apply this patch. See discussion above. Thanks.
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: SLING-4544.patch, Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where 1-5% of the rendering time is spent in
MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4603) oak-documentMk based discovery.impl
[
https://issues.apache.org/jira/browse/SLING-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491937#comment-14491937
]
Felix Meschberger commented on SLING-4603:
--
See discussion in http://sling.markmail.org/thread/rrodyxlxoiuyx74d
oak-documentMk based discovery.impl
---
Key: SLING-4603
URL: https://issues.apache.org/jira/browse/SLING-4603
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Stefan Egli
Assignee: Stefan Egli
When discovery is used in a stack based on jackrabbit oak as the repository,
the current way of discoving instances somewhat sounds like duplicating work:
oak, or more precisely documentnodestore, itself has a low-level [lease
mechanism|http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html]
where it stores information about the cluster nodes including a {{leaseEnd}}
indicating at what time others can consider a particular node as
dead/crashed. This corresponds pretty much to the discovery.impl heartbeat
mechanism. And in a stack which is built ontop of oak-documentMk, we could be
making use of this fact and delegate the decision about whether a node in a
cluster is alive or not to the oak layer. Also, with OAK-2597 the relevant
information: {{ActiveClusterNodes}} is nicely exposed via JMX - so that can
become the new source of truth defining the cluster view.
When replacing discovery-owned heartbeats with oak-owned ones, there is one
important detail to be watched out for: it can no longer easily be determined
from another instance in the cluster, whether it has this new discovery
bundle activated or not. Hence it is not given that when a voting happens,
that all {{active}} nodes (as reported by oak-documentMk) are actually going
to respond. So the 'silent instance due to deactivated discovery bundle' case
needs special attention/handling.
Other than that, given the normal case of all {{active}} nodes having the
bundle activated, the voting mechanism can stay the same as in
discovery.impl. The topology connectors can be treated the same too (by
storing announcements to their respective
{{/var/discovery/clusterInstances/slingId/announcements/announcerSlingId}}
node. The properties can be handled the same too (by storing to
{{/properties}} node. Only thing that gets replaced is the {{heartbeats}}.
Note that in order for such an oak-based discovery.impl this oak-lease
mechanism must be very robust (it should be so by its own interest already).
However, there are currently a few issues that should probably first be
resolved until discovery can be based on this: OAK-2739, OAK-2682 and
OAK-2681 are currently known in this area.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484913#comment-14484913 ] Felix Meschberger commented on SLING-4585: -- As I pointed at in [my comment|https://issues.apache.org/jira/browse/JCR-3870?focusedCommentId=14484909page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14484909] to JCR-3870: New API is not needed and not helpfull. Rather the implementation of the API should be improved to support the API usage pattern as suggested by the API specification. As such, I think there is nothing to be done in Sling. BTW: I once tested replacing the current if-exists-then-access pattern with a try-access-catch pattern. Overall performance of the resource resovler was actually worse and so the existing pattern prevails. Also, using exceptions for flow control is bad programming styl so I prefer keeping the if-exists-then-access pattern -- of course, best would be if the JCR's getItem method would just return null if an item is not existing or not visible... Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource --- Key: SLING-4585 URL: https://issues.apache.org/jira/browse/SLING-4585 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4543) i18n: support for json dictionaries
[ https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-4543: - Affects Version/s: i18n 2.3.2 Fix Version/s: i18n 2.3.4 i18n: support for json dictionaries --- Key: SLING-4543 URL: https://issues.apache.org/jira/browse/SLING-4543 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.3.2 Reporter: Alexander Klimetschek Assignee: Felix Meschberger Fix For: i18n 2.3.4 Attachments: SLING-4543.patch Support json dictionaries as alternative to individual sling:Message nodes. The fine grained JCR sling:Message node approach does not scale very well when dictionaries contain thousands of entries, at least installation of such a dictionary is slow, but also reading can be affected (even if this is cached), especially viewing in a tree browser becomes impossible. The individual string overlay mechanism (/apps string overlays same /libs string) must still work. In our case (AEM) this can save more than a minute during installation time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4543) i18n: support for json dictionaries
[ https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-4543: Assignee: Felix Meschberger i18n: support for json dictionaries --- Key: SLING-4543 URL: https://issues.apache.org/jira/browse/SLING-4543 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.3.2 Reporter: Alexander Klimetschek Assignee: Felix Meschberger Fix For: i18n 2.3.4 Attachments: SLING-4543.patch Support json dictionaries as alternative to individual sling:Message nodes. The fine grained JCR sling:Message node approach does not scale very well when dictionaries contain thousands of entries, at least installation of such a dictionary is slow, but also reading can be affected (even if this is cached), especially viewing in a tree browser becomes impossible. The individual string overlay mechanism (/apps string overlays same /libs string) must still work. In our case (AEM) this can save more than a minute during installation time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4543) i18n: support for json dictionaries
[ https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-4543. -- Resolution: Fixed I have applied the patch in Rev. 1669598. i18n: support for json dictionaries --- Key: SLING-4543 URL: https://issues.apache.org/jira/browse/SLING-4543 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.3.2 Reporter: Alexander Klimetschek Assignee: Felix Meschberger Fix For: i18n 2.4.0 Attachments: SLING-4543.patch Support json dictionaries as alternative to individual sling:Message nodes. The fine grained JCR sling:Message node approach does not scale very well when dictionaries contain thousands of entries, at least installation of such a dictionary is slow, but also reading can be affected (even if this is cached), especially viewing in a tree browser becomes impossible. The individual string overlay mechanism (/apps string overlays same /libs string) must still work. In our case (AEM) this can save more than a minute during installation time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4543) i18n: support for json dictionaries
[ https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383911#comment-14383911 ] Felix Meschberger commented on SLING-4543: -- Thanks [~alexander.klimetschek] for the patch. I am going to apply this. Since this looks like new feature I also increased the intended next version to be 2.4.0 i18n: support for json dictionaries --- Key: SLING-4543 URL: https://issues.apache.org/jira/browse/SLING-4543 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.3.2 Reporter: Alexander Klimetschek Assignee: Felix Meschberger Fix For: i18n 2.4.0 Attachments: SLING-4543.patch Support json dictionaries as alternative to individual sling:Message nodes. The fine grained JCR sling:Message node approach does not scale very well when dictionaries contain thousands of entries, at least installation of such a dictionary is slow, but also reading can be affected (even if this is cached), especially viewing in a tree browser becomes impossible. The individual string overlay mechanism (/apps string overlays same /libs string) must still work. In our case (AEM) this can save more than a minute during installation time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14384093#comment-14384093
]
Felix Meschberger edited comment on SLING-4544 at 3/27/15 4:29 PM:
---
I think this can be cheap: scan the string for patterns {xxx} and work your
formatting along this scanning. As soon as you find a complex one stop scanning
create a new format from the rest of the format string and call
MessageFormat.format with the original arguments and append the result to the
work so far.
and then: I am not sure, whether this really makes a difference at all...
was (Author: fmeschbe):
I think this can be cheap: scan the string for patterns {xxx} and work your
formatting along this scanning. As soon as you find a complex one stop scanning
create a new format from the rest of the format string and call
MessageFormat.format with the original arguments and append the result to the
work so far.
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14384065#comment-14384065
]
Felix Meschberger commented on SLING-4544:
--
The API defines MessageFormat pattern is supported. So to comply with the
contract we have to do this.
Now, an option would be to have a private simple implementation for the 80-90%
use case of just having {9} style place holders. Once extending formatting is
encountered the simple implementation could fall back to the real MessageFormat.
As to lazy formatting: Easy to do, but please don't. The reason is that you
keep references to the args which may be objects. And by keeping them you
prevent them from being garbage collected. And yes, I have been thinking about
lazy formatting before and dropped the idea exactly for that reason.
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14384093#comment-14384093
]
Felix Meschberger commented on SLING-4544:
--
I think this can be cheap: scan the string for patterns {xxx} and work your
formatting along this scanning. As soon as you find a complex one stop scanning
create a new format from the rest of the format string and call
MessageFormat.format with the original arguments and append the result to the
work so far.
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14384065#comment-14384065
]
Felix Meschberger edited comment on SLING-4544 at 3/27/15 4:16 PM:
---
The API defines MessageFormat pattern is supported. So to comply with the
contract we have to do this.
Now, an option would be to have a private simple implementation for the 80-90%
use case of just having \{9} style place holders. Once extending formatting is
encountered the simple implementation could fall back to the real MessageFormat.
As to lazy formatting: Easy to do, but please don't. The reason is that you
keep references to the args which may be objects. And by keeping them you
prevent them from being garbage collected. And yes, I have been thinking about
lazy formatting before and dropped the idea exactly for that reason.
was (Author: fmeschbe):
The API defines MessageFormat pattern is supported. So to comply with the
contract we have to do this.
Now, an option would be to have a private simple implementation for the 80-90%
use case of just having {9} style place holders. Once extending formatting is
encountered the simple implementation could fall back to the real MessageFormat.
As to lazy formatting: Easy to do, but please don't. The reason is that you
keep references to the args which may be objects. And by keeping them you
prevent them from being garbage collected. And yes, I have been thinking about
lazy formatting before and dropped the idea exactly for that reason.
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4528) Moving to Oak
[
https://issues.apache.org/jira/browse/SLING-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375591#comment-14375591
]
Felix Meschberger commented on SLING-4528:
--
I am sorry, I don't know where the Oak based repository bundle stands at this
point.
Moving to Oak
-
Key: SLING-4528
URL: https://issues.apache.org/jira/browse/SLING-4528
Project: Sling
Issue Type: Task
Components: JCR
Reporter: Oliver Lietz
Labels: oak
Fix For: JCR Oak Server 1.0.0
_Apache Sling Oak Repository Server_ ({{org.apache.sling.jcr.oak.server}}) is
not released and contains some TODOs and {{JcrRepositoryHacks}}.
What needs to be done for a first release, [~bdelacretaz] and [~mduerig]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4461) Remove fallbacks for service users resolution
[ https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14363196#comment-14363196 ] Felix Meschberger commented on SLING-4461: -- I do not exactly understand this. The API contract is a fallback mechanism as explained above: with exact subservice name, without subservice name, default mapping. The ServiceUserMapped service reference contract is exactly as defined by the service reference filter. Also sub service names in configurations cannot be empty (such mappings would be logged and ignored). Remove fallbacks for service users resolution - Key: SLING-4461 URL: https://issues.apache.org/jira/browse/SLING-4461 Project: Sling Issue Type: Improvement Components: Service User Mapper Reporter: Marius Petria ServiceUserMapperImpl has several levels of fallback for service user resolution (fallback to bundle default, or to global default). While this offers a lot of flexibility, it introduces non-determinism in a security feature. If defaults are set, it can happen (especially at startup) that code is executed using different serviceUsers, e.g. a component can execute using the bundle default or global default until its specific subService is available, and it can be easily imagined how this can cause subtle errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4461) Remove fallbacks for service users resolution
[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14363190#comment-14363190
]
Felix Meschberger commented on SLING-4461:
--
Right. And the default value for the default mapping is {{null}}, hence no
default mapping at all. So someone not caring has at least to care a bit and
explicitly configure the default mapping.
Remove fallbacks for service users resolution
-
Key: SLING-4461
URL: https://issues.apache.org/jira/browse/SLING-4461
Project: Sling
Issue Type: Improvement
Components: Service User Mapper
Reporter: Marius Petria
ServiceUserMapperImpl has several levels of fallback for service user
resolution (fallback to bundle default, or to global default). While this
offers a lot of flexibility, it introduces non-determinism in a security
feature. If defaults are set, it can happen (especially at startup) that code
is executed using different serviceUsers, e.g. a component can execute using
the bundle default or global default until its specific subService is
available, and it can be easily imagined how this can cause subtle errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4461) Remove fallbacks for service users resolution
[ https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362992#comment-14362992 ] Felix Meschberger commented on SLING-4461: -- While I agree with the problem and like the illustration, the weakness of the illustration is that it abuses access control for configuration where the configuration is the selection of files to remove. Remove fallbacks for service users resolution - Key: SLING-4461 URL: https://issues.apache.org/jira/browse/SLING-4461 Project: Sling Issue Type: Improvement Components: Service User Mapper Reporter: Marius Petria ServiceUserMapperImpl has several levels of fallback for service user resolution (fallback to bundle default, or to global default). While this offers a lot of flexibility, it introduces non-determinism in a security feature. If defaults are set, it can happen (especially at startup) that code is executed using different serviceUsers, e.g. a component can execute using the bundle default or global default until its specific subService is available, and it can be easily imagined how this can cause subtle errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4461) Remove fallbacks for service users resolution
[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14363013#comment-14363013
]
Felix Meschberger edited comment on SLING-4461 at 3/16/15 10:12 AM:
Service User Mapping has been introduced as a security feature to allow
(background) services to operate in a least privileges required way instead of
granting them all full repository access through
getAdministrativeResourceResolver and loginAdministrative.
The defaults have been introduced as a convenience measure allowing to migrate
code towards service user mapping.
Now the the ServiceUserMapping service introduced with SLING-4312 enforces a
stricter approach. From a security point of view, this is actually better,
since this makes sure a component is only enabled if the expected service user
mapping is actually exactly given as required.
As such the ServiceUserMapping service dependency narrows the functionality
towards the more secure angle.
Should we thus drop the defaults because ServiceUserMapping dependency and
defaults fallback support are not equivalent from an API point of view ? Sounds
like throwing out the baby with the bath water.
Using filters we have a number of options, actually:
* @Reference(mapping.target=(subServiceName=dedicatedUserService))
Require mapping for the given sub service name
* @Reference(mapping.target=(!(subServiceName=*)))
Require a plain service name mapping
*
@Reference(mapping.target=(|(subServiceName=dedicatedUserService)(!(subServiceName=*
Ask for sub service name mapping, allowing fallback to plain service name
mapping
The question is just how we would handle allowing a falling back to the default
user mapping. Maybe we define a new service property {{default}} which is only
set for the default mapping ?
So, with filters we can cover everything from most narrow requirements to
broadest possible openness as supported by the API.
Whether we define an annotation to simplify the initial setup or not is another
question.
Last but not least: The fall back defaults are not really less deterministic
than not having them. For one thing the fall-back mechanism fully determined:
# If a subservice name is required check that mapping first
# Then go for service name only mapping
# Then fall back to default mapping (if configured)
The non-determinism comes from the the fact, that configuration may be updated
at any time. But this is a fundamental tenet of the OSGi framework and as such
is not really a problem. In fact having the ServiceUserMapped service allows to
actually cope with this dynamism in that a component may be taken out of
service if a mapping is removed.
was (Author: fmeschbe):
Service User Mapping has been introduced as a security feature to allow
(background) services to operate in a least privileges required way instead of
granting them all full repository access through
getAdministrativeResourceResolver and loginAdministrative.
The defaults have been introduced as a convenience measure allowing to migrate
code towards service user mapping.
Now the the ServiceUserMapping service introduced with SLING-4312 enforces a
stricter approach. From a security point of view, this is actually better,
since this makes sure a component is only enabled if the expected service user
mapping is actually exactly given as required.
As such the ServiceUserMapping service dependency narrows the functionality
towards the more secure angle.
Should we thus drop the defaults because ServiceUserMapping dependency and
defaults fallback support are not equivalent from an API point of view ? Sounds
like throwing out the baby with the bath water.
Using filters we have a number of options, actually:
* @Reference(mapping.target=(subServiceName=dedicatedUserService))
Require mapping for the given sub service name
* @Reference(mapping.target=(!(subServiceName=*)))
Require a plain service name mapping
*
@Reference(mapping.target=(|(subServiceName=dedicatedUserService)(!(subServiceName=*
Ask for sub service name mapping, allowing fallback to plain service name
mapping
The question is just how we would handle allowing a falling back to the default
user mapping. Maybe we define a new service property {{default}} which is only
set for the default mapping ?
Whether we define an annotation to simplify the initial setup or not is another
question.
Remove fallbacks for service users resolution
-
Key: SLING-4461
URL: https://issues.apache.org/jira/browse/SLING-4461
Project: Sling
Issue Type: Improvement
Components: Service User Mapper
Reporter: Marius Petria
ServiceUserMapperImpl has several levels of fallback for service user
resolution (fallback to bundle default, or to global default).
