[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=16351550#comment-16351550 ] Robert Munteanu commented on SLING-3049: [~chetanm] - is the 'Packaging Data' link from https://sling.apache.org/documentation/development/logging.html incorrect? It leads to http://www.slf4j.org/manual.html#mdc > 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 >Priority: Major > Labels: Sling-10-ReleaseNotes, logback > Fix For: Commons Log 5.1.0 > > 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 (v7.6.3#76005)
[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=16259265#comment-16259265 ] ASF GitHub Bot commented on SLING-3049: --- chetanmeh commented on issue #1: SLING-3049 - Make Logback Stacktrace Packaging data support OSGi aware URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/1#issuecomment-345706219 Changes merged to master via rebase This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > 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 > Fix For: Commons Log 5.0.4 > > 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-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=16259264#comment-16259264 ] ASF GitHub Bot commented on SLING-3049: --- chetanmeh closed pull request #1: SLING-3049 - Make Logback Stacktrace Packaging data support OSGi aware URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > 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 > Fix For: Commons Log 5.0.4 > > 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-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=16235466#comment-16235466 ] Chetan Mehrotra commented on SLING-3049: Thanks [~karlpauls] for the feedback bq. Obviously, it suffers a little from not being able to get to the real classes - i.e., it will not report on classes that are provided from more than one bundle Yes. If same package is loaded by multiple bundles then this impl would not provide any info. But in most cases the packages are unique so should be ok for Sling like setup bq. I guess the only question I would have is if this could be problematic for tools/scripts/others that rely on a certain layout of a stacktrace. Not sure that is important. I mostly use Intellij Stacktrace Analyzer and it is able to work with that bq. I suppose you could use some bytecode magic to weave the information about the bundle source into the "Source" field of the class and parse it out later when you need it but that probably isn't a good idea That would be really cool and nifty use of weaving hook!. But for some other day :) > 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 >Priority: Major > 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-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=16235446#comment-16235446 ] Karl Pauls commented on SLING-3049: --- [~chetanm], I think this looks good implementation wise. Obviously, it suffers a little from not being able to get to the real classes - i.e., it will not report on classes that are provided from more than one bundle. Furthermore, the weaving hook approach will require this bundle to be started as early as possible. However, I can't think of a better way to achieve this from the top of my head* and fwiw, the weaving hook implementation looks good (i.e., it doesn't synchronize and loads all classes upfront). I guess the only question I would have is if this could be problematic for tools/scripts/others that rely on a certain layout of a stacktrace. Not sure that is important. Otherwise, I'm happy with it - nice job. * I suppose you could use some bytecode magic to weave the information about the bundle source into the "Source" field of the class and parse it out later when you need it but that probably isn't a good idea :-) > 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 >Priority: Major > 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-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=16226685#comment-16226685
]
Julian Reschke commented on SLING-3049:
---
How about adding bundle + version only when it changes from the previous line?
{noformat}
31.10.2017 17:19:52.383 *WARN* [oak-executor-33]
org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
idle for 2 minutes and might be out of date. Consider using a fresh session or
explicitly refresh the session.
java.lang.Exception: The session was created here:
at
org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:279)
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:220)
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.impersonate(SessionImpl.java:274)
at
org.apache.sling.jcr.oak.server.internal.TcclWrappingJackrabbitSession.impersonate(TcclWrappingJackrabbitSession.java:84)
[org.apache.sling.jcr.oak.server:1.1.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:201)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:171)
at
org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:112)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:275)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:74)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
at
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
at
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getServiceResourceResolver(CommonResourceResolverFactoryImpl.java:396)
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.getResourceTypeResourceResolver(ResourceResolverControl.java:704)
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.getParentResourceType(ResourceResolverControl.java:728)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1216)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1205)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.isResourceType(ResourceResolverImpl.java:1233)
at
org.apache.sling.api.resource.AbstractResource.isResourceType(AbstractResource.java:121)
[org.apache.sling.api:2.16.2]
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.isDictionaryResource(JcrResourceBundleProvider.java:242)
[org.apache.sling.i18n:2.5.8]
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.onChange(JcrResourceBundleProvider.java:222)
at
org.apache.sling.resourceresolver.impl.observation.BasicObservationReporter.reportChanges(BasicObservationReporter.java:211)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:155)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:190)
[org.apache.jackrabbit.jackrabbit-jcr-commons:2.14.3]
at
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:507)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.plugins.observation.FilteringDispatcher.contentChanged(FilteringDispatcher.java:53)
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=16226665#comment-16226665
]
Chetan Mehrotra commented on SLING-3049:
So with bundle name included stacktrace looks like below
{noformat}
31.10.2017 17:19:52.383 *WARN* [oak-executor-33]
org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
idle for 2 minutes and might be out of date. Consider using a fresh session or
explicitly refresh the session.
java.lang.Exception: The session was created here:
at
org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:279)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:220)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.impersonate(SessionImpl.java:274)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.sling.jcr.oak.server.internal.TcclWrappingJackrabbitSession.impersonate(TcclWrappingJackrabbitSession.java:84)
[org.apache.sling.jcr.oak.server:1.1.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:201)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:171)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:112)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:275)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:74)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getServiceResourceResolver(CommonResourceResolverFactoryImpl.java:396)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.getResourceTypeResourceResolver(ResourceResolverControl.java:704)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.getParentResourceType(ResourceResolverControl.java:728)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1216)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1205)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.isResourceType(ResourceResolverImpl.java:1233)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.api.resource.AbstractResource.isResourceType(AbstractResource.java:121)
[org.apache.sling.api:2.16.2]
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.isDictionaryResource(JcrResourceBundleProvider.java:242)
[org.apache.sling.i18n:2.5.8]
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.onChange(JcrResourceBundleProvider.java:222)
[org.apache.sling.i18n:2.5.8]
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=16226482#comment-16226482 ] Bertrand Delacretaz commented on SLING-3049: Thanks for this, looks very useful! Echoing Robert's comment on Twitter, I think it would be useful to also include the bundle symbolic name. It makes the log lines more verbose but such logs are verbose anyway, and it's useful information. > 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-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=16226353#comment-16226353 ] Chetan Mehrotra commented on SLING-3049: bq. Will this be automatically part of any stacktraces in log files? Yes. We can possibly enable this feature by default also > 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-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-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=16223417#comment-16223417
]
Chetan Mehrotra commented on SLING-3049:
Created PR https://github.com/apache/sling-org-apache-sling-commons-log/pull/1
This approach uses a
[WeavingHook|https://osgi.org/javadoc/r4v43/core/org/osgi/framework/hooks/weaving/WeavingHook.html]
to determine class to bundle mapping. Via hook it create a mapping of class
package with bundle version. Then it hooks into the Logback rendering logic to
add the version info as part of stacktrace.
The log entry would look like below
{noformat}
28.10.2017 15:52:34.060 *ERROR* [0:0:0:0:0:0:0:1 [1509186154052] POST
/bin/cpm/nodes/node.create.json HTTP/1.1]
com.composum.sling.core.servlet.ServletOperationSet Access denied.
javax.jcr.AccessDeniedException: Access denied.
at
org.apache.jackrabbit.oak.jcr.security.AccessManager.checkPermissions(AccessManager.java:71)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:295)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:264)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl.addNode(NodeImpl.java:264)
[1.6.4]
at
com.composum.sling.nodes.servlet.NodeFactory$DefaultStrategy.createNode(NodeFactory.java:68)
[1.8.2]
at
com.composum.sling.nodes.servlet.NodeFactory.createNode(NodeFactory.java:51)
[1.8.2]
at
com.composum.sling.nodes.servlet.NodeServlet$CreateOperation.doIt(NodeServlet.java:1083)
[1.8.2]
at
com.composum.sling.core.servlet.ServletOperationSet.doPost(ServletOperationSet.java:173)
[1.8.2]
at
com.composum.sling.core.servlet.AbstractServiceServlet.doPost(AbstractServiceServlet.java:85)
[1.8.2]
at
org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:149)
[2.16.2]
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:346)
[2.16.2]
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:378)
[2.16.2]
at
org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
[2.6.8]
at
org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
[2.6.8]
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:77)
[2.6.8]
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:282)
[2.6.8]
at
org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
[2.6.8]
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:77)
[2.6.8]
at
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:107)
[2.6.8]
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:68)
[2.6.8]
at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:138)
[2.5.8]
{noformat}
With this feature enabled on a larger setup I did not find any delay in
startup/restart. On such a setup it was having mapping for 2000+ packages. This
approach does not add much over head as mapping is cached.
[~karlpauls] [~cziegeler] [~ianeboston] Please review the approach. This
feature should not be adding much overhead and would prove useful when users
provide exception message on mailing list to discuss the issue.
PS: If required we can also include bundle name. But that may not be very useful
> 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] [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=16223415#comment-16223415 ] ASF GitHub Bot commented on SLING-3049: --- chetanmeh opened a new pull request #1: SLING-3049 - Make Logback Stacktrace Packaging data support OSGi aware URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/1 Uses WeavingHook to capture class to bundle mapping and uses that to decorate the stacktrace when logback writes it to appender This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > 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-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-tabpanelfocusedCommentId=13878558#comment-13878558 ] Chetan Mehrotra commented on SLING-3049: I need to rework the pull request. However the problem is (as explained in my last comment above) this feature is tricky to implement in OSGi env. So better to disable it for now. So its bit low priority now 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 Fix For: Commons Log 4.0.0 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.1.5#6160)
[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-tabpanelfocusedCommentId=13847427#comment-13847427 ] Chetan Mehrotra commented on SLING-3049: With [1550694|http://svn.apache.org/r1550694] I have disabled support for PackagingDataCalculator all together. The way it computes PackagingData would cause issue in OSGi environment. Also the support we had required a locally modified file of Logback and which with its EPL licences would anyway have to be removed. So with this disabled we should not see this issue. Later if Logback does include the fix for LOGBACK-899 users can still enable it as suggested in SLING-3257. Leaving it open for now, once it is confirmed that above issue is not seen anymore would close the bug as WontFix 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 Fix For: Commons Log 4.0.0 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.1.4#6159)
[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-tabpanelfocusedCommentId=13847504#comment-13847504 ] Robert Munteanu commented on SLING-3049: Thanks! I've also updated the bundle list to refer to the latest snapshot in http://svn.apache.org/r1550733 . The problem should be gone in the next build. 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 Fix For: Commons Log 4.0.0 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.1.4#6159)
[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-tabpanelfocusedCommentId=13828491#comment-13828491
]
Chetan Mehrotra commented on SLING-3049:
Also the testcase
{{org.apache.sling.commons.log.logback.integration.ITAppenderServices#testPackagingData}}
fails on CI [1] though it passes locally on both Sun JDK and Open JDK
1.7.0-25. For now it is disabled
[1] https://builds.apache.org/job/sling-trunk-1.7
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
Fix For: Commons Log 4.0.0
Attachments: SLING-3049.patch
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.1#6144)
[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-tabpanelfocusedCommentId=13795005#comment-13795005 ] Chetan Mehrotra commented on SLING-3049: Any updates on this? 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 Labels: logback Attachments: SLING-3049.patch 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.1#6144)
[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-tabpanelfocusedCommentId=13795023#comment-13795023 ] Bertrand Delacretaz commented on SLING-3049: Wouldn't it better to set this module to java 6 instead of introducing specific animal sniffer settings? I'm in favor of Java 6. Also, is there a simple way to add automated tests? Maybe just verify that the patch does something, no need to go into detail probably. 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 Labels: logback Attachments: SLING-3049.patch 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.1#6144)
[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-tabpanelfocusedCommentId=13795041#comment-13795041
]
Chetan Mehrotra commented on SLING-3049:
bq. Wouldn't it better to set this module to java 6 instead of introducing
specific animal sniffer settings? I'm in favor of Java 6.
Problem is not due to usage of JDK 6 API but usage of
{{sun.reflect.Reflection}} class and I am not able to exclude it from animal
sniffer check.
bq. Also, is there a simple way to add automated tests? Maybe just verify that
the patch does something, no need to go into detail probably.
Not sure if it can be tested in a simple way.I can add an integration testcase
and have an appender which can check the packaging data from LoggingEvent
created for an exception. That would take some time
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
Labels: logback
Attachments: SLING-3049.patch
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.1#6144)
[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-tabpanelfocusedCommentId=13787935#comment-13787935 ] Chetan Mehrotra commented on SLING-3049: Can this patch be applied? 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 Labels: logback Attachments: SLING-3049.patch 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.1#6144)
[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-tabpanelfocusedCommentId=13762818#comment-13762818 ] Chetan Mehrotra commented on SLING-3049: Problem details around animal sniffer usage As the logic uses some Sun internal classes Animal Sniffer Complains. I am not able to ignore the class hence need to disable it for now. Also 1.9 of animal sniffer fails with version fails with exception java.nio.CharBuffer.subSequence(II)Ljava/nio/CharBuffer;. Seems like a bug with 1.9 so using 1.8 version See following links for animal sniffer related problems * https://svn.apache.org/repos/asf/felix/trunk/threaddump/pom.xml * http://mojo.10943.n7.nabble.com/Animal-sniffer-won-t-run-on-jdk-6-td38697.html If I get time would debug them and open bugs on Animal Sniffer project 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 Labels: logback Attachments: SLING-3049.patch 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[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-tabpanelfocusedCommentId=13762873#comment-13762873 ] Bertrand Delacretaz commented on SLING-3049: As the logic uses some Sun internal classes Animal Sniffer Complains. I am not able to ignore the class hence need to disable it for now. We might want to drop Java 1.5 support...I just did that for the scripting.api bundle in SLING-3042, it's probably not worth bothering with that anymore. I'll discuss on list. 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 Labels: logback Attachments: SLING-3049.patch 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[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-tabpanelfocusedCommentId=13762890#comment-13762890 ] Felix Meschberger commented on SLING-3049: -- +1 I'd say, feel free to just drop Java 5 if needed. 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 Labels: logback Attachments: SLING-3049.patch 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[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-tabpanelfocusedCommentId=13762900#comment-13762900 ] Chetan Mehrotra commented on SLING-3049: For the commons log the JDK level is already to 6 and despite that animal sniffer is giving problem. Looking for the problem on net indicates that it is an issue with plugin itself. Hence disabled it for the patch 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 Labels: logback Attachments: SLING-3049.patch 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
