[jira] [Commented] (SLING-7429) Improve basename handling
[
https://issues.apache.org/jira/browse/SLING-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643699#comment-16643699
]
Alexander Klimetschek commented on SLING-7429:
--
I would be very careful here risking any backwards incompatibility - even if at
first sight 2. sounds like a feature that has no real purpose. You never know
what folks might be doing and often just accidentally relying on such a
behaviour.
IIUC, you are proposing to turn this around and on empty string select all
dictionaries with no basename set or set to an empty string. What would be the
use case for that? (I read the link but it just talks about the IT tests)
If this is really needed, I would prefer if we come up with a new way that does
not break BC. For example, define a new string name that we can be sure is not
used, for example „__sling_basename_all_unset“ or something like that. If we
don’t want to change the Java API and introduce another method parameter...
> Improve basename handling
> -
>
> Key: SLING-7429
> URL: https://issues.apache.org/jira/browse/SLING-7429
> Project: Sling
> Issue Type: Improvement
> Components: i18n
>Affects Versions: i18n 2.5.12
>Reporter: Konrad Windszus
>Priority: Major
>
> Right now the basename handling according to
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names
> is as follows
> {quote}
> The base name argument can take one three values:
> # {{null}}, selects messages of mix:language nodes ignoring the existence or
> absence of sling:basename properties
> # Empty String, selects messages of mix:language nodes which have
> sling:basename properties, ignoring the actual values
> # Any other Value, selects messages of mix:language nodes whose
> sling:basename properties has any value which matches the base name string
> {quote}
> I think it should somehow be also possible for a client to explicitly select
> a resource bundle which is not having the {{sling:basename}} property set.
> This was originally triggered from
> https://issues.apache.org/jira/browse/SLING-7421?focusedCommentId=16335686=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16335686.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session
[
https://issues.apache.org/jira/browse/SLING-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460184#comment-16460184
]
Alexander Klimetschek commented on SLING-3524:
--
Thanks, LGTM! Unit tests covering all paths would be good, I think.
For reference, I updated the table to make the differences more clear. AFAICS,
the cell in bold is the only new combination as part of this patch.
||Scenario||No clone||Clone||
|Normal login, no sudo|logoutSession: true
no impersonation call
doLogoutSession: true|_same as no clone_|
|Normal login with sudo|logoutSession: true
original session impersonated then closed, USER_IMPERSONATOR set
doLogoutSession: true|_same as no clone_|
|Session login, no sudo|logoutSession: false
session used as-is
doLogoutSession: false|*logoutSession: false*
*session self-impersonated*
*doLogoutSession: true*|
|Session login with sudo|logoutSession: false
session impersonated, USER_IMPERSONATOR set
doLogoutSession: true|_same as no clone_|
> ResourceResolver.clone(null) should not share the same JCR session
> --
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
> Issue Type: Improvement
> Components: JCR, ResourceResolver
>Affects Versions: Resource Resolver 1.0.6
>Reporter: Alexander Klimetschek
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was
> created by passing an existing session using
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of
> the resource resolver to pass into a new, separate thread, and use
> {{ResourceResolver.clone(null)}}, you will actually share the session, but
> this is not obvious. The problem is that a JCR session cannot be shared
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return
> a session that impersonated itself, abstracting this from the resource
> resolver user. Additionally, it might be worth looking that clone always
> returns a new session, unless specifically stated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session
[
https://issues.apache.org/jira/browse/SLING-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458741#comment-16458741
]
Alexander Klimetschek commented on SLING-3524:
--
[~Csaba Varga] I like it! Regarding the jcr resource resolver changes, I think
the "needsCloning/needsSudo/explicitSessionUsed" might need some explanation in
comments, it's not straightforward to follow. Are all possible combinations
covered correctly?
> ResourceResolver.clone(null) should not share the same JCR session
> --
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
> Issue Type: Improvement
> Components: JCR, ResourceResolver
>Affects Versions: Resource Resolver 1.0.6
>Reporter: Alexander Klimetschek
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was
> created by passing an existing session using
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of
> the resource resolver to pass into a new, separate thread, and use
> {{ResourceResolver.clone(null)}}, you will actually share the session, but
> this is not obvious. The problem is that a JCR session cannot be shared
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return
> a session that impersonated itself, abstracting this from the resource
> resolver user. Additionally, it might be worth looking that clone always
> returns a new session, unless specifically stated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7510) UriProvider throws unchecked IllegalArgumentException that must be handled by consumers
[
https://issues.apache.org/jira/browse/SLING-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated SLING-7510:
-
Summary: UriProvider throws unchecked IllegalArgumentException that must be
handled by consumers (was: UriProvider should throw a checked exception
instead of IllegalArgumentException)
> UriProvider throws unchecked IllegalArgumentException that must be handled by
> consumers
> ---
>
> Key: SLING-7510
> URL: https://issues.apache.org/jira/browse/SLING-7510
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: API 2.16.4
>Reporter: Alexander Klimetschek
>Priority: Major
>
> h3. Status quo
> A consumer of the
> [UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
> currently is required to handle an unchecked {{IllegalArgumentException}},
> which is thrown when the provider is not able to handle the binary. Note that
> it is not supposed to ever return null per the javadoc. The
> [JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
> shows a typical consumer code (although it still does do a null check).
> For the use case of asking multiple providers and taking the first one that
> responds it's not an optimal pattern to rely on an unchecked exception for
> the expected failure case that one provider by design cannot handle a certain
> binary or request. Throwing an {{IllegalArgumentException}} if there is no
> problem with the argument passed from the client, but a limit or
> configuration setting of the provider, is misleading. Also, given there are
> multiple providers active, a client cannot know upfront which provider is the
> right one for a given binary and somehow prevent the "illegal argument" call
> in the first place.
> h3. Suggestion
> Often, {{null}} return values are used in such a case. The provider can log
> any possible useful information itself, on why it could not handle it, if
> needed. This would simplify the consumer code (no try/catch necessary) and
> remove unnecessary cost of exception handling for normal code paths.
> JcrNodeResource itself it uses a null return value to pass on the "could not
> retrieve anything" state to the upper layers.
> If the goal really is to use exceptions here, the API should add a
> {{@Nonnull}} annotation for the return value _and_ the expected failure
> exception should be a checked one such as a new {{UriProviderException}}.
> Then for any unexpected faults (e.g. network error), it's fine to allow
> providers to throw a unchecked runtime exception, and usually that's not
> something that is explicitly mentioned in javadoc, but would definitely not
> hurt.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7510) UriProvider should throw a checked exception instead of IllegalArgumentException
[
https://issues.apache.org/jira/browse/SLING-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated SLING-7510:
-
Description:
h3. Status quo
A consumer of the
[UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
currently is required to handle an unchecked {{IllegalArgumentException}},
which is thrown when the provider is not able to handle the binary. Note that
it is not supposed to ever return null per the javadoc. The
[JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
shows a typical consumer code (although it still does do a null check).
For the use case of asking multiple providers and taking the first one that
responds it's not an optimal pattern to rely on an unchecked exception for the
expected failure case that one provider by design cannot handle a certain
binary or request. Throwing an {{IllegalArgumentException}} if there is no
problem with the argument passed from the client, but a limit or configuration
setting of the provider, is misleading. Also, given there are multiple
providers active, a client cannot know upfront which provider is the right one
for a given binary and somehow prevent the "illegal argument" call in the first
place.
h3. Suggestion
Often, {{null}} return values are used in such a case. The provider can log any
possible useful information itself, on why it could not handle it, if needed.
This would simplify the consumer code (no try/catch necessary) and remove
unnecessary cost of exception handling for normal code paths. JcrNodeResource
itself it uses a null return value to pass on the "could not retrieve anything"
state to the upper layers.
If the goal really is to use exceptions here, the API should add a {{@Nonnull}}
annotation for the return value _and_ the expected failure exception should be
a checked one such as a new {{UriProviderException}}. Then for any unexpected
faults (e.g. network error), it's fine to allow providers to throw a unchecked
runtime exception, and usually that's not something that is explicitly
mentioned in javadoc, but would definitely not hurt.
was:
h3. Status quo
A consumer of the
[UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
currently is required to handle an unchecked {{IllegalArgumentException}},
which is thrown when the provider is not able to handle the binary. Note that
it is not supposed to ever return null per the javadoc. The
[JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
shows a typical consumer code (although it does do a null check).
For the use case of asking multiple providers and taking the first one that
responds it's not an optimal pattern to rely on an unchecked exception for the
expected failure case that one provider by design cannot handle a certain
binary or request. Throwing an {{IllegalArgumentException}} if there is no
problem with the argument passed from the client, but a limit or configuration
setting of the provider, is misleading. Also, given there are multiple
providers active, a client cannot know upfront which provider is the right one
for a given binary and somehow prevent the "illegal argument" call in the first
place.
h3. Suggestion
Often, {{null}} return values are used in such a case. The provider can log any
possible useful information itself, on why it could not handle it, if needed.
This would simplify the consumer code (no try/catch necessary) and remove
unnecessary cost of exception handling for normal code paths. JcrNodeResource
itself it uses a null return value to pass on the "could not retrieve anything"
state to the upper layers.
If the goal really is to use exceptions here, the API should add a {{@Nonnull}}
annotation for the return value _and_ the expected failure exception should be
a checked one such as a new {{UriProviderException}}. Then for any unexpected
faults (e.g. network error), it's fine to allow providers to throw a unchecked
runtime exception, and usually that's not something that is explicitly
mentioned in javadoc, but would definitely not hurt.
> UriProvider should throw a checked exception instead of
> IllegalArgumentException
>
>
> Key: SLING-7510
> URL:
[jira] [Created] (SLING-7510) UriProvider should throw a checked exception instead of IllegalArgumentException
Alexander Klimetschek created SLING-7510:
Summary: UriProvider should throw a checked exception instead of
IllegalArgumentException
Key: SLING-7510
URL: https://issues.apache.org/jira/browse/SLING-7510
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.16.4
Reporter: Alexander Klimetschek
h3. Status quo
A consumer of the
[UriProvider|https://github.com/apache/sling-org-apache-sling-api/blob/dfc41640031bc87ec271c648b22073e65f4f171a/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L45]
currently is required to handle an unchecked {{IllegalArgumentException}},
which is thrown when the provider is not able to handle the binary. Note that
it is not supposed to ever return null per the javadoc. The
[JcrNodeResource|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/0e2ebd0f1a5c7cb2044b2d754945eb0ee7641081/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L233-L242]
shows a typical consumer code (although it does do a null check).
For the use case of asking multiple providers and taking the first one that
responds it's not an optimal pattern to rely on an unchecked exception for the
expected failure case that one provider by design cannot handle a certain
binary or request. Throwing an {{IllegalArgumentException}} if there is no
problem with the argument passed from the client, but a limit or configuration
setting of the provider, is misleading. Also, given there are multiple
providers active, a client cannot know upfront which provider is the right one
for a given binary and somehow prevent the "illegal argument" call in the first
place.
h3. Suggestion
Often, {{null}} return values are used in such a case. The provider can log any
possible useful information itself, on why it could not handle it, if needed.
This would simplify the consumer code (no try/catch necessary) and remove
unnecessary cost of exception handling for normal code paths. JcrNodeResource
itself it uses a null return value to pass on the "could not retrieve anything"
state to the upper layers.
If the goal really is to use exceptions here, the API should add a {{@Nonnull}}
annotation for the return value _and_ the expected failure exception should be
a checked one such as a new {{UriProviderException}}. Then for any unexpected
faults (e.g. network error), it's fine to allow providers to throw a unchecked
runtime exception, and usually that's not something that is explicitly
mentioned in javadoc, but would definitely not hurt.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7300) CPU spike in i18n job
[
https://issues.apache.org/jira/browse/SLING-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286651#comment-16286651
]
Alexander Klimetschek commented on SLING-7300:
--
All 3 dumps are inside the logging. Maybe there is a problem there. Do you see
a lot of log output by the i18n? If yes, maybe it's set to a higher log level,
outputting too much for an overloaded logging system (just guessing here) and a
workaround is to limit logging for {{org.apache.sling.i18n}} to ERROR or the
like. HTH
> CPU spike in i18n job
> -
>
> Key: SLING-7300
> URL: https://issues.apache.org/jira/browse/SLING-7300
> Project: Sling
> Issue Type: Bug
> Components: i18n, Karaf
>Affects Versions: i18n 2.5.10
> Environment: Linux, jdk1.8 latest version, Karaf 4.1.3
>Reporter: Ivo Leitão
>Priority: Critical
> Attachments: 1.tdump, 2.tdump, 3.tdump, cpuspike.png
>
>
> Hi,
> I'm experiencing severe CPU spikes caused by the reload job in the i18n
> bundle. I've uploaded 3 threadumps which I analysed in http://fastthread.io.
> The analysis identified a cpu spike in the method scheduleReloadBundles of
> the class
> https://github.com/apache/sling-org-apache-sling-i18n/blob/master/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java.
> This does not happen every time only on some situations. I've experienced
> this problem at least on the previous i18n bundle versions. Since there was
> changes on the mentioned class I've updated it hopping to get rid of this
> problem. Unfortunately I'm experiencing it again :-(
> Thread dump bellow:
> sling-default-1-JcrResourceBundleProvider: reload all resource bundles -
> priority:5 - threadId:0x7f2ec851e800 - nativeId:0x1f72 - state:RUNNABLE
> stackTrace:
> java.lang.Thread.State: RUNNABLE
> at
> java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss(ThreadLocal.java:444)
> at java.lang.ThreadLocal$ThreadLocalMap.getEntry(ThreadLocal.java:419)
> at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:298)
> at java.lang.ThreadLocal.get(ThreadLocal.java:163)
> at
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.getByteBuffer(StringBuilderEncoder.java:115)
> at
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.encode(StringBuilderEncoder.java:54)
> at
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.encode(StringBuilderEncoder.java:32)
> at
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:219)
> at
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:57)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:177)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:170)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:161)
> at
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:218)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:403)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
> at
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.doLog0(PaxLoggerImpl.java:151)
> at
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.doLog(PaxLoggerImpl.java:144)
> at
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.inform(PaxLoggerImpl.java:176)
> at
> org.ops4j.pax.logging.internal.TrackingLogger.inform(TrackingLogger.java:86)
> at org.ops4j.pax.logging.slf4j.Slf4jLogger.info(Slf4jLogger.java:476)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider$1.run(JcrResourceBundleProvider.java:319)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:347)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
>
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225218#comment-16225218 ] Alexander Klimetschek commented on SLING-3049: -- +1 Looks very useful when people report issues and don‘t know what bundles are even involved. Will this be automatically part of any stacktraces in log files? > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6935) Context-Aware web console default experience difficult
[ https://issues.apache.org/jira/browse/SLING-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16177100#comment-16177100 ] Alexander Klimetschek commented on SLING-6935: -- Thanks! > Context-Aware web console default experience difficult > -- > > Key: SLING-6935 > URL: https://issues.apache.org/jira/browse/SLING-6935 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Context-Aware Configuration Impl 1.4.2 >Reporter: Alexander Klimetschek >Assignee: Stefan Seifert > Fix For: Context-Aware Configuration Impl 1.4.4 > > > A resolve with the default values doesn't give anything. Default values > should be: > * Content Path "/content" > * other config name "." > Which should on a typical system give you something, such as > "/conf/global/settings" for example. This makes exploring the UI much simpler. > If no config name is set, one gets a 500 error "Invalid configuration name: > null". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7014) Inheritance of configurations from parent content resource
[
https://issues.apache.org/jira/browse/SLING-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090251#comment-16090251
]
Alexander Klimetschek commented on SLING-7014:
--
[~cziegeler] [~sseif...@pro-vision.de] Could you look into this? If this is the
case, it's a critical bug in the resolution logic of the default SPI
implementation.
Note that {{cq:conf}} is our custom name for the {{sling:configRef}} property.
As stated in the
[documentation|http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-default-implementation.html]:
{quote}Go up in the content resource tree until a resource with sling:configRef
is found. This is the 'inner-most' context. Check if a configuration resource
exists at the path the property points to.{quote}
> Inheritance of configurations from parent content resource
> --
>
> Key: SLING-7014
> URL: https://issues.apache.org/jira/browse/SLING-7014
> Project: Sling
> Issue Type: Bug
>Reporter: Nitin Gupta
>Priority: Critical
>
> configure /content/dam/folder/@cq:conf = /conf/something
> Then use the sling context aware API to get the configuration for
> /content/dam/folder/asset.png and I essentially get /conf/global (an
> osgi-configured fallback) instead of /conf/something
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041485#comment-16041485
]
Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
-
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
Although I think it's still a problem of mixing URLs (where these parameters
come in) and the resource namespace, which came in by sharing the same
implementation (getResourceInternal) between resolve() and getResource(), while
it should probably be separated, so the parameter parsing happens for resolve()
only and other means given to retrieve things with parameter if you are a
client using getResource() semantics.
was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered). Although I think it's still a problem of mixing URLs (where these
parameters come in) and the resource namespace, which came in by sharing the
same implementation (getResourceInternal) between resolve() and getResource(),
while it should probably be separated, so the parameter parsing happens for
resolve() only and other means given to retrieve things with parameter if you
are a client using getResource() semantics.
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041485#comment-16041485
]
Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
-
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered). Although I think it's still a problem of mixing URLs (where these
parameters come in) and the resource namespace, which came in by sharing the
same implementation (getResourceInternal) between resolve() and getResource(),
while it should probably be separated, so the parameter parsing happens for
resolve() only and other means given to retrieve things with parameter if you
are a client using getResource() semantics.
was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041485#comment-16041485
]
Alexander Klimetschek commented on SLING-848:
-
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039472#comment-16039472
]
Alexander Klimetschek edited comment on SLING-848 at 6/6/17 8:53 PM:
-
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only {{resolve()}} needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using {{getResource()}} OTOH is programmatic and "knows"
what it's doing and could pass the parameters explicitly in a map, as proposed
early above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to {{resolve()}} or the new {{getResource(String,
Map)}}. This raises the point of backwards compatibility, but I think it makes
sense to address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through {{resolve()}}, and that should
work as well. Not sure if it would do...
2.
Maybe simply try to retrieve the resource with the full path if the cut off
path (if parameters were found) doesn't return a resource.
Not sure if that creates issues with different permissions and the cut off path
is not found due to missing read permission. A getOrCreate style method might
run into this, but likely would not be able to create the full path variant
then.
was (Author: alexander.klimetschek):
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only {{resolve()}} needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using {{getResource()}} OTOH is programmatic and "knows"
what it's doing and could pass the parameters explicitly in a map, as proposed
early above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to {{resolve()}} or the new {{getResource(String,
Map)}}. This raises the point of backwards compatibility, but I think it makes
sense to address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through {{resolve()}}, and that should
work as well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve.
Not sure if that creates issues with different permissions and the cut off path
is not found due to missing read permission. A getOrCreate style method might
run into this, but likely would not be able to create the full path variant
then.
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type:
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039472#comment-16039472
]
Alexander Klimetschek edited comment on SLING-848 at 6/6/17 8:52 PM:
-
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only {{resolve()}} needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using {{getResource()}} OTOH is programmatic and "knows"
what it's doing and could pass the parameters explicitly in a map, as proposed
early above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to {{resolve()}} or the new {{getResource(String,
Map)}}. This raises the point of backwards compatibility, but I think it makes
sense to address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through {{resolve()}}, and that should
work as well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve. (Not sure if that creates issues with different
permissions and the cut off path is not found due to missing read permission. A
getOrCreate style method might run into this, but likely would not be able to
create the full path variant then).
was (Author: alexander.klimetschek):
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only resolve() needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using getResource() OTOH is programmatic and "knows" what
it's doing and could pass the parameters explicitly in a map, as proposed early
above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to resolve() or the new {{getResource(String, Map)}}.
This raises the point of backwards compatibility, but I think it makes sense to
address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through resolve(), and that should work as
well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve. (Not sure if that creates issues with different
permissions and the cut off path is not found due to missing read permission. A
getOrCreate style method might run into this, but likely would not be able to
create the full path variant then).
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR,
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039472#comment-16039472
]
Alexander Klimetschek edited comment on SLING-848 at 6/6/17 8:52 PM:
-
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only {{resolve()}} needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using {{getResource()}} OTOH is programmatic and "knows"
what it's doing and could pass the parameters explicitly in a map, as proposed
early above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to {{resolve()}} or the new {{getResource(String,
Map)}}. This raises the point of backwards compatibility, but I think it makes
sense to address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through {{resolve()}}, and that should
work as well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve.
Not sure if that creates issues with different permissions and the cut off path
is not found due to missing read permission. A getOrCreate style method might
run into this, but likely would not be able to create the full path variant
then.
was (Author: alexander.klimetschek):
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only {{resolve()}} needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using {{getResource()}} OTOH is programmatic and "knows"
what it's doing and could pass the parameters explicitly in a map, as proposed
early above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to {{resolve()}} or the new {{getResource(String,
Map)}}. This raises the point of backwards compatibility, but I think it makes
sense to address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through {{resolve()}}, and that should
work as well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve. (Not sure if that creates issues with different
permissions and the cut off path is not found due to missing read permission. A
getOrCreate style method might run into this, but likely would not be able to
create the full path variant then).
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
>
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039472#comment-16039472
]
Alexander Klimetschek commented on SLING-848:
-
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only resolve() needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using getResource() OTOH is programmatic and "knows" what
it's doing and could pass the parameters explicitly in a map, as proposed early
above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to resolve() or the new {{getResource(String, Map)}}.
This raises the point of backwards compatibility, but I think it makes sense to
address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through resolve(), and that should work as
well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve. (Not sure if that creates issues with different
permissions and the cut off path is not found due to missing read permission. A
getOrCreate style method might run into this, but likely would not be able to
create the full path variant then).
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037662#comment-16037662
]
Alexander Klimetschek edited comment on SLING-848 at 6/5/17 9:56 PM:
-
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names. We (Adobe AEM) have a lot of code that
works like this and now fails if a ";" is included in the path:
{code:java}
Node node = parent.addNode("something;else");
Resource resource = resourceResolver.getResource(node.getPath());
{code}
I wonder if all Resource creation APIs and utilities within Sling are also
adapted consistently at this point?
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
was (Author: alexander.klimetschek):
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037662#comment-16037662
]
Alexander Klimetschek edited comment on SLING-848 at 6/5/17 9:51 PM:
-
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
was (Author: alexander.klimetschek):
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037662#comment-16037662
]
Alexander Klimetschek commented on SLING-848:
-
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
> Support getting versioned resources by using uri path parameters
>
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6935) Context-Aware web console default experience difficult
[
https://issues.apache.org/jira/browse/SLING-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035391#comment-16035391
]
Alexander Klimetschek commented on SLING-6935:
--
BTW, instead of a service user it could use the webconsole's resource resolver
(i.e. the current logged in user) available via
{code}ResourceResolver resolver = (ResourceResolver)
request.getAttribute("org.apache.sling.auth.core.ResourceResolver");{code}
and offer impersonation if one wants to try the resolution for different users.
> Context-Aware web console default experience difficult
> --
>
> Key: SLING-6935
> URL: https://issues.apache.org/jira/browse/SLING-6935
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.4.2
>Reporter: Alexander Klimetschek
>
> A resolve with the default values doesn't give anything. Default values
> should be:
> * Content Path "/content"
> * other config name "."
> Which should on a typical system give you something, such as
> "/conf/global/settings" for example. This makes exploring the UI much simpler.
> If no config name is set, one gets a 500 error "Invalid configuration name:
> null".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6935) Context-Aware web console default experience difficult
Alexander Klimetschek created SLING-6935: Summary: Context-Aware web console default experience difficult Key: SLING-6935 URL: https://issues.apache.org/jira/browse/SLING-6935 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Context-Aware Configuration Impl 1.4.2 Reporter: Alexander Klimetschek A resolve with the default values doesn't give anything. Default values should be: * Content Path "/content" * other config name "." Which should on a typical system give you something, such as "/conf/global/settings" for example. This makes exploring the UI much simpler. If no config name is set, one gets a 500 error "Invalid configuration name: null". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-6932) [javadoc] Document transient nature of ResourceResolver operations
[ https://issues.apache.org/jira/browse/SLING-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-6932: - Description: All ResourceResolver resource operations (create, delete, move, copy) are transient, one always has to call commit() to save the transaction. This isn't documented in the current [ResourceResolver javadoc|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java]. A general paragraph in the class level javadoc on the overall transactional behavior, plus a sentence on each modifying operation such as "It is necessary to call commit() to persist these changes." would help. Furthermore, with changes across multiple resource providers (such as a move), these are multiple transactions, but there is no two phase commit or the like - the first failure will stop committing transactions, and already committed transactions are not rolled back. (Based on reading [this code|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/helper/ResourceResolverControl.java#L419-L423]). Should be documented as well. Discussed here: http://sling.markmail.org/thread/vrnjgqgf3djvwscv was: All ResourceResolver resource operations (create, delete, move, copy) are transient, one always has to call commit() to save the transaction. This isn't documented in the current [ResourceResolver javadoc|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java]. A general paragraph in the class level javadoc on the overall transactional behavior, plus a sentence on each modifying operation such as "It is necessary to call commit() to persist these changes." would help. Furthermore, with changes across multiple resource providers (such as a move), these are multiple transactions, but there is no two phase commit or the like - the first failure will stop committing transactions, and already committed transactions are not rolled back. (Based on reading [this code|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/helper/ResourceResolverControl.java#L419-L423]). Should be clarified as well. Discussed here: http://sling.markmail.org/thread/vrnjgqgf3djvwscv > [javadoc] Document transient nature of ResourceResolver operations > -- > > Key: SLING-6932 > URL: https://issues.apache.org/jira/browse/SLING-6932 > Project: Sling > Issue Type: Improvement > Components: API >Reporter: Alexander Klimetschek > > All ResourceResolver resource operations (create, delete, move, copy) are > transient, one always has to call commit() to save the transaction. > This isn't documented in the current [ResourceResolver > javadoc|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java]. > A general paragraph in the class level javadoc on the overall transactional > behavior, plus a sentence on each modifying operation such as "It is > necessary to call commit() to persist these changes." would help. > Furthermore, with changes across multiple resource providers (such as a > move), these are multiple transactions, but there is no two phase commit or > the like - the first failure will stop committing transactions, and already > committed transactions are not rolled back. (Based on reading [this > code|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/helper/ResourceResolverControl.java#L419-L423]). > Should be documented as well. > Discussed here: http://sling.markmail.org/thread/vrnjgqgf3djvwscv -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6932) [javadoc] Document transient nature of ResourceResolver operations
Alexander Klimetschek created SLING-6932: Summary: [javadoc] Document transient nature of ResourceResolver operations Key: SLING-6932 URL: https://issues.apache.org/jira/browse/SLING-6932 Project: Sling Issue Type: Improvement Components: API Reporter: Alexander Klimetschek All ResourceResolver resource operations (create, delete, move, copy) are transient, one always has to call commit() to save the transaction. This isn't documented in the current [ResourceResolver javadoc|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java]. A general paragraph in the class level javadoc on the overall transactional behavior, plus a sentence on each modifying operation such as "It is necessary to call commit() to persist these changes." would help. Furthermore, with changes across multiple resource providers (such as a move), these are multiple transactions, but there is no two phase commit or the like - the first failure will stop committing transactions, and already committed transactions are not rolled back. (Based on reading [this code|https://github.com/apache/sling/blob/96c4134f770c83a665170ec9fad1f8d49832e650/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/helper/ResourceResolverControl.java#L419-L423]). Should be clarified as well. Discussed here: http://sling.markmail.org/thread/vrnjgqgf3djvwscv -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6890) Remove usage of o.a.jackrabbit.commons.json from i18n
[
https://issues.apache.org/jira/browse/SLING-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030046#comment-16030046
]
Alexander Klimetschek commented on SLING-6890:
--
Where did you saw it? The code itself has no direct import of {{org.json}}.
> Remove usage of o.a.jackrabbit.commons.json from i18n
> -
>
> Key: SLING-6890
> URL: https://issues.apache.org/jira/browse/SLING-6890
> Project: Sling
> Issue Type: Sub-task
> Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Karl Pauls
> Fix For: i18n 2.5.10
>
>
> It looks like i18n is using some org.json this time from
> o.a.jackrabbit.commons.json. We'll have to replace that too I would guess.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files
[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998790#comment-15998790
]
Alexander Klimetschek commented on SLING-6826:
--
{quote}this "((comment))" concept seems to be an AEM-only concept, not part of
sling{quote}
It doesn't have to, it just needs to use this convention in the dictionary, and
thus frees the Sling i18n layer from this complexity and allows different apps
to use different approaches, if they want.
{quote}the maven tool produced the flat json file in the target folder, not in
the source folder{quote}
This seems like something easy to change in the tool, no?
I just have the feeling that someone else might have different ideas on how
their json should look like in their development process and then this should
be added to sling i18n as well. Or your development flow and desired json
source format changes in the future.
IMO there should be a clear distinction between what the source translation
files are (such as your nested json, or in AEM we extract XLIFF from the source
code) and the _delivery_ dictionary files that sling i18n can pick up. The
latter should be kept as simple as possible in a key value format, as that's
also how java ResourceBundles "think" as well (we also explicitly designed the
((comment)) feature so that it does not impact sling i18n).
This way we keep these more fluctuating things (source file formats) out of
sling i18n and don't have to adopt it constantly.
> i18n: Supported nested keys in JSON i18n files
> --
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
> Issue Type: New Feature
> Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs
> page:
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those
> in nested objects or arrays. Normally, a dictionary will be just a single
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
> "key1": "value1",
> "key2": "value2",
> "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
> "level1": {
> "key1": "value1",
> "level2: {
> "key2": "value2",
> "level3": {
> "key3": "value3"
> }
> }
> }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as
> key/value map file with no hierarchies at all. in this case the result is the
> same. but if someone used hierarchies this ticket will create a backward
> compatibility issue. i will start a discussion on the sling-dev list about
> this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files
[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997693#comment-15997693
]
Alexander Klimetschek commented on SLING-6826:
--
This means the nested structure maps to aggregated keys like
{{application1.section1.component1.key1}} (mentioned in the description above,
but I somehow missed it).
Is having a plain json dictionary like this instead not feasible?
{code}
{
"application1.section1.component1.key1": "value1",
"application1.section1.component1.key2": "value2"
}
{code}
I'd be a bit hesitant to add a feature that is json format specific and not
really supported by other dictionary formats (e.g. the old sling:Message
structure, or even other like XLIFF). It could lead to some incompatibilities
at some point, and keeping it simple at the sling i18n side might be better.
You could build a little preprocessor that would convert the nested
dictionaries into the plain json format for example, as part of build tooling.
{quote}whenever the english text changes (for whatever reason), the key
contract is broken and all translations have to be touched as well{quote}
Note that this is a good thing, as when you change the original english text,
you usually need to change the translation or at least review it. The clearly
missing key/translation makes this detectable.
{quote}it is not possible to "namespace" i18n keys to separate different
applications deployed by different parties on the same instance{quote}
Yes, it is possible using comments. The convention we use in AEM is {{message
((comment))}} as key, and we have tooling around it (i.e. an API that supports
comments and our translation tooling can handle it and generate the right json
dictionaries in the end). Then you can have e.g.
* {{Share ((action button in main toolbar))}}
* {{Share ((link to the collaboration area))}}
Another option is to use the [basename
support|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names],
where each dictionary has its own basename and you request the a specific
ResourceBundle at runtime,
> i18n: Supported nested keys in JSON i18n files
> --
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
> Issue Type: New Feature
> Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs
> page:
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those
> in nested objects or arrays. Normally, a dictionary will be just a single
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
> "key1": "value1",
> "key2": "value2",
> "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
> "level1": {
> "key1": "value1",
> "level2: {
> "key2": "value2",
> "level3": {
> "key3": "value3"
> }
> }
> }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as
> key/value map file with no hierarchies at all. in this case the result is the
> same. but if someone used hierarchies this ticket will create a backward
> compatibility issue. i will start a discussion on the sling-dev list about
> this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files
[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995856#comment-15995856
]
Alexander Klimetschek commented on SLING-6826:
--
What is the use case for supporting nested json files?
At first glance, it only increases complexity to me (well, only a bit, but
looking at future maintenance it might be). The json format is kind of
proprietary (albeit it's dead simple) and is assumed to be converted from other
dictionaries such as xliff etc. anyway...
Thus I also would be surprised if people are using it with nested json today,
where not all contents would be used by sling i18n (to answer your question).
> i18n: Supported nested keys in JSON i18n files
> --
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
> Issue Type: New Feature
> Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs
> page:
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those
> in nested objects or arrays. Normally, a dictionary will be just a single
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
> "key1": "value1",
> "key2": "value2",
> "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
> "level1": {
> "key1": "value1",
> "level2: {
> "key2": "value2",
> "level3": {
> "key3": "value3"
> }
> }
> }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as
> key/value map file with no hierarchies at all. in this case the result is the
> same. but if someone used hierarchies this ticket will create a backward
> compatibility issue. i will start a discussion on the sling-dev list about
> this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)
[
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965637#comment-15965637
]
Alexander Klimetschek edited comment on SLING-6777 at 4/12/17 10:06 AM:
At first, I can only see this happening on bundle restarts or component
restarts due to configuration changes (i.e. the {{JcrResourceBundleProvider}}
restarting), while some request using the {{ValidationService}} is still being
processed and still has a reference on the closing provider. Where I don't
think much can be done. It's a somewhat typical issue you often get during
restarts.
Is there any indication this is happening frequently instead of a one-off
situation and persists after it has happened once?
{quote}we should handle closed resolvers in Validation gracefully{quote}
Note that Validation does not see the resolver here, so validation could not
handle this directly.
{quote}Should we switch to short running resolver in i18n{quote}
Seems possible. It is long running because it was originally used for JCR
observation. But since SLING-4186 and [this
change|https://github.com/apache/sling/commit/a30af93968405819c1b607e89ff7b5371f74533d],
it leverages the Sling Resource Change stuff, which I believe has its own
listener session(s).
was (Author: alexander.klimetschek):
At first, I can only see this happening on bundle restarts or component
restarts due to configuration changes (i.e. the {{JcrResourceBundleProvider}}
restarting), while some request using the {{ValidationService}} is still being
processed and still has a reference on the closing provider. Where I don't
think much can be done. It's a somewhat typical issue you often get during
restarts.
Is there any indication this is happening frequently instead of a one-off
situation and persists once it has happened once?
{quote}we should handle closed resolvers in Validation gracefully{quote}
Note that Validation does not see the resolver here, so validation could not
handle this directly.
{quote}Should we switch to short running resolver in i18n{quote}
Seems possible. It is long running because it was originally used for JCR
observation. But since SLING-4186 and [this
change|https://github.com/apache/sling/commit/a30af93968405819c1b607e89ff7b5371f74533d],
it leverages the Sling Resource Change stuff, which I believe has its own
listener session(s).
> ValidationServiceImpl breaks when hitting closed resolver for resource
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
> at
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
> at
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
> at
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
> at
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6777) ValidationServiceImpl breaks when hitting closed resolver for resource bundles (i18n)
[
https://issues.apache.org/jira/browse/SLING-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965637#comment-15965637
]
Alexander Klimetschek commented on SLING-6777:
--
At first, I can only see this happening on bundle restarts or component
restarts due to configuration changes (i.e. the {{JcrResourceBundleProvider}}
restarting), while some request using the {{ValidationService}} is still being
processed and still has a reference on the closing provider. Where I don't
think much can be done. It's a somewhat typical issue you often get during
restarts.
Is there any indication this is happening frequently instead of a one-off
situation and persists once it has happened once?
{quote}we should handle closed resolvers in Validation gracefully{quote}
Note that Validation does not see the resolver here, so validation could not
handle this directly.
{quote}Should we switch to short running resolver in i18n{quote}
Seems possible. It is long running because it was originally used for JCR
observation. But since SLING-4186 and [this
change|https://github.com/apache/sling/commit/a30af93968405819c1b607e89ff7b5371f74533d],
it leverages the Sling Resource Change stuff, which I believe has its own
listener session(s).
> ValidationServiceImpl breaks when hitting closed resolver for resource
> bundles (i18n)
> -
>
> Key: SLING-6777
> URL: https://issues.apache.org/jira/browse/SLING-6777
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Validation
>Reporter: Oliver Lietz
>
> {noformat}
> java.lang.IllegalStateException: Resource resolver is already closed.
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.checkClosed(ResourceResolverImpl.java:186)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:731)
> at
> org.apache.sling.i18n.impl.JcrResourceBundle.loadPotentialLanguageRoots(JcrResourceBundle.java:328)
> at
> org.apache.sling.i18n.impl.JcrResourceBundle.(JcrResourceBundle.java:85)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.createResourceBundle(JcrResourceBundleProvider.java:452)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundleInternal(JcrResourceBundleProvider.java:411)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:180)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.getResourceBundle(JcrResourceBundleProvider.java:171)
> at
> org.apache.sling.validation.impl.ValidationServiceImpl.getDefaultResourceBundle(ValidationServiceImpl.java:196)
> at
> org.apache.sling.validation.impl.ValidationServiceImpl.validate(ValidationServiceImpl.java:292)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6719) Add Server-Timing header to enable chrome log server timings
[ https://issues.apache.org/jira/browse/SLING-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15943521#comment-15943521 ] Alexander Klimetschek commented on SLING-6719: -- The request progress tracker log could be dumped into the Server-Timings header (optional, off by default, as you probably don't want this by default). See thread https://twitter.com/cpilsworth/status/845760731278553089 If you want more info like MongoDB access times, these can then be added to the tracker log. > Add Server-Timing header to enable chrome log server timings > > > Key: SLING-6719 > URL: https://issues.apache.org/jira/browse/SLING-6719 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Log Tracer 1.0.2 > > > Chrome supports Server-Timing header [1] [2] to provide views around time > spent on server side for various sub calls as part of overall > request-response timing UI. > We should utlilize that in Sling to log time data for e.g. remote calls made > to Mongo as part of given request processing. > [1] https://w3c.github.io/server-timing/ > [2] https://ma.ttias.be/server-timings-chrome-devtools/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6552) ResourceResolver must be independent from javax.jcr
[ https://issues.apache.org/jira/browse/SLING-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892684#comment-15892684 ] Alexander Klimetschek commented on SLING-6552: -- Does this actually work if no javax.jcr bundle is present? ResourceResolverImpl references that new JcrNamespaceMangler (which has the javax.jcr imports) directly through casting inside an if condition - does this make Java load that class only when inside the if in demand? > ResourceResolver must be independent from javax.jcr > --- > > Key: SLING-6552 > URL: https://issues.apache.org/jira/browse/SLING-6552 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.5.12, Resource Resolver 1.5.14 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Resolver 1.5.16 > > > Currently the resource resolver bundle imports javax.jcr which makes the > resource resolver unusable if the jcr api is not available > The resource resolver should be independent from the jcr api and run without > it -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SLING-6552) ResourceResolver must be independent from javax.jcr
[ https://issues.apache.org/jira/browse/SLING-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892684#comment-15892684 ] Alexander Klimetschek edited comment on SLING-6552 at 3/2/17 5:51 PM: -- Does this actually work if no javax.jcr bundle is present? ResourceResolverImpl references that new JcrNamespaceMangler (which has the javax.jcr imports) directly through casting inside an if condition - does this make Java load that class only when inside the if on demand? was (Author: alexander.klimetschek): Does this actually work if no javax.jcr bundle is present? ResourceResolverImpl references that new JcrNamespaceMangler (which has the javax.jcr imports) directly through casting inside an if condition - does this make Java load that class only when inside the if in demand? > ResourceResolver must be independent from javax.jcr > --- > > Key: SLING-6552 > URL: https://issues.apache.org/jira/browse/SLING-6552 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.5.12, Resource Resolver 1.5.14 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Resolver 1.5.16 > > > Currently the resource resolver bundle imports javax.jcr which makes the > resource resolver unusable if the jcr api is not available > The resource resolver should be independent from the jcr api and run without > it -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[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=15826747#comment-15826747
]
Alexander Klimetschek commented on SLING-6187:
--
Ah, thanks for the test. This wasn't apparent from skimming over the code! An
explicit comment might be great, since it would be crucial.
We should have a look at the @Suffixes we know (in Sling and AEM) and ask the
community to get a sense.
> 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-6187c.diff, SLING-6187.patch,
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826728#comment-15826728
]
Alexander Klimetschek edited comment on SLING-6187 at 1/17/17 8:13 PM:
---
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list could work as well. Not sure if existing post
processors would typically remove the @Suffix entries from the change list - if
not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
was (Author: alexander.klimetschek):
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list could work as well. Not sure if existing post
processors would typically remove the @Suffix entries from the change list - if
not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
> 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-6187c.diff, SLING-6187.patch,
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826728#comment-15826728
]
Alexander Klimetschek commented on SLING-6187:
--
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list could work as well. Not sure if existing post
processors would typically remove the @Suffix entries from the change list - if
not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
> 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-6187c.diff, SLING-6187.patch,
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826728#comment-15826728
]
Alexander Klimetschek edited comment on SLING-6187 at 1/17/17 8:14 PM:
---
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list at the end as in your patch could work as well.
Not sure if existing post processors would typically remove the @Suffix entries
from the change list - if not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
was (Author: alexander.klimetschek):
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list could work as well. Not sure if existing post
processors would typically remove the @Suffix entries from the change list - if
not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
> 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-6187c.diff, SLING-6187.patch,
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15760252#comment-15760252
]
Alexander Klimetschek commented on SLING-6187:
--
It wouldn't be prohibited in general, but just if 2 parameters are there, one
is the property, the other is property + suffix. Pretty unlikely and you could
have a per request flag to override this (or use ./ trickery).
Alternatively we could come up with a new syntax, say ":property@Suffix"
(leading : is already used as special parameter in the post servlet).
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187-validating.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15752215#comment-15752215
]
Alexander Klimetschek commented on SLING-6187:
--
IIUC, the new validating patch requires a configuration of the sling post
servlet bundle (for the ModificationValidatingPostProcessor) to set a pattern
(like @Encrypted) that must not be present after all other processors have run
through?
That seems feasible, albeit it does require the @Encrypted post processor
module provider to ensure this configuration on the sling post servlet is also
present. If they put the configuration in the same deployment package as the
post processor, there is still a (very small?) chance that these are
temporarily gone _together_, leading to the original issue.
If we have a mechanism where the presence of a post processor that announces
its @Suffix in the service properties itself is enough (see above), that
additional configuration wouldn't be necessary. But that would mean all post
processors handling custom suffixes need to be changed, otherwise their
requests would fail. How many custom @Suffix based post processors do we know
about?
I would like to hear others opinion on that as well.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187-validating.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15748802#comment-15748802
]
Alexander Klimetschek commented on SLING-6187:
--
The core of the issue is that the use of @Suffix together with a post processor
will write the properties if the processor is not there, because the post
servlet itself does not know about the suffixes and post processors. We should
fix that and have a mechanism where the post servlet knows about the suffix. Or
something else if we don't want to touch the suffix behaviour.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746895#comment-15746895
]
Alexander Klimetschek commented on SLING-6187:
--
The point is _additional_ parameter. The request already says "@Encrypted" and
indicates what it wants. Adding a second one, with more arbitrary names, and
which also works if left out, will not help the situation IMO.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746876#comment-15746876
]
Alexander Klimetschek commented on SLING-6187:
--
FWIW: All approaches require changes to the requests made by clients anyway.
Except for this one: have the post servlet detect suffixes, have post
processors indicate their suffixes in a service property, and make it fail if
no such processor is found.
Suffix detection means:
- there is one property named "xyz"
- AND there is another "xyz@"
Then normal properties containing a @ are still possible. However, all post
processors handling suffixes are required to be changed and advertise their
suffix, otherwise their requests will fail.
Upside would be that the request signature would not change at all.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746852#comment-15746852
]
Alexander Klimetschek edited comment on SLING-6187 at 12/14/16 1:26 AM:
My view now is that a post processor that relies on the @Suffix mechanism where
the properties would be written differently, without failure, if the processor
is not active, is a problem of the processor. And slightly so for Sling
encouraging this fragile approach. The Sling Post servlet should have a
mechanism like I outlined above that gives a clear behavior, without a default
behavior fallback, without any implementation specific references the client
has to know about.
Why should an API client know that certain fields are handled by a post
processor and also pass another parameter where it has to know that the set is
called xyz? Note that addressing the profile is not different from addressing
individual post processor names, it is an implementation detail.
It should behave like an extra sling post operation, which I believe would fail
if not present based on the _operation name_ aka _suffix name_ or prefix
"trick" as in my proposal above.
was (Author: alexander.klimetschek):
My view now is that a post processor that relies on the @Suffix mechanism where
the properties would be written differently, without failure, if the processor
is not active, is a problem of the processor. And slightly so for Sling
encouraging this fragile approach. The Sling Post servlet should have a
mechanism like I outlined above that gives a clear behavior, without a default
behavior fallback, without any implementation specific references the client
has to know about.
Why should an API client know that certain fields are handled by a post
processor and also pass another parameter where it has to know that the set is
called xyz? Note that addressing the profile is not different from addressing
individual post processor names, it is an implementation detail.
It should behave like an extra sling post operation, which I believe would fail
if not present, but as part of the normal sling post servlet mixed with normal
properties.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746852#comment-15746852
]
Alexander Klimetschek commented on SLING-6187:
--
My view now is that a post processor that relies on the @Suffix mechanism where
the properties would be written differently, without failure, if the processor
is not active, is a problem of the processor. And slightly so for Sling
encouraging this fragile approach. The Sling Post servlet should have a
mechanism like I outlined above that gives a clear behavior, without a default
behavior fallback, without any implementation specific references the client
has to know about.
Why should an API client know that certain fields are handled by a post
processor and also pass another parameter where it has to know that the set is
called xyz? Note that addressing the profile is not different from addressing
individual post processor names, it is an implementation detail.
It should behave like an extra sling post operation, which I believe would fail
if not present, but as part of the normal sling post servlet mixed with normal
properties.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [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=15746788#comment-15746788
]
Alexander Klimetschek commented on SLING-6187:
--
What about this alternative?
- these encrypted properties are prefixed with a value like j_ so they do not
get handled by the normal SlingPostProcessor (or another prefix, configurable
as per
https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#omitting-some-parameters
)
- that post processor in question only handles the ones with prefix to be sure
they don't get written without it and throws an error otherwise (forces clients
to change the request, alternatively a warning)
- some new mechanism needs to be added to make the reuqest fail if these
properties were not processed so the original request can fail if that post
processor is offline
IMO this needs to be solved on the interface layer (i.e. the request parameters
etc.), and not be depending on the implementation (who knows, maybe we turn
such a post processor into a core feature at some point).
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [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=15745678#comment-15745678
]
Alexander Klimetschek commented on SLING-6187:
--
[~fmeschbe] The problem is if you have an important "add-on" post processor,
for example one that encrypts properties server side before storing them in the
JCR, and for some reason it's not active (bundle restarting etc.). Since it's
"add-on", it would happily store the unprocessed (e.g. unencrypted) value and
return without an error.
Maybe the source of the issue is the add-on character of such a post processor
as in the encryption case. If it would be something that does not work at all
if the post processor (or whatever pluggable interface) is not found, you
automatically get an error.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [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=15732716#comment-15732716
]
Alexander Klimetschek commented on SLING-5745:
--
Unfortunately we could not find any hint on what was going wrong. Only thing
was that we had 4.1.0-snapshot bundles before and went to a 4.1.0 release,
however, the entire tree was replaced in the package and both jars never were
present at the same time in the JCR. In many cases it works fine.
IIUC, the installer logic is pretty complex. Until it's 100% perfect, a "Reset
cache" operation seems useful. Sometimes getting things to work is more time
critical than understanding it fully.
> 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] [Comment Edited] (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=15730412#comment-15730412
]
Alexander Klimetschek edited comment on SLING-5745 at 12/8/16 12:24 AM:
+1
We just had such a situation and doing these steps helped. In our case, after a
package install some bundles were not installed and were shown as
"Untransformed Resources" in /system/console/osgi-installer. Restarting the
bundle, the whole instance or reinstalling the package did not help, they
stayed in there and weren't tried again by the installer for some reason.
We did these steps successfully:
# stop {{org.apache.sling.installer.core}} bundle
# remove {{launchpad/installer/RegisteredResourceList.ser}} on the filesystem
(we kept a backup to be safe)
# start {{org.apache.sling.installer.core}} bundle again
# optional, if sling scripting such as jsps are involved which might be in a
broken state due to the bundles temporarily missing ("Unresolved compilation
problems ... Only a type can be imported"): force recompilation by deleting the
cache & restarting the fsclassloader bundle
was (Author: alexander.klimetschek):
+1
We just had such a situation and doing these steps helped. In our case, after a
package install some bundles were not installed and were shown as
"Untransformed Resources" in /system/console/osgi-installer. Restarting the
bundle, the whole instance or reinstalling the package did not help.
We did these steps:
# stop {{org.apache.sling.installer.core}} bundle
# remove {{launchpad/installer/RegisteredResourceList.ser}} on the filesystem
(we kept a backup to be safe)
# start {{org.apache.sling.installer.core}} bundle again
> 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-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=15730412#comment-15730412
]
Alexander Klimetschek commented on SLING-5745:
--
+1
We just had such a situation and doing these steps helped. In our case, after a
package install some bundles were not installed and were shown as
"Untransformed Resources" in /system/console/osgi-installer. Restarting the
bundle, the whole instance or reinstalling the package did not help.
We did these steps:
# stop {{org.apache.sling.installer.core}} bundle
# remove {{launchpad/installer/RegisteredResourceList.ser}} on the filesystem
(we kept a backup to be safe)
# start {{org.apache.sling.installer.core}} bundle again
> 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] [Comment Edited] (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=15613238#comment-15613238
]
Alexander Klimetschek edited comment on SLING-6187 at 10/27/16 9:17 PM:
Could this check be based on the resource type? Then you'd configure the
required post processors based on the RT (or node type), and it's completely
server side.
This lets me think however, that whatever the @suffix triggers in the first
place (say an encryption of a property), which you want to guarantee, should
probably also be defined purely server side.
I.e. if the client forgets/omits the suffix, the requiredPostProcessor check
would not help and you still get an undesired result.
was (Author: alexander.klimetschek):
Could this check be based on the resource type? Then you'd configure the
required post processors based on the RT (or node type), and it's completely
server side.
This lets me think however, that whatever the @suffix triggers in the first
place (say an encryption of a property), which you want to guarantee, should
probably also be defined purely server side.
> 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
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15613238#comment-15613238
]
Alexander Klimetschek commented on SLING-6187:
--
Could this check be based on the resource type? Then you'd configure the
required post processors based on the RT (or node type), and it's completely
server side.
This lets me think however, that whatever the @suffix triggers in the first
place (say an encryption of a property), which you want to guarantee, should
probably also be defined purely server side.
> 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
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606603#comment-15606603
]
Alexander Klimetschek commented on SLING-6187:
--
regarding 2): the @suffix is in a separate request parameter and this is
already handled IIRC.
The name of the post processor is a server implementation detail and with a new
request parameter existing clients would have to be changed. Maybe there is a
other way to ensure it...
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606487#comment-15606487
]
Alexander Klimetschek commented on SLING-6187:
--
Having clients to specify that doesn't feel quite right - it should be a server
side validation.
What if the sling post servlet understands the @suffix (in this case
@Encrypted) and detects if no post processor has handled it?
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
>
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-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=15605824#comment-15605824
]
Alexander Klimetschek commented on SLING-6165:
--
SLING-5277 has a
[patch|https://issues.apache.org/jira/secure/attachment/12835048/SLING-5277-new.patch]
that might help.
Make sure to test it with a servlet that doesn't do resource type lookups (and
no filter that does so).
> 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.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods 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()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {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] [Comment Edited] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605790#comment-15605790 ] Alexander Klimetschek edited comment on SLING-5277 at 10/25/16 4:39 PM: AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin/service resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. Note that this issue is not about admin vs. service user but about performance of creating this extra session, which adds cost to every single sling request, even if not used at all. was (Author: alexander.klimetschek): AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- 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=15605795#comment-15605795
]
Alexander Klimetschek commented on SLING-6165:
--
Would be great if the ScriptingResourceResolverFactory could fix the SLING-5277
performance issue - to only create the extra JCR session (service user /
service resolver) if it is actually used, and not for every single request.
> 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.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods 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()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {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-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605790#comment-15605790 ] Alexander Klimetschek commented on SLING-5277: -- AFAICS, SLING-6165 just moves this to a different place, but has the same problem that the admin resolver is created for each request (upon SlingRequestEvent.EventType.EVENT_INIT it does rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), even if it is never accessed, because nothing asks for resolving a resource type etc. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603702#comment-15603702 ] Alexander Klimetschek edited comment on SLING-5277 at 10/25/16 12:53 AM: - Attached new patch [^SLING-5277-new.patch] which solves the above discussed issue. The patch is against revision 1730513 though, right after the org.apache.sling.servlets.resolver 2.4.2 release, as afterwards a lot of sling changes happened that requires many bundles to update (which I couldn't easily do in my environment). I haven't got good test numbers yet (only tested this issue together with other changes), but independent tests would be great! /cc [~joerghoh] was (Author: alexander.klimetschek): Attached new patch [^SLING-5277-new.patch] which solves the above discussed issue. I haven't got good test numbers yet (only tested this issue together with other changes), but independent tests would be great! /cc [~joerghoh] > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5277: - Attachment: SLING-5277-new.patch Attached new patch [^SLING-5277-new.patch] which solves the above discussed issue. I haven't got good test numbers yet (only tested this issue together with other changes), but independent tests would be great! /cc [~joerghoh] > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277-new.patch, SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-6180) Show slowest filters sorted by total time in filter status webconsole
[ https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-6180: - Summary: Show slowest filters sorted by total time in filter status webconsole (was: Show slowest filters sorted by time per request in filter status webconsole) > Show slowest filters sorted by total time in filter status webconsole > - > > Key: SLING-6180 > URL: https://issues.apache.org/jira/browse/SLING-6180 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-6180.patch > > > Current output of /system/console/status-slingfilter includes time > measurements, including time per call. However, to analyze performance of > component & include filters a time per request would be helpful, as these are > called multiple times per request. > Also, with a longer list of filters it would be nice to have this information > sorted by their time per request, so that the "worst" offenders show up at > the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[ https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15597291#comment-15597291 ] Alexander Klimetschek edited comment on SLING-6180 at 10/22/16 6:50 AM: Attaching a new version that fixes a memory leak - using the unique RequestData instead of ServletRequest (which is often wrapped and there are multiple instances of it per actual request) to track the requests. Also sorting by the aggregated total time, which turns out to be more useful in identifying the filters that burn the most cpu cycles. was (Author: alexander.klimetschek): Attaching a new version that fixes a memory leak - using the unique RequestData instead of ServletRequest (which is often wrapped and there are multiple instances of it per actual request) to track the requests. > Show slowest filters sorted by time per request in filter status webconsole > --- > > Key: SLING-6180 > URL: https://issues.apache.org/jira/browse/SLING-6180 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-6180.patch > > > Current output of /system/console/status-slingfilter includes time > measurements, including time per call. However, to analyze performance of > component & include filters a time per request would be helpful, as these are > called multiple times per request. > Also, with a longer list of filters it would be nice to have this information > sorted by their time per request, so that the "worst" offenders show up at > the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[ https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-6180: - Attachment: (was: SLING-6180.patch) > Show slowest filters sorted by time per request in filter status webconsole > --- > > Key: SLING-6180 > URL: https://issues.apache.org/jira/browse/SLING-6180 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-6180.patch > > > Current output of /system/console/status-slingfilter includes time > measurements, including time per call. However, to analyze performance of > component & include filters a time per request would be helpful, as these are > called multiple times per request. > Also, with a longer list of filters it would be nice to have this information > sorted by their time per request, so that the "worst" offenders show up at > the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[ https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-6180: - Attachment: SLING-6180.patch > Show slowest filters sorted by time per request in filter status webconsole > --- > > Key: SLING-6180 > URL: https://issues.apache.org/jira/browse/SLING-6180 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-6180.patch > > > Current output of /system/console/status-slingfilter includes time > measurements, including time per call. However, to analyze performance of > component & include filters a time per request would be helpful, as these are > called multiple times per request. > Also, with a longer list of filters it would be nice to have this information > sorted by their time per request, so that the "worst" offenders show up at > the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[ https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-6180: - Attachment: SLING-6180.patch Attaching a new version that fixes a memory leak - using the unique RequestData instead of ServletRequest (which is often wrapped and there are multiple instances of it per actual request) to track the requests. > Show slowest filters sorted by time per request in filter status webconsole > --- > > Key: SLING-6180 > URL: https://issues.apache.org/jira/browse/SLING-6180 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-6180.patch > > > Current output of /system/console/status-slingfilter includes time > measurements, including time per call. However, to analyze performance of > component & include filters a time per request would be helpful, as these are > called multiple times per request. > Also, with a longer list of filters it would be nice to have this information > sorted by their time per request, so that the "worst" offenders show up at > the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[ https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-6180: - Attachment: (was: SLING-6180.patch) > Show slowest filters sorted by time per request in filter status webconsole > --- > > Key: SLING-6180 > URL: https://issues.apache.org/jira/browse/SLING-6180 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-6180.patch > > > Current output of /system/console/status-slingfilter includes time > measurements, including time per call. However, to analyze performance of > component & include filters a time per request would be helpful, as these are > called multiple times per request. > Also, with a longer list of filters it would be nice to have this information > sorted by their time per request, so that the "worst" offenders show up at > the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[
https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596897#comment-15596897
]
Alexander Klimetschek edited comment on SLING-6180 at 10/22/16 1:34 AM:
Attached a patch: [^SLING-6180.patch]
This will:
* track number of requests in addition to number of calls per FilterHandle
* in the web console status output, show data aggregated by filter (i.e. if the
filter appears in different scopes)
* show time per request
* sort by time per request
Example output (added at the end):
{noformat}
Aggregated performance:
com.day.cq.wcm.core.impl.WCMComponentFilter: called: 29294; time: 283821ms;
time/call: 9688µs; time/request: 17325µs
com.adobe.cq.dam.webdav.impl.io.DamWebdavRequestFilter: called: 15; time: 13ms;
time/call: 866µs; time/request: 866µs
com.adobe.granite.httpcache.impl.InnerCacheFilter: called: 6931; time: 5253ms;
time/call: 757µs; time/request: 757µs
com.day.cq.dam.core.impl.servlet.DamContentDispositionFilter: called: 25; time:
16ms; time/call: 640µs; time/request: 640µs
com.adobe.granite.requests.logging.impl.RequestLoggerImpl: called: 6931; time:
2500ms; time/call: 360µs; time/request: 360µs
com.adobe.cq.social.commons.cors.CORSAuthenticationFilter: called: 6931; time:
2292ms; time/call: 330µs; time/request: 330µs
com.adobe.cq.social.ugcbase.security.impl.SaferSlingPostServlet: called: 6931;
time: 1957ms; time/call: 282µs; time/request: 282µs
com.adobe.granite.resourceresolverhelper.impl.ResourceResolverHelperImpl:
called: 6931; time: 1396ms; time/call: 201µs; time/request: 201µs
com.day.cq.dam.core.impl.assetlinkshare.AdhocAssetShareAuthHandler: called:
6931; time: 1267ms; time/call: 182µs; time/request: 182µs
com.day.cq.wcm.core.impl.WCMRequestFilter: called: 6931; time: 1187ms;
time/call: 171µs; time/request: 171µs
com.day.cq.wcm.core.impl.WCMDebugFilter: called: 29294; time: 2265ms;
time/call: 77µs; time/request: 138µs
com.day.cq.dam.core.impl.servlet.ActivityRecordHandler: called: 6931; time:
724ms; time/call: 104µs; time/request: 104µs
com.adobe.granite.optout.impl.OptOutFilter: called: 6931; time: 661ms;
time/call: 95µs; time/request: 95µs
org.apache.sling.rewriter.impl.RewriterFilter: called: 6933; time: 86ms;
time/call: 12µs; time/request: 12µs
com.day.cq.wcm.mobile.core.impl.redirect.RedirectFilter: called: 6759; time:
72ms; time/call: 10µs; time/request: 10µs
com.day.cq.wcm.core.impl.WCMDeveloperModeFilter: called: 22353; time: 61ms;
time/call: 2µs; time/request: 6µs
com.adobe.granite.csrf.impl.CSRFFilter: called: 6931; time: 46ms; time/call:
6µs; time/request: 6µs
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter: called:
6931; time: 43ms; time/call: 6µs; time/request: 6µs
org.apache.sling.bgservlets.impl.BackgroundServletStarterFilter: called: 6931;
time: 41ms; time/call: 5µs; time/request: 5µs
com.adobe.granite.rest.assets.impl.AssetContentDispositionFilter: called: 6941;
time: 33ms; time/call: 4µs; time/request: 4µs
com.day.cq.wcm.foundation.forms.impl.FormsHandlingServlet: called: 6931; time:
25ms; time/call: 3µs; time/request: 3µs
org.apache.sling.security.impl.ContentDispositionFilter: called: 6931; time:
21ms; time/call: 3µs; time/request: 3µs
com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl: called: 6931; time: 22ms;
time/call: 3µs; time/request: 3µs
com.adobe.cq.mcm.campaign.servlets.CampaignCopyTracker: called: 6931; time:
27ms; time/call: 3µs; time/request: 3µs
com.adobe.granite.rest.impl.servlet.ApiResourceFilter: called: 6931; time:
18ms; time/call: 2µs; time/request: 2µs
org.apache.sling.i18n.impl.I18NFilter: called: 6943; time: 13ms; time/call:
1µs; time/request: 1µs
com.day.cq.personalization.impl.TargetComponentFilter: called: 29294; time:
0ms; time/call: 0µs; time/request: 0µs
org.apache.sling.distribution.servlet.DistributionAgentCreationFilter: called:
0; time: 0ms; time/call: -1µs; time/request: -1µs
{noformat}
The tracking of requests and requestsSeen in the FilterHandle should be
reviewed carefully as it is called concurrently. In my first version I had no
concurrent hash map and it easily killed a server when running a load test
against it. AFAICS, the solution now should work fine, but I wonder if it
doesn't add new blocking and if there is a better solution available. There is
a new endRequest() called by the SlingRequestProcessorImpl at the end of the
request that removes the tracked request object again, to ensure the map is not
growing too much.
was (Author: alexander.klimetschek):
Attached a patch: [^SLING-6180.patch]
This will:
* track number of requests in addition to number of calls per FilterHandle
* in the web console status output, show data aggregated by filter (i.e. if the
filter appears in different scopes)
* show time per request
* sort by time per request
Example output (added at the end):
{noformat}
Aggregated performance:
[jira] [Updated] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
[
https://issues.apache.org/jira/browse/SLING-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated SLING-6180:
-
Attachment: SLING-6180.patch
Attached a patch: [^SLING-6180.patch]
This will:
* track number of requests in addition to number of calls per FilterHandle
* in the web console status output, show data aggregated by filter (i.e. if the
filter appears in different scopes)
* show time per request
* sort by time per request
Example output (added at the end):
{noformat}
Aggregated performance:
com.day.cq.wcm.core.impl.WCMComponentFilter: called: 29294; time: 283821ms;
time/call: 9688µs; time/request: 17325µs
com.adobe.cq.dam.webdav.impl.io.DamWebdavRequestFilter: called: 15; time: 13ms;
time/call: 866µs; time/request: 866µs
com.adobe.granite.httpcache.impl.InnerCacheFilter: called: 6931; time: 5253ms;
time/call: 757µs; time/request: 757µs
com.day.cq.dam.core.impl.servlet.DamContentDispositionFilter: called: 25; time:
16ms; time/call: 640µs; time/request: 640µs
com.adobe.granite.requests.logging.impl.RequestLoggerImpl: called: 6931; time:
2500ms; time/call: 360µs; time/request: 360µs
com.adobe.cq.social.commons.cors.CORSAuthenticationFilter: called: 6931; time:
2292ms; time/call: 330µs; time/request: 330µs
com.adobe.cq.social.ugcbase.security.impl.SaferSlingPostServlet: called: 6931;
time: 1957ms; time/call: 282µs; time/request: 282µs
com.adobe.granite.resourceresolverhelper.impl.ResourceResolverHelperImpl:
called: 6931; time: 1396ms; time/call: 201µs; time/request: 201µs
com.day.cq.dam.core.impl.assetlinkshare.AdhocAssetShareAuthHandler: called:
6931; time: 1267ms; time/call: 182µs; time/request: 182µs
com.day.cq.wcm.core.impl.WCMRequestFilter: called: 6931; time: 1187ms;
time/call: 171µs; time/request: 171µs
com.day.cq.wcm.core.impl.WCMDebugFilter: called: 29294; time: 2265ms;
time/call: 77µs; time/request: 138µs
com.day.cq.dam.core.impl.servlet.ActivityRecordHandler: called: 6931; time:
724ms; time/call: 104µs; time/request: 104µs
com.adobe.granite.optout.impl.OptOutFilter: called: 6931; time: 661ms;
time/call: 95µs; time/request: 95µs
org.apache.sling.rewriter.impl.RewriterFilter: called: 6933; time: 86ms;
time/call: 12µs; time/request: 12µs
com.day.cq.wcm.mobile.core.impl.redirect.RedirectFilter: called: 6759; time:
72ms; time/call: 10µs; time/request: 10µs
com.day.cq.wcm.core.impl.WCMDeveloperModeFilter: called: 22353; time: 61ms;
time/call: 2µs; time/request: 6µs
com.adobe.granite.csrf.impl.CSRFFilter: called: 6931; time: 46ms; time/call:
6µs; time/request: 6µs
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter: called:
6931; time: 43ms; time/call: 6µs; time/request: 6µs
org.apache.sling.bgservlets.impl.BackgroundServletStarterFilter: called: 6931;
time: 41ms; time/call: 5µs; time/request: 5µs
com.adobe.granite.rest.assets.impl.AssetContentDispositionFilter: called: 6941;
time: 33ms; time/call: 4µs; time/request: 4µs
com.day.cq.wcm.foundation.forms.impl.FormsHandlingServlet: called: 6931; time:
25ms; time/call: 3µs; time/request: 3µs
org.apache.sling.security.impl.ContentDispositionFilter: called: 6931; time:
21ms; time/call: 3µs; time/request: 3µs
com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl: called: 6931; time: 22ms;
time/call: 3µs; time/request: 3µs
com.adobe.cq.mcm.campaign.servlets.CampaignCopyTracker: called: 6931; time:
27ms; time/call: 3µs; time/request: 3µs
com.adobe.granite.rest.impl.servlet.ApiResourceFilter: called: 6931; time:
18ms; time/call: 2µs; time/request: 2µs
org.apache.sling.i18n.impl.I18NFilter: called: 6943; time: 13ms; time/call:
1µs; time/request: 1µs
com.day.cq.personalization.impl.TargetComponentFilter: called: 29294; time:
0ms; time/call: 0µs; time/request: 0µs
org.apache.sling.distribution.servlet.DistributionAgentCreationFilter: called:
0; time: 0ms; time/call: -1µs; time/request: -1µs
{noformat}
> Show slowest filters sorted by time per request in filter status webconsole
> ---
>
> Key: SLING-6180
> URL: https://issues.apache.org/jira/browse/SLING-6180
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Alexander Klimetschek
> Attachments: SLING-6180.patch
>
>
> Current output of /system/console/status-slingfilter includes time
> measurements, including time per call. However, to analyze performance of
> component & include filters a time per request would be helpful, as these are
> called multiple times per request.
> Also, with a longer list of filters it would be nice to have this information
> sorted by their time per request, so that the "worst" offenders show up at
> the top.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6180) Show slowest filters sorted by time per request in filter status webconsole
Alexander Klimetschek created SLING-6180: Summary: Show slowest filters sorted by time per request in filter status webconsole Key: SLING-6180 URL: https://issues.apache.org/jira/browse/SLING-6180 Project: Sling Issue Type: Improvement Components: Servlets Reporter: Alexander Klimetschek Current output of /system/console/status-slingfilter includes time measurements, including time per call. However, to analyze performance of component & include filters a time per request would be helpful, as these are called multiple times per request. Also, with a longer list of filters it would be nice to have this information sorted by their time per request, so that the "worst" offenders show up at the top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4558) Simpler serviceuser config for service user mappings
[
https://issues.apache.org/jira/browse/SLING-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated SLING-4558:
-
Issue Type: Improvement (was: Bug)
> Simpler serviceuser config for service user mappings
>
>
> Key: SLING-4558
> URL: https://issues.apache.org/jira/browse/SLING-4558
> Project: Sling
> Issue Type: Improvement
> Components: Installer
>Reporter: Alexander Klimetschek
> Attachments: SLING-4558.patch
>
>
> For a service user configuration (amendment), one has to currently remember a
> weird long PID:
> {{org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended}}
> plus making sure it has a unique ID by appending {{-something}}, which
> confuses people as to whether that "something" must correspond to a bundle or
> service name (not necessary) or they come up with these long names:
> {{org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended.something.xml}}
> which then create too long paths for some cases (git checkouts under windows
> or jcr repository limitations).
> A simple {{serviceuser}} config node name would be better.
> For reference, the target service is
> [MappingConfigAmendment|https://github.com/apache/sling/blob/trunk/bundles/extensions/serviceusermapper/src/main/java/org/apache/sling/serviceusermapping/impl/MappingConfigAmendment.java]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[ https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15145701#comment-15145701 ] Alexander Klimetschek edited comment on SLING-5274 at 2/13/16 1:55 AM: --- Thanks Bertrand for SLING-5489 ([331ff05a|https://github.com/apache/sling/commit/331ff05a157455c8a030b5afe3fa2299ef8539ce]), it's a good start. For the record, here are the other features in my patch that aren't covered and that might be useful: * include requests with authentication failures in the request history console ** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of handleSecurity() when it returns false; also required some changes in RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and getPathInfo(), plus appropriate logging in handleSecurity() * more detailed logging inside SlingAuthenticator for the individual authentication steps AFAICS, these changes shouldn't depend on the switch to the OSGi http whiteboard implementation, but I don't know for sure. was (Author: alexander.klimetschek): Thanks Bertrand for SLING-5489, it's a good start. For the record, here are the other features in my patch that aren't covered and that might be useful: * include requests with authentication failures in the request history console ** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of handleSecurity() when it returns false; also required some changes in RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and getPathInfo(), plus appropriate logging in handleSecurity() * more detailed logging inside SlingAuthenticator for the individual authentication steps AFAICS, these changes shouldn't depend on the switch to the OSGi http whiteboard implementation, but I don't know for sure. > Include authentication in RequestProgressTracker > > > Key: SLING-5274 > URL: https://issues.apache.org/jira/browse/SLING-5274 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5274-bertrand.patch, SLING-5274.patch > > > The request progress tracker only starts with the sling filters, after the > sling authentication ran through. Since authentication steps can be complex > with multiple handlers (just like filters) and can have a major performance > impact (custom auth handlers, slow resource resolver login) it would be very > useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[ https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15145701#comment-15145701 ] Alexander Klimetschek edited comment on SLING-5274 at 2/13/16 1:55 AM: --- Thanks Bertrand for SLING-5489 ([331ff05a|https://github.com/apache/sling/commit/331ff05a157455c8a030b5afe3fa2299ef8539ce]), it's a good start. For the record, here are the other features in my patch that might be useful: * include requests with authentication failures in the request history console ** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of handleSecurity() when it returns false; also required some changes in RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and getPathInfo(), plus appropriate logging in handleSecurity() * more detailed logging inside SlingAuthenticator for the individual authentication steps AFAICS, these changes shouldn't depend on the switch to the OSGi http whiteboard implementation, but I don't know for sure. was (Author: alexander.klimetschek): Thanks Bertrand for SLING-5489 ([331ff05a|https://github.com/apache/sling/commit/331ff05a157455c8a030b5afe3fa2299ef8539ce]), it's a good start. For the record, here are the other features in my patch that aren't covered and that might be useful: * include requests with authentication failures in the request history console ** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of handleSecurity() when it returns false; also required some changes in RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and getPathInfo(), plus appropriate logging in handleSecurity() * more detailed logging inside SlingAuthenticator for the individual authentication steps AFAICS, these changes shouldn't depend on the switch to the OSGi http whiteboard implementation, but I don't know for sure. > Include authentication in RequestProgressTracker > > > Key: SLING-5274 > URL: https://issues.apache.org/jira/browse/SLING-5274 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5274-bertrand.patch, SLING-5274.patch > > > The request progress tracker only starts with the sling filters, after the > sling authentication ran through. Since authentication steps can be complex > with multiple handlers (just like filters) and can have a major performance > impact (custom auth handlers, slow resource resolver login) it would be very > useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5274) Include authentication in RequestProgressTracker
[ https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15145701#comment-15145701 ] Alexander Klimetschek commented on SLING-5274: -- Thanks Bertrand for SLING-5489, it's a good start. For the record, here are the other features in my patch that aren't covered and that might be useful: * include requests with authentication failures in the request history console ** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of handleSecurity() when it returns false; also required some changes in RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and getPathInfo(), plus appropriate logging in handleSecurity() * more detailed logging inside SlingAuthenticator for the individual authentication steps AFAICS, these changes shouldn't depend on the switch to the OSGi http whiteboard implementation, but I don't know for sure. > Include authentication in RequestProgressTracker > > > Key: SLING-5274 > URL: https://issues.apache.org/jira/browse/SLING-5274 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5274-bertrand.patch, SLING-5274.patch > > > The request progress tracker only starts with the sling filters, after the > sling authentication ran through. Since authentication steps can be complex > with multiple handlers (just like filters) and can have a major performance > impact (custom auth handlers, slow resource resolver login) it would be very > useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5448) AuthenticationInfoPostProcessor javadoc misleading
[
https://issues.apache.org/jira/browse/SLING-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated SLING-5448:
-
Description:
Currently, the [AuthenticationInfoPostProcessor javadoc
says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object
after authentication has been performed.
{quote}
But that's pretty misleading, as "after authentication" actually means "one
AuthenticationHandler has returned an AuthenticationInfo" object, but does not
include the resource provider creations (e.g. JCR repository login), which are
often understood as part of authentication too.
I suggest this instead:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object
right after one authentication handler has returned it from
extractCredentials() or for an anonymous AuthenticationInfo. It is called
before the resource resolver is created and any authentication in the resource
providers (such as JCR repository login) happens.
As such it is useful to intercept responses from other AuthenticationHandlers
and access or modify the AuthenticationInfo before they are actually used to
create the resource resolver.
{quote}
was:
Currently, the [AuthenticationInfoPostProcessor javadoc
says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object
after authentication has been performed.
{quote}
But that's pretty misleading, as "after authentication" actually means "one
AuthenticationHandler has returned an AuthenticationInfo" object, but does not
include the resource provider creations (e.g. JCR repository login).
I suggest this instead:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object
right after one authentication handler has returned it from
extractCredentials() or for an anonymous AuthenticationInfo. It is called
before the resource resolver is created and any authentication in the resource
providers (such as JCR repository login) happens.
As such it is useful to intercept responses from other AuthenticationHandlers
and access or modify the AuthenticationInfo before they are actually used to
create the resource resolver.
{quote}
> AuthenticationInfoPostProcessor javadoc misleading
> --
>
> Key: SLING-5448
> URL: https://issues.apache.org/jira/browse/SLING-5448
> Project: Sling
> Issue Type: Bug
> Components: Authentication
>Affects Versions: Auth Core 1.3.12
>Reporter: Alexander Klimetschek
>
> Currently, the [AuthenticationInfoPostProcessor javadoc
> says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:
> {quote}
> Service interface which allows bundles to modify the AuthenticationInfo
> object after authentication has been performed.
> {quote}
> But that's pretty misleading, as "after authentication" actually means "one
> AuthenticationHandler has returned an AuthenticationInfo" object, but does
> not include the resource provider creations (e.g. JCR repository login),
> which are often understood as part of authentication too.
> I suggest this instead:
> {quote}
> Service interface which allows bundles to modify the AuthenticationInfo
> object right after one authentication handler has returned it from
> extractCredentials() or for an anonymous AuthenticationInfo. It is called
> before the resource resolver is created and any authentication in the
> resource providers (such as JCR repository login) happens.
> As such it is useful to intercept responses from other AuthenticationHandlers
> and access or modify the AuthenticationInfo before they are actually used to
> create the resource resolver.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5448) AuthenticationInfoPostProcessor javadoc misleading
Alexander Klimetschek created SLING-5448:
Summary: AuthenticationInfoPostProcessor javadoc misleading
Key: SLING-5448
URL: https://issues.apache.org/jira/browse/SLING-5448
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: Auth Core 1.3.12
Reporter: Alexander Klimetschek
Currently, the [AuthenticationInfoPostProcessor javadoc
says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object
after authentication has been performed.
{quote}
But that's pretty misleading, as "after authentication" actually means "one
AuthenticationHandler has returned an AuthenticationInfo" object, but does not
include the resource provider creations (e.g. JCR repository login).
I suggest this instead:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object
right after one authentication handler has returned it from
extractCredentials() or for an anonymous AuthenticationInfo. It is called
before the resource resolver is created and any authentication in the resource
providers (such as JCR repository login) happens.
As such it is useful to intercept responses from other AuthenticationHandlers
and access or modify the AuthenticationInfo before they are actually used to
create the resource resolver.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[
https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081843#comment-15081843
]
Alexander Klimetschek commented on SLING-5277:
--
To fix the DESTROY handling, we can just call
{{this.perThreadScriptResolver.remove()}} without the {{get()}} beforehand and
the not null check.
However, how do we close the per script resource resolver then, in case it was
created? {{ThreadLocal.remove()}} doesn't return the removed object. It seems
we have to do the {{ThreadLocal.get() & initialValue()}} logic ourselves
(again), inside {{getScriptResourceResolver}} using {{ThreadLocal.set()}}, so
that {{ThreadLocal.get()}} will return null if no resolver was set for the
current thread.
> Performance: per thread script resolver (admin session) is always created
> even if cache is hit
> --
>
> Key: SLING-5277
> URL: https://issues.apache.org/jira/browse/SLING-5277
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Alexander Klimetschek
> Attachments: SLING-5277.patch
>
>
> Since SLING-3441, for every request, a new admin / privileged session is
> [created in the
> SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532].
> It is created before the script/servlet cache is checked, so in most cases
> when the cache is hit it is never used, but the cost of creating an extra
> session (which can vary, especially with concurrent traffic) is incurred.
> The per thread script resolver can be created lazily instead of directly in
> the event to avoid this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081834#comment-15081834 ] Alexander Klimetschek edited comment on SLING-5277 at 1/4/16 9:24 PM: -- Good catch. It doesn't need to be created in the DESTROY event. For why it didn't affect my performance tests: Since the destroy event happens at the end of the request, it doesn't affect the latency of request handling from the client pov. I was focusing on the jcr & sling authentication overhead. It should still affect overall throughput, though. And probably the core problem was that concurrent resource resolver creation had a synchronization bottleneck that was fixed recently by SLING-4937 – see my comment there – which made any additional resource resolvers created per request a lot more costly. Still, this should be fixed here and not unnecessarily created, since the sling servlet resolver doesn't have control over how costly creation of a resource resolver is (affected by custom resource providers, other sling issues like SLING-4937, jackrabbit issues...). was (Author: alexander.klimetschek): Good catch. It doesn't need to be created in the DESTROY event. For why it didn't affect my performance tests: Since the destroy event happens at the end of the request, it doesn't affect the latency of request handling from the client pov. I was focusing on the jcr & sling authentication overhead. It should still affect overall throughput. And probably the core problem was that concurrent resource resolver creation had a synchronization bottleneck that was fixed recently by SLING-4937 – see my comment there – which made any additional resource resolvers created per request a lot more costly. Still, this should be fixed here and not unnecessarily created, since the sling servlet resolver doesn't have control over how costly creation of a resource resolver is (affected by custom resource providers, other sling issues like SLING-4937, jackrabbit issues...). > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081834#comment-15081834 ] Alexander Klimetschek edited comment on SLING-5277 at 1/4/16 9:25 PM: -- Good catch. It doesn't need to be created in the DESTROY event. For why it didn't affect my performance tests: Since the destroy event happens at the end of the request, it doesn't affect the latency of request handling from the client pov. I was focusing on the jcr & sling authentication overhead. It should still affect overall throughput, though. And probably the core problem was that concurrent resource resolver creation had a synchronization bottleneck that was fixed recently by SLING-4937 – see my comment there – which made any additional resource resolvers created per request a lot more costly. Still, this should be fixed here and a whole new resource resolver not unnecessarily created, since the sling servlet resolver doesn't have control over how costly creation of a resource resolver is (affected by custom resource providers, other sling issues like SLING-4937, jackrabbit issues...). was (Author: alexander.klimetschek): Good catch. It doesn't need to be created in the DESTROY event. For why it didn't affect my performance tests: Since the destroy event happens at the end of the request, it doesn't affect the latency of request handling from the client pov. I was focusing on the jcr & sling authentication overhead. It should still affect overall throughput, though. And probably the core problem was that concurrent resource resolver creation had a synchronization bottleneck that was fixed recently by SLING-4937 – see my comment there – which made any additional resource resolvers created per request a lot more costly. Still, this should be fixed here and not unnecessarily created, since the sling servlet resolver doesn't have control over how costly creation of a resource resolver is (affected by custom resource providers, other sling issues like SLING-4937, jackrabbit issues...). > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081834#comment-15081834 ] Alexander Klimetschek commented on SLING-5277: -- Good catch. It doesn't need to be created in the DESTROY event. For why it didn't affect my performance tests: Since the destroy event happens at the end of the request, it doesn't affect the latency of request handling from the client pov. I was focusing on the jcr & sling authentication overhead. It should still affect overall throughput. And probably the core problem was that concurrent resource resolver creation had a synchronization bottleneck that was fixed recently by SLING-4937 – see my comment there – which made any additional resource resolvers created per request a lot more costly. Still, this should be fixed here and not unnecessarily created, since the sling servlet resolver doesn't have control over how costly creation of a resource resolver is (affected by custom resource providers, other sling issues like SLING-4937, jackrabbit issues...). > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006105#comment-15006105 ] Alexander Klimetschek commented on SLING-5277: -- The patch does exactly that. In my performance tests it made a noticeable difference, since the session creation cost essentially outweighed the cache benefit. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5288) Restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/SLING-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998939#comment-14998939 ] Alexander Klimetschek commented on SLING-5288: -- For performance reasons I would use a hash set of strings (fully qualified class names) to do the check against and pass that into the object stream already, as you don't want to build the set every time. (I think in an osgi environment you have to use the names and checking for Class equality might not work as these could change over time.) I would also have the class validator be an interface that just does "allows(Class class)", then provide one impl that does the above simple whitelist check, and pass that to the safe object stream. This way applications can provide their own whitelist logic. > Restrict which classes can be deserialized > -- > > Key: SLING-5288 > URL: https://issues.apache.org/jira/browse/SLING-5288 > Project: Sling > Issue Type: Bug > Components: General >Reporter: Bertrand Delacretaz > > To avoid a recently reported Java deserialization vulnerability [1], we > should restrict which classes are accepted when deserializing binaries. > I have created a prototype SafeObjectInputStream at [2], which refuses to > operate on classes that are outside a whitelist. > We probably also need a wrapper for ObjectInputStreams provided by the > environment, that looks a bit harder to create, for now we can already > discuss this prototype to see if we want to pursue the idea. > [1] > https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread > [2] > https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/safe-object-input-stream -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4937) Drop namespace mapping support
[
https://issues.apache.org/jira/browse/SLING-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14997921#comment-14997921
]
Alexander Klimetschek commented on SLING-4937:
--
It also helps with performance A LOT. The call
{{NamespaceMappingSupport#getNamespaceAwareSession}} tends to be comparatively
slow under high traffic with lots of concurrency in my tests. E.g. the actual
repo login takes way less than 0.5 ms (if optimized), but the
getNamespaceAwareSession has a high variance up to 40 ms, being the largest
part of the authentication phase in our sling app.
AFAICS, in commit
https://github.com/apache/sling/commit/75594f9e2cd2c57ea8111935a41d1066dfe86813
(not linked here) it has been removed from AbstractSlingRepository2 eventually.
> Drop namespace mapping support
> --
>
> Key: SLING-4937
> URL: https://issues.apache.org/jira/browse/SLING-4937
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Jackrabbit Server 2.3.0, JCR Base 2.3.0, JCR Oak
> Server 1.0.0
>
>
> I think we should support the support for namespace mapping from our jcr
> base module (and therefore from the jcr server implementations).
> The namespace support parses the Sling-Namespaces header of bundles and
> ensures that every session has namespace prefix mapping based on these
> headers ensuring a stable mapping. The main reason why we added this in
> the first place is, is that in theory one could map e.g. the sling
> namespace prefix to some own non Sling url. Which obviously would break
> all applications. Of course, no one really does this and even with this
> mapping behavuíour in place, I'm pretty sure apps would break if someone
> does crazy mappings as we only cover the part where the Sling API is
> used. Defaulting to the JCR API will probably use the wrong mapping.
> As implementing this mapping creates proxy objects for the session which
> is kind of heavy and I really think that this feature was never really
> useful, I think we should drop it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5274) Include authentication in RequestProgressTracker
[ https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5274: - Flags: Patch > Include authentication in RequestProgressTracker > > > Key: SLING-5274 > URL: https://issues.apache.org/jira/browse/SLING-5274 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5274.patch > > > The request progress tracker only starts with the sling filters, after the > sling authentication ran through. Since authentication steps can be complex > with multiple handlers (just like filters) and can have a major performance > impact (custom auth handlers, slow resource resolver login) it would be very > useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5277: - Attachment: SLING-5277.patch Here is a patch: [^SLING-5277.patch] This makes use of ThreadLocal.initialValue() to create the per thread resolver on demand. Quick testing improves performance (as the session is no longer cloned immediately and upon hitting the cache is never cloned apparently). Should be properly tested though, also in line of SLING-3441. > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5275) RequestProgressTracker should log microseconds
[ https://issues.apache.org/jira/browse/SLING-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5275: - Flags: Patch > RequestProgressTracker should log microseconds > -- > > Key: SLING-5275 > URL: https://issues.apache.org/jira/browse/SLING-5275 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5275.patch > > > The RequestProgressTracker logs timings as milliseconds. If requests are very > fast and in the milliseconds range, more resolution is required for fine > tuning. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5277: - Flags: Patch > Performance: per thread script resolver (admin session) is always created > even if cache is hit > -- > > Key: SLING-5277 > URL: https://issues.apache.org/jira/browse/SLING-5277 > Project: Sling > Issue Type: Bug > Components: Servlets >Reporter: Alexander Klimetschek > Attachments: SLING-5277.patch > > > Since SLING-3441, for every request, a new admin / privileged session is > [created in the > SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. > It is created before the script/servlet cache is checked, so in most cases > when the cache is hit it is never used, but the cost of creating an extra > session (which can vary, especially with concurrent traffic) is incurred. > The per thread script resolver can be created lazily instead of directly in > the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
Alexander Klimetschek created SLING-5277: Summary: Performance: per thread script resolver (admin session) is always created even if cache is hit Key: SLING-5277 URL: https://issues.apache.org/jira/browse/SLING-5277 Project: Sling Issue Type: Bug Components: Servlets Reporter: Alexander Klimetschek Since SLING-3441, for every request, a new admin / privileged session is [created in the SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532]. It is created before the script/servlet cache is checked, so in most cases when the cache is hit it is never used, but the cost of creating an extra session (which can vary, especially with concurrent traffic) is incurred. The per thread script resolver can be created lazily instead of directly in the event to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5274) Include authentication in RequestProgressTracker
Alexander Klimetschek created SLING-5274: Summary: Include authentication in RequestProgressTracker Key: SLING-5274 URL: https://issues.apache.org/jira/browse/SLING-5274 Project: Sling Issue Type: Improvement Components: Engine Reporter: Alexander Klimetschek The request progress tracker only starts with the sling filters, after the sling authentication ran through. Since authentication steps can be complex with multiple handlers (just like filters) and can have a major performance impact (custom auth handlers, slow resource resolver login) it would be very useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5274) Include authentication in RequestProgressTracker
[ https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994940#comment-14994940 ] Alexander Klimetschek commented on SLING-5274: -- Maybe a separate topic, but it would be super awesome if we could also log the osgi httpservice level steps (in Sling's default setup, where it's embedded into that). This includes filters that most folks aren't even aware of, and also httpservice level servlets that never appear here. It would require to generalize the tracker a bit and somehow hook it into the felix http service impl... > Include authentication in RequestProgressTracker > > > Key: SLING-5274 > URL: https://issues.apache.org/jira/browse/SLING-5274 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5274.patch > > > The request progress tracker only starts with the sling filters, after the > sling authentication ran through. Since authentication steps can be complex > with multiple handlers (just like filters) and can have a major performance > impact (custom auth handlers, slow resource resolver login) it would be very > useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5275) RequestProgressTracker should log microseconds
[ https://issues.apache.org/jira/browse/SLING-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5275: - Attachment: SLING-5275.patch Attached patch: [^SLING-5275.patch] This switches completely. Another option might be to have this configurable. if requests are usually slow and say in the 10s to 100s of milliseconds, using microseconds is overkill. > RequestProgressTracker should log microseconds > -- > > Key: SLING-5275 > URL: https://issues.apache.org/jira/browse/SLING-5275 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5275.patch > > > The RequestProgressTracker logs timings as milliseconds. If requests are very > fast and in the milliseconds range, more resolution is required for fine > tuning. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994887#comment-14994887
]
Alexander Klimetschek edited comment on SLING-5274 at 11/7/15 2:31 AM:
---
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
Example authentication failure (note that these were not recorded/visible so
far!):
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET, Path=/bin/ping
15 TIMER_START{Authentication}
31 LOG Calling auth handler: Cloud IMS Authentication Handler
59 LOG Calling auth handler: OAuth Authentication Handler
78 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
81 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
83 LOG Calling auth handler: Token Authentication Handler
88 LOG Calling auth handler: ImageServer Authentication Handler
91 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
115 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
120 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
121 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
125 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
160 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
4572 LOG Login failed: UserId/Password mismatch.
4738 TIMER_END{4720,Authentication} failed
{noformat}
Note that the examples include microsecond logging from the patch in SLING-5275.
Notes about the changes:
- the SlingRequestProgressTracker is now created in
SlingHttpContext#handleSecurity() to start early
- and passed around as request attribute (since at that early stage there is no
SlingHttpServletRequest present yet)
- also getPathInfo() will be null at this early stage and actually never
resolved if the authentication fails, hence using getRequestURI() if it's null
(in the recent request console printer)
- tried to log all pluggable parts and their actual order (auth handlers, auth
post processors)
was (Author: alexander.klimetschek):
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994887#comment-14994887
]
Alexander Klimetschek edited comment on SLING-5274 at 11/7/15 2:32 AM:
---
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
Example authentication failure (note that these were not recorded/visible so
far!):
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET, Path=/bin/ping
15 TIMER_START{Authentication}
31 LOG Calling auth handler: Cloud IMS Authentication Handler
59 LOG Calling auth handler: OAuth Authentication Handler
78 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
81 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
83 LOG Calling auth handler: Token Authentication Handler
88 LOG Calling auth handler: ImageServer Authentication Handler
91 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
115 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
120 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
121 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
125 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
160 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
4572 LOG Login failed: UserId/Password mismatch.
4738 TIMER_END{4720,Authentication} failed
{noformat}
Note that the examples include microsecond logging from the patch in SLING-5275.
Notes about the changes:
- the SlingRequestProgressTracker is now created in
SlingHttpContext#handleSecurity() to start early enough
- and passed around as request attribute (since at that early stage there is no
SlingHttpServletRequest present yet)
- also getPathInfo() will be null at this early stage and actually never
resolved if the authentication fails, hence using getRequestURI() if it's null
(in the recent request console printer)
- tried to log all pluggable parts and their actual order (auth handlers, auth
post processors)
was (Author: alexander.klimetschek):
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994887#comment-14994887
]
Alexander Klimetschek edited comment on SLING-5274 at 11/7/15 2:32 AM:
---
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
Example authentication failure (note that these were not recorded/visible so
far!):
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET, Path=/bin/ping
15 TIMER_START{Authentication}
31 LOG Calling auth handler: Cloud IMS Authentication Handler
59 LOG Calling auth handler: OAuth Authentication Handler
78 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
81 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
83 LOG Calling auth handler: Token Authentication Handler
88 LOG Calling auth handler: ImageServer Authentication Handler
91 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
115 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
120 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
121 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
125 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
160 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
4572 LOG Login failed: UserId/Password mismatch.
4738 TIMER_END{4720,Authentication} failed
{noformat}
Note that the examples include microsecond logging from the patch in SLING-5275.
Notes about the changes:
- the SlingRequestProgressTracker is now created in
SlingHttpContext#handleSecurity() to start early enough
- and passed around as request attribute (since at that early stage there is no
SlingHttpServletRequest yet)
- also getPathInfo() will be null at this early stage and actually never
resolved if the authentication fails, hence using getRequestURI() if it's null
(in the recent request console printer)
- tried to log all pluggable parts and their actual order (auth handlers, auth
post processors)
was (Author: alexander.klimetschek):
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
[jira] [Created] (SLING-5275) RequestProgressTracker should log microseconds
Alexander Klimetschek created SLING-5275: Summary: RequestProgressTracker should log microseconds Key: SLING-5275 URL: https://issues.apache.org/jira/browse/SLING-5275 Project: Sling Issue Type: Improvement Components: Engine Reporter: Alexander Klimetschek The RequestProgressTracker logs timings as milliseconds. If requests are very fast and in the milliseconds range, more resolution is required for fine tuning. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994887#comment-14994887
]
Alexander Klimetschek edited comment on SLING-5274 at 11/7/15 2:23 AM:
---
Attached patch: [^SLING-5274.patch]
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
Example authentication failure (note that these were not recorded/visible so
far!):
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET, Path=/bin/ping
15 TIMER_START{Authentication}
31 LOG Calling auth handler: Cloud IMS Authentication Handler
59 LOG Calling auth handler: OAuth Authentication Handler
78 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
81 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
83 LOG Calling auth handler: Token Authentication Handler
88 LOG Calling auth handler: ImageServer Authentication Handler
91 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
115 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
120 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
121 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
125 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
160 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
4572 LOG Login failed: UserId/Password mismatch.
4738 TIMER_END{4720,Authentication} failed
{noformat}
was (Author: alexander.klimetschek):
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
Example authentication failure (note that these were not recorded/visible so
far!):
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET, Path=/bin/ping
15 TIMER_START{Authentication}
31 LOG Calling auth handler: Cloud IMS Authentication Handler
59 LOG Calling auth
[jira] [Updated] (SLING-5274) Include authentication in RequestProgressTracker
[ https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-5274: - Attachment: SLING-5274.patch > Include authentication in RequestProgressTracker > > > Key: SLING-5274 > URL: https://issues.apache.org/jira/browse/SLING-5274 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek > Attachments: SLING-5274.patch > > > The request progress tracker only starts with the sling filters, after the > sling authentication ran through. Since authentication steps can be complex > with multiple handlers (just like filters) and can have a major performance > impact (custom auth handlers, slow resource resolver login) it would be very > useful to include it with detailed information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994887#comment-14994887
]
Alexander Klimetschek edited comment on SLING-5274 at 11/7/15 2:20 AM:
---
Example authentication success:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
Example authentication failure (note that these were not recorded/visible so
far!):
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET, Path=/bin/ping
15 TIMER_START{Authentication}
31 LOG Calling auth handler: Cloud IMS Authentication Handler
59 LOG Calling auth handler: OAuth Authentication Handler
78 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
81 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
83 LOG Calling auth handler: Token Authentication Handler
88 LOG Calling auth handler: ImageServer Authentication Handler
91 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
115 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
120 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
121 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
125 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
160 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
4572 LOG Login failed: UserId/Password mismatch.
4738 TIMER_END{4720,Authentication} failed
{noformat}
was (Author: alexander.klimetschek):
Example:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
> Include authentication in RequestProgressTracker
>
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Alexander Klimetschek
>
> The request progress tracker only starts with the
[jira] [Commented] (SLING-5274) Include authentication in RequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994887#comment-14994887
]
Alexander Klimetschek commented on SLING-5274:
--
Example:
{noformat}
0 TIMER_START{Request Processing}
1 COMMENT timer_end format is {,}
8 LOG Method=GET,
Path=/is/image/content/dam/geometrixx/portraits/scott_reynolds.jpg
12 TIMER_START{Authentication}
24 LOG Calling auth handler: Cloud IMS Authentication Handler
46 LOG Calling auth handler: OAuth Authentication Handler
65 LOG Calling auth handler: Day CQ Login Selector Authentication Handler
68 LOG Calling auth handler: Granite Client Certificate Authentication
Handler
71 LOG Calling auth handler: Token Authentication Handler
77 LOG Calling auth handler: ImageServer Authentication Handler
80 LOG Calling auth handler:
org.apache.sling.auth.core.impl.HttpBasicAuthenticationHandler
101 LOG AuthenticationHandlers returned: type=BASIC, userId=admin
105 LOG Calling auth post processor:
com.adobe.cq.social.commons.cors.CORSAuthInfoPostProcessor
106 LOG Calling auth post processor:
org.apache.sling.jcr.resource.internal.WorkspaceAuthInfoPostProcessor
109 LOG Calling auth post processor:
com.adobe.cq.creativecloud.cloudims.impl.auth.cookie.TokenAuthenticationInfoPostProcessor
144 LOG Trying to get a resource resolver for: type=BASIC, userId=admin
12408 LOG Login success: Resource Resolver, userId=admin
12428 TIMER_END{12415,Authentication} succeeded
12611 TIMER_START{ResourceResolution}
... existing logs
{noformat}
> Include authentication in RequestProgressTracker
>
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Alexander Klimetschek
>
> The request progress tracker only starts with the sling filters, after the
> sling authentication ran through. Since authentication steps can be complex
> with multiple handlers (just like filters) and can have a major performance
> impact (custom auth handlers, slow resource resolver login) it would be very
> useful to include it with detailed information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5255) Jobs: allow to configure queue.maxparallel in terms of % of number of CPU cores
Alexander Klimetschek created SLING-5255:
Summary: Jobs: allow to configure queue.maxparallel in terms of %
of number of CPU cores
Key: SLING-5255
URL: https://issues.apache.org/jira/browse/SLING-5255
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Alexander Klimetschek
The {{queue.maxparallel}} setting (how many concurrent threads can run for a
given job queue) currently supports a fixed number of threads or -1 which means
"as many CPU cores present on the machine". The latter is in our case used as a
crucial default, but it's too aggressive, since it might take over all CPU
processing.
Since every machine has different numbers of CPUs and cores, it would be useful
to express this config as % of number of CPU cores. This allows for example for
a default setting of 50% that should work well on different machines without
having to manually configure it on each instance.
This could either be a separate setting or (better) maybe allow floating point
numbers between 0.0 and 1.0 to express the percentage for the existing
{{queue.maxparallel}}. E.g. 0.5 means 50% of the cores. If it's an integer,
continue to use it as an exact number of threads to use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5051) RequestDispatcher forward breaks i18n
[
https://issues.apache.org/jira/browse/SLING-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986006#comment-14986006
]
Alexander Klimetschek commented on SLING-5051:
--
You can also simply adjust the service ranking in your filter to be lower than
the i18n filter. You can see the actual filter order at
http://localhost:4502/system/console/status-slingfilter
> RequestDispatcher forward breaks i18n
> -
>
> Key: SLING-5051
> URL: https://issues.apache.org/jira/browse/SLING-5051
> Project: Sling
> Issue Type: Bug
> Components: General
> Environment: Adobe Experience Manager 6.1
>Reporter: Sothea Nim
>
> I just noticed that on AEM 6, in my Filter, when I call RequestDispatcher
> forward, i.e. request.getRequestDispatcher(...).forward(req, res);, it cause
> i18n to break. Here's a snippet of my codes:
> ...
> boolean filtered = false;
> SlingHttpServletRequest request = req instanceof SlingHttpServletRequest ?
> (SlingHttpServletRequest) req : null;
> SlingHttpServletResponse response = res instanceof SlingHttpServletResponse ?
> (SlingHttpServletResponse) res : null;
>
> if (request != null && response != null) {
>
> // block of codes to resolve the request uri and get the new desired URI
>
> if (this.resolvedUriResource != null) {
> String uri = this.resolvedUriResource.getPath() + ".html";
> RequestDispatcherOptions options = new RequestDispatcherOptions();
> options.setAddSelectors(uriSelectors);
>
> this.filterConfig.getServletContext().getRequestDispatcher(uri).forward(req,
> res); // OR
> //request.getRequestDispatcher(this.resolvedUriResource,
> options).forward(req, res);
> filtered = true;
> }
> }
> if (!filtered) {
> chain.doFilter(req, res);
> }
> ...
> Obtain the package contained detailed codes here:
> http://www.sotheanim.com/images/www.sotheanim.com/blog/aem61-i18n-issue-samplepackage.zip
>
> (/sixd/bundle/src/main/java/com/sixd/i18nissue/filter/PathResolutionFilter.java)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5017) Moving a JCR node not reflected in JcrNodeResource
[
https://issues.apache.org/jira/browse/SLING-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14744100#comment-14744100
]
Alexander Klimetschek commented on SLING-5017:
--
I see your points, but the workaround of refetching is extremely ugly in case
of a move of the request resource:
{code}
// request start
// ... do move ...
// due to resouce.getPath cached after moving, use the underlying correct Node
path to fetch it again
Node node = request.getResource().adaptTo(Node.class);
Resource resource = request.getResourceResolver().getResource(node.getPath());
{code}
> Moving a JCR node not reflected in JcrNodeResource
> --
>
> Key: SLING-5017
> URL: https://issues.apache.org/jira/browse/SLING-5017
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Alexander Klimetschek
>
> When moving a JCR node via the JCR API behind a resource, Resource.getPath()
> and Resource.getName() will still return the old path and name:
> {code:java}
> // e.g. "/some/oldname"
> Resource resource = request.getResource();
> // move via JCR API (no move available in resource API)
> Node node = resource.adaptTo(Node.class);
> node.getSession().move(node.getPath(), node.getParent().getPath() +
> "newname");
> node.getSession().save();
> resource.getName(); // returns "oldname"
> resource.getPath(); // returns "/some/oldname"
> {code}
> This is because the path is [cached in
> JcrItemResource|https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L83]
> and it uses the getPath() and [getName() implementation of
> AbstractResource|https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/AbstractResource.java#L53]
> which are based on the cached path.
> To ensure the correct transient JCR semantics, the resource should pass
> getPath() and getName() through to the underlying Node (respectively Item).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
