[jira] [Commented] (SLING-5311) Oak Server: Oak not registered in JMX
[ https://issues.apache.org/jira/browse/SLING-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012736#comment-15012736 ] Chetan Mehrotra commented on SLING-5311: [~sseif...@pro-vision.de] The JMX registration relies on Aries JMX Whiteboard support. Are you using std Sling build? If not check if you have org.apache.aries.jmx/org.apache.aries.jmx.whiteboard/1.0.0 bundle installed > Oak Server: Oak not registered in JMX > - > > Key: SLING-5311 > URL: https://issues.apache.org/jira/browse/SLING-5311 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Oak Server 1.0.0 >Reporter: Stefan Seifert >Priority: Minor > Fix For: JCR Oak Server 1.0.2 > > > the oak server created is not registered properly via JMX. when inspecting > JVM running sling e.g. with JVisualVM and MBeans plugin no JMX entries for > org.apache.jackrabbit.oak.* show up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3635) [Javascript] Optimization level for byte code generator in Rhino should be configurable
[ https://issues.apache.org/jira/browse/SLING-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14997978#comment-14997978 ] Chetan Mehrotra commented on SLING-3635: bq. This option should be configurable, and the default value for this configuration should be "-1" - meaning run scripts in interpreted mode. Since we are not caching script compilation artifacts, the interpreted mode gives the best performance for short-running scripts. Given that with SLING-913 compiled scripts are cached should the default be changed? > [Javascript] Optimization level for byte code generator in Rhino should be > configurable > --- > > Key: SLING-3635 > URL: https://issues.apache.org/jira/browse/SLING-3635 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting JavaScript 2.0.12 >Reporter: Marius-Andrei Danila >Assignee: Bertrand Delacretaz > Fix For: Scripting JavaScript 2.0.14 > > Attachments: SLING-3635.diff > > > The Rhino Javascript engine allows you to choose the level of optimization > for the generated byte code or it lets you select whether the scripts should > be run in interpreted mode [0]. > Currently, there is no way to configure this. By default, Rhino compiles > scripts into JVM classes using the optimization level 0. > This option should be configurable, and the default value for this > configuration should be "-1" - meaning run scripts in interpreted mode. Since > we are not caching script compilation artifacts, the interpreted mode gives > the best performance for short-running scripts. > The attached patch implements this improvement by exposing a configuration > entry in the Rhino Javascript engine factory component. > [0] > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Optimization -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-5092) Missing Content type for system/console/slinglog/tailer.txt
[
https://issues.apache.org/jira/browse/SLING-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned SLING-5092:
--
Assignee: Chetan Mehrotra
> Missing Content type for system/console/slinglog/tailer.txt
> ---
>
> Key: SLING-5092
> URL: https://issues.apache.org/jira/browse/SLING-5092
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Antonio Sanso
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.8
>
>
> {{system/console/slinglog/tailer.txt}} Felix Console plugin is missing
> response content type
> {code}
> HTTP/1.1 200 OK
> Date: Tue, 06 Oct 2015 10:27:07 GMT
> Set-Cookie: felix-webconsole-locale=en;Path=/system/console;Expires=Mon,
> 01-Oct-2035 10:27:07 GMT
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Content-Length: 51
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5092) Missing Content type for system/console/slinglog/tailer.txt
[
https://issues.apache.org/jira/browse/SLING-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-5092:
---
Fix Version/s: Commons Log 4.0.8
> Missing Content type for system/console/slinglog/tailer.txt
> ---
>
> Key: SLING-5092
> URL: https://issues.apache.org/jira/browse/SLING-5092
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Antonio Sanso
> Fix For: Commons Log 4.0.8
>
>
> {{system/console/slinglog/tailer.txt}} Felix Console plugin is missing
> response content type
> {code}
> HTTP/1.1 200 OK
> Date: Tue, 06 Oct 2015 10:27:07 GMT
> Set-Cookie: felix-webconsole-locale=en;Path=/system/console;Expires=Mon,
> 01-Oct-2035 10:27:07 GMT
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Content-Length: 51
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4908) Updated to latest WebConsole release
[ https://issues.apache.org/jira/browse/SLING-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693171#comment-14693171 ] Chetan Mehrotra commented on SLING-4908: Thanks [~rombert] and [~cziegeler] for taking care of this - Did not realized that update the WebConsole would have broken such test (UI worked fine). Would be more careful in future while make such changes > Updated to latest WebConsole release > > > Key: SLING-4908 > URL: https://issues.apache.org/jira/browse/SLING-4908 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Launchpad Builder 8 > > > We should update to the org.apache.felix.webconsole to 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4914) LogPanel should pass appender name as request parameter
[ https://issues.apache.org/jira/browse/SLING-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-4914. -- > LogPanel should pass appender name as request parameter > --- > > Key: SLING-4914 > URL: https://issues.apache.org/jira/browse/SLING-4914 > Project: Sling > Issue Type: Bug > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 4.0.6 > > > SlingLogPanel currently passes the appender name as part of request url > itself. This can at times pose problem as the appender name can be arbitrary. > It would be better if the name is passed as part of request parameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4914) LogPanel should pass appender name as request parameter
[ https://issues.apache.org/jira/browse/SLING-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4914. Resolution: Fixed Change the implementation. Now url is like below http://localhost:8080/system/console/slinglog/tailer.txt?tail=&name= Done with http://svn.apache.org/r1693182 > LogPanel should pass appender name as request parameter > --- > > Key: SLING-4914 > URL: https://issues.apache.org/jira/browse/SLING-4914 > Project: Sling > Issue Type: Bug > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 4.0.6 > > > SlingLogPanel currently passes the appender name as part of request url > itself. This can at times pose problem as the appender name can be arbitrary. > It would be better if the name is passed as part of request parameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4914) LogPanel should pass appender name as request parameter
Chetan Mehrotra created SLING-4914: -- Summary: LogPanel should pass appender name as request parameter Key: SLING-4914 URL: https://issues.apache.org/jira/browse/SLING-4914 Project: Sling Issue Type: Bug Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Commons Log 4.0.6 SlingLogPanel currently passes the appender name as part of request url itself. This can at times pose problem as the appender name can be arbitrary. It would be better if the name is passed as part of request parameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4911) Upgrade to Oak 1.3.3
[
https://issues.apache.org/jira/browse/SLING-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644123#comment-14644123
]
Chetan Mehrotra commented on SLING-4911:
[~olli] Do note that Oak 1.3.x releases are considered unstable releases. If
you want to use Oak for production then its better to stick to 1.2.x versions.
Latest there being 1.2.3
> Upgrade to Oak 1.3.3
>
>
> Key: SLING-4911
> URL: https://issues.apache.org/jira/browse/SLING-4911
> Project: Sling
> Issue Type: Improvement
> Components: Launchpad, Oak
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Oak Server 1.0.0, Launchpad Karaf Features 0.2.0,
> Launchpad Builder 8
>
>
> * {{bundles/jcr/it-jackrabbit-oak/pom.xml}}
> * {{bundles/jcr/oak-server/pom.xml}}
> * {{launchpad/builder/src/main/provisioning/oak.txt}}
> *
> {{contrib/launchpad/karaf/org.apache.sling.launchpad.karaf-features/src/main/feature/feature.xml}}
> SLING-4873
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4910) NPE in JCrResourceBundleProvider
[
https://issues.apache.org/jira/browse/SLING-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643830#comment-14643830
]
Chetan Mehrotra commented on SLING-4910:
Seeing this issue with latest trunk i.e. 2.4.3-SNAPSHOT
[~kwin] May be this is related to recent changes done for SLING-4811. Can you
have a look
> NPE in JCrResourceBundleProvider
>
>
> Key: SLING-4910
> URL: https://issues.apache.org/jira/browse/SLING-4910
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: i18n 2.4.4
>
>
> At fresh startup seeing couple of exceptions like below. Looks like by the
> time events are delivered ResourceResolverFactory is still not set
> (ResourceResolverFactory is missing. Cannot create ResourceResolver) which
> later causes NPE.
> {noformat}
> 28.07.2015 09:37:49.803 *ERROR* [Thread-36]
> org.apache.sling.i18n.impl.JcrResourceBundleProvider getResourceResolver:
> ResourceResolverFactory is missing. Cannot create ResourceResolver
> 28.07.2015 09:37:49.804 *WARN* [Thread-36] org.apache.felix.eventadmin
> Service [org.apache.sling.i18n.impl.JcrResourceBundleProvider,160,
> [org.apache.sling.i18n.ResourceBundleProvider,
> org.osgi.service.event.EventHandler]] EventAdmin: Exception during event
> dispatch [org.osgi.service.event.Event
> [topic=org/apache/sling/api/resource/Resource/ADDED] |
> [org.apache.sling.i18n.ResourceBundleProvider,
> org.osgi.service.event.EventHandler] | Bundle(org.apache.sling.i18n [93])]
> (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at
> org.apache.sling.i18n.impl.JcrResourceBundle.refreshSession(JcrResourceBundle.java:98)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.isDictionaryResource(JcrResourceBundleProvider.java:250)
> at
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.handleEvent(JcrResourceBundleProvider.java:229)
> at
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)
> at
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks$1.run(SyncDeliverTasks.java:145)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4910) NPE in JCrResourceBundleProvider
Chetan Mehrotra created SLING-4910:
--
Summary: NPE in JCrResourceBundleProvider
Key: SLING-4910
URL: https://issues.apache.org/jira/browse/SLING-4910
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Chetan Mehrotra
Priority: Minor
Fix For: i18n 2.4.4
At fresh startup seeing couple of exceptions like below. Looks like by the time
events are delivered ResourceResolverFactory is still not set
(ResourceResolverFactory is missing. Cannot create ResourceResolver) which
later causes NPE.
{noformat}
28.07.2015 09:37:49.803 *ERROR* [Thread-36]
org.apache.sling.i18n.impl.JcrResourceBundleProvider getResourceResolver:
ResourceResolverFactory is missing. Cannot create ResourceResolver
28.07.2015 09:37:49.804 *WARN* [Thread-36] org.apache.felix.eventadmin Service
[org.apache.sling.i18n.impl.JcrResourceBundleProvider,160,
[org.apache.sling.i18n.ResourceBundleProvider,
org.osgi.service.event.EventHandler]] EventAdmin: Exception during event
dispatch [org.osgi.service.event.Event
[topic=org/apache/sling/api/resource/Resource/ADDED] |
[org.apache.sling.i18n.ResourceBundleProvider,
org.osgi.service.event.EventHandler] | Bundle(org.apache.sling.i18n [93])]
(java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.sling.i18n.impl.JcrResourceBundle.refreshSession(JcrResourceBundle.java:98)
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.isDictionaryResource(JcrResourceBundleProvider.java:250)
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.handleEvent(JcrResourceBundleProvider.java:229)
at
org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)
at
org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks$1.run(SyncDeliverTasks.java:145)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4908) Updated to latest WebConsole release
[ https://issues.apache.org/jira/browse/SLING-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4908. Resolution: Fixed > Updated to latest WebConsole release > > > Key: SLING-4908 > URL: https://issues.apache.org/jira/browse/SLING-4908 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Launchpad Builder 8 > > > We should update to the org.apache.felix.webconsole to 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4908) Updated to latest WebConsole release
[ https://issues.apache.org/jira/browse/SLING-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643824#comment-14643824 ] Chetan Mehrotra commented on SLING-4908: Thanks [~olli] for noticing that. I was testing out [~sseif...@pro-vision.de] changes for SLING-4726/FELIX-4710 which were marked for 4.2.6 so tested with that. Updated now to 4.2.10 with http://svn.apache.org/r1692985 > Updated to latest WebConsole release > > > Key: SLING-4908 > URL: https://issues.apache.org/jira/browse/SLING-4908 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Launchpad Builder 8 > > > We should update to the org.apache.felix.webconsole to 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4909) Add default log config to route request and access log to separate files
[ https://issues.apache.org/jira/browse/SLING-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4909. Resolution: Fixed Done in http://svn.apache.org/r1692868 > Add default log config to route request and access log to separate files > > > Key: SLING-4909 > URL: https://issues.apache.org/jira/browse/SLING-4909 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Launchpad Builder 8 > > > Currently all logging goes to error.log including the access and request > logging. This clutters the main log file. Launchpad should be shipped with > config to enable routing these logs to separate files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4909) Add default log config to route request and access log to separate files
[ https://issues.apache.org/jira/browse/SLING-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4909: --- Priority: Minor (was: Major) > Add default log config to route request and access log to separate files > > > Key: SLING-4909 > URL: https://issues.apache.org/jira/browse/SLING-4909 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Launchpad Builder 8 > > > Currently all logging goes to error.log including the access and request > logging. This clutters the main log file. Launchpad should be shipped with > config to enable routing these logs to separate files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4909) Add default log config to route request and access log to separate files
Chetan Mehrotra created SLING-4909: -- Summary: Add default log config to route request and access log to separate files Key: SLING-4909 URL: https://issues.apache.org/jira/browse/SLING-4909 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Launchpad Builder 8 Currently all logging goes to error.log including the access and request logging. This clutters the main log file. Launchpad should be shipped with config to enable routing these logs to separate files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4908) Updated to latest WebConsole release
[ https://issues.apache.org/jira/browse/SLING-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4908. Resolution: Fixed Done in http://svn.apache.org/r1692862 > Updated to latest WebConsole release > > > Key: SLING-4908 > URL: https://issues.apache.org/jira/browse/SLING-4908 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Launchpad Builder 8 > > > We should update to the org.apache.felix.webconsole to 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4908) Updated to latest WebConsole release
Chetan Mehrotra created SLING-4908: -- Summary: Updated to latest WebConsole release Key: SLING-4908 URL: https://issues.apache.org/jira/browse/SLING-4908 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Launchpad Builder 8 We should update to the org.apache.felix.webconsole to 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4906) Reduce (transitive) package dependencies
[ https://issues.apache.org/jira/browse/SLING-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4906. Resolution: Fixed Removed dep on javax.mail and javax.jms also with http://svn.apache.org/r1692841. If any one needs to make use of such Logback features then they can add a fragment package > Reduce (transitive) package dependencies > > > Key: SLING-4906 > URL: https://issues.apache.org/jira/browse/SLING-4906 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > It seems that updating innocent looking bundles cause the whole system to > restart. We now had a case where a bundle containing some package was > updated. This package was imported by the groovy bundle and the groovy bundle > was imported by the commons.log bundle. > Unfortunately, the log4j.api bundle - which is imported by nearly almost > every bundle - imports the impl package which is exported by the commons.log > bundle. > Obviously the best solution would be if the log4j.api bundle would not import > packages, but I guess that's not feasible the way log4j works. > Therefore we should have a look at our commons.log bundle to see whether we > can reduce the imports, or the effect of other bundles being updated -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4839) Allow to configure logger additivity via OSGi Config UI
[ https://issues.apache.org/jira/browse/SLING-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4839. Resolution: Fixed Done in http://svn.apache.org/r1692840 Both Log WebConsole plugin and OSGi config now provide support for configuring additivity > Allow to configure logger additivity via OSGi Config UI > --- > > Key: SLING-4839 > URL: https://issues.apache.org/jira/browse/SLING-4839 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.2 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 4.0.4 > > > While configuring the loggers via OSGi Commons Log sets the additivity to > false by default. Due to this logs from those categories are not routed to > main error log. This at times causes important exceptions from getting > noticed and hence might get missed out. > Commons Log does support controlling the additivity via OSGi config but that > setting is not exposed in UI. This setting should be exposed via UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3264) Integrate with Felix Inventory Support in Commons Log
[ https://issues.apache.org/jira/browse/SLING-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3264. Resolution: Not A Problem Requirement in SLING-4788 is met for now using overloaded method. So not much benefit in using newer API as WebConsole supports older approach also. > Integrate with Felix Inventory Support in Commons Log > -- > > Key: SLING-3264 > URL: https://issues.apache.org/jira/browse/SLING-3264 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > > The Commons Log expose some information as part of Configuration Printer. For > better support it should also integrate with Felix Inventory Feature [1] and > expose the internal runtime state. > Also it might be better to decouple dumping of Log file content. So it should > expose two printers. One to provide log file details and other to provide the > runtime state information > [1] > http://felix.apache.org/documentation/subprojects/apache-felix-inventory.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4906) Reduce (transitive) package dependencies
[
https://issues.apache.org/jira/browse/SLING-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642383#comment-14642383
]
Chetan Mehrotra commented on SLING-4906:
Remove Groovy related packages from import list with
http://svn.apache.org/r1692824. Now import list looks like
{noformat}
ch.qos.logback.classic{version=[1.1,2)}
ch.qos.logback.classic.encoder{version=[1.1,2)}
ch.qos.logback.classic.gaffer {version=[1.1,2)}
ch.qos.logback.classic.joran {version=[1.1,2)}
ch.qos.logback.classic.jul{version=[1.1,2)}
ch.qos.logback.classic.spi{version=[1.1,2)}
ch.qos.logback.classic.turbo {version=[1.1,2)}
ch.qos.logback.classic.util {version=[1.1,2)}
ch.qos.logback.core {version=[1.1,2)}
ch.qos.logback.core.encoder {version=[1.1,2)}
ch.qos.logback.core.filter{version=[1.1,2)}
ch.qos.logback.core.helpers {version=[1.1,2)}
ch.qos.logback.core.joran {version=[1.1,2)}
ch.qos.logback.core.joran.action {version=[1.1,2)}
ch.qos.logback.core.joran.event {version=[1.1,2)}
ch.qos.logback.core.joran.spi {version=[1.1,2)}
ch.qos.logback.core.pattern {version=[1.1,2)}
ch.qos.logback.core.rolling {version=[1.1,2)}
ch.qos.logback.core.spi {version=[1.1,2)}
ch.qos.logback.core.status{version=[1.1,2)}
ch.qos.logback.core.util {version=[1.1,2)}
javax.jms {resolution:=optional}
javax.mail{resolution:=optional}
javax.mail.internet {resolution:=optional}
javax.management {resolution:=optional}
javax.naming {resolution:=optional}
javax.net
javax.net.ssl
javax.sql {resolution:=optional}
javax.xml.namespace
javax.xml.parsers {resolution:=optional}
javax.xml.stream
javax.xml.stream.events
org.osgi.framework{version=1.3}
org.osgi.util.tracker {version=[1.4,2)}
org.slf4j {version=[1.6,1.8)}
org.slf4j.helpers {version=[1.6,2)}
org.slf4j.spi {version=[1.6,1.8)}
org.xml.sax {resolution:=optional}
org.xml.sax.helpers {resolution:=optional}
sun.reflect {resolution:=optional}
{noformat}
[~cziegeler] Should we prune above list further. May be javax.mail should also
be removed?
> Reduce (transitive) package dependencies
>
>
> Key: SLING-4906
> URL: https://issues.apache.org/jira/browse/SLING-4906
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> It seems that updating innocent looking bundles cause the whole system to
> restart. We now had a case where a bundle containing some package was
> updated. This package was imported by the groovy bundle and the groovy bundle
> was imported by the commons.log bundle.
> Unfortunately, the log4j.api bundle - which is imported by nearly almost
> every bundle - imports the impl package which is exported by the commons.log
> bundle.
> Obviously the best solution would be if the log4j.api bundle would not import
> packages, but I guess that's not feasible the way log4j works.
> Therefore we should have a look at our commons.log bundle to see whether we
> can reduce the imports, or the effect of other bundles being updated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4907) Provide support for registering Filter with all configured appenders
[
https://issues.apache.org/jira/browse/SLING-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-4907.
Resolution: Fixed
If the {{Filter}} {{appenders}} property is set {{*}} then that filter would be
registered against all Appenders
{code}
Dictionary props = new Hashtable();
props.put("appenders", "*");
ServiceRegistration sr =
bundleContext.registerService(Filter.class.getName(), stf, props);
{code}
Implemented in http://svn.apache.org/r1692823
> Provide support for registering Filter with all configured appenders
>
>
> Key: SLING-4907
> URL: https://issues.apache.org/jira/browse/SLING-4907
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> Current Logback support provides support for registering {{Filter}} as OSGi
> services [1]. This only supports registering against known appenders.
> If we need to have a logic which needs to handle/listen to all WARN and above
> log messages that needs to get logged then only way for now is to register a
> {{TurboFilter}} which has performance cost. To support such cases the
> {{Filter}} support should enable registering a Filter instance against all
> configured appenders. This would allow such a Filter to listen to all logged
> messages without the performance cost
> [1]
> https://sling.apache.org/documentation/development/logging.html#filters-as-osgi-services
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4906) Reduce (transitive) package dependencies
[ https://issues.apache.org/jira/browse/SLING-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642339#comment-14642339 ] Chetan Mehrotra commented on SLING-4906: Somehow I had a misunderstanding that a bundle would only be able to import packages from bundle at its own start level or level below. Hence I went all the way to SLING-3814 to ensure that Commons Log uses Groovy which is not susceptible to such transitive imports. However that understanding is wrong as a system package refresh done at any later time would wire the optional dependency from bundles at lower start level. So safe solution would be to remove such optional imports altogether! > Reduce (transitive) package dependencies > > > Key: SLING-4906 > URL: https://issues.apache.org/jira/browse/SLING-4906 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > It seems that updating innocent looking bundles cause the whole system to > restart. We now had a case where a bundle containing some package was > updated. This package was imported by the groovy bundle and the groovy bundle > was imported by the commons.log bundle. > Unfortunately, the log4j.api bundle - which is imported by nearly almost > every bundle - imports the impl package which is exported by the commons.log > bundle. > Obviously the best solution would be if the log4j.api bundle would not import > packages, but I guess that's not feasible the way log4j works. > Therefore we should have a look at our commons.log bundle to see whether we > can reduce the imports, or the effect of other bundles being updated -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4907) Provide support for registering Filter with all configured appenders
Chetan Mehrotra created SLING-4907:
--
Summary: Provide support for registering Filter with all
configured appenders
Key: SLING-4907
URL: https://issues.apache.org/jira/browse/SLING-4907
Project: Sling
Issue Type: Improvement
Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: Commons Log 4.0.4
Current Logback support provides support for registering {{Filter}} as OSGi
services [1]. This only supports registering against known appenders.
If we need to have a logic which needs to handle/listen to all WARN and above
log messages that needs to get logged then only way for now is to register a
{{TurboFilter}} which has performance cost. To support such cases the
{{Filter}} support should enable registering a Filter instance against all
configured appenders. This would allow such a Filter to listen to all logged
messages without the performance cost
[1]
https://sling.apache.org/documentation/development/logging.html#filters-as-osgi-services
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4906) Reduce (transitive) package dependencies
[
https://issues.apache.org/jira/browse/SLING-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642326#comment-14642326
]
Chetan Mehrotra commented on SLING-4906:
[~cziegeler] when you say
{quote}
Unfortunately, the log4j.api bundle - which is imported by nearly almost every
bundle - imports the impl package which is exported by the commons.log bundle.
{quote}
Did you meant slf4j.api bundle?. If yes then yes by design it has to import
those packages from commons log
> Reduce (transitive) package dependencies
>
>
> Key: SLING-4906
> URL: https://issues.apache.org/jira/browse/SLING-4906
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> It seems that updating innocent looking bundles cause the whole system to
> restart. We now had a case where a bundle containing some package was
> updated. This package was imported by the groovy bundle and the groovy bundle
> was imported by the commons.log bundle.
> Unfortunately, the log4j.api bundle - which is imported by nearly almost
> every bundle - imports the impl package which is exported by the commons.log
> bundle.
> Obviously the best solution would be if the log4j.api bundle would not import
> packages, but I guess that's not feasible the way log4j works.
> Therefore we should have a look at our commons.log bundle to see whether we
> can reduce the imports, or the effect of other bundles being updated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4906) Reduce (transitive) package dependencies
[
https://issues.apache.org/jira/browse/SLING-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642324#comment-14642324
]
Chetan Mehrotra commented on SLING-4906:
Below is the current import list
{noformat}
ch.qos.logback.classic{version=[1.1,2)}
ch.qos.logback.classic.encoder{version=[1.1,2)}
ch.qos.logback.classic.gaffer {version=[1.1,2)}
ch.qos.logback.classic.joran {version=[1.1,2)}
ch.qos.logback.classic.jul{version=[1.1,2)}
ch.qos.logback.classic.spi{version=[1.1,2)}
ch.qos.logback.classic.turbo {version=[1.1,2)}
ch.qos.logback.classic.util {version=[1.1,2)}
ch.qos.logback.core {version=[1.1,2)}
ch.qos.logback.core.encoder {version=[1.1,2)}
ch.qos.logback.core.filter{version=[1.1,2)}
ch.qos.logback.core.helpers {version=[1.1,2)}
ch.qos.logback.core.joran {version=[1.1,2)}
ch.qos.logback.core.joran.action {version=[1.1,2)}
ch.qos.logback.core.joran.event {version=[1.1,2)}
ch.qos.logback.core.joran.spi {version=[1.1,2)}
ch.qos.logback.core.pattern {version=[1.1,2)}
ch.qos.logback.core.rolling {version=[1.1,2)}
ch.qos.logback.core.spi {version=[1.1,2)}
ch.qos.logback.core.status{version=[1.1,2)}
ch.qos.logback.core.util {version=[1.1,2)}
groovy.lang {resolution:=optional}
javax.jms {resolution:=optional}
javax.mail{resolution:=optional}
javax.mail.internet {resolution:=optional}
javax.management {resolution:=optional}
javax.naming {resolution:=optional}
javax.net
javax.net.ssl
javax.sql {resolution:=optional}
javax.xml.namespace
javax.xml.parsers {resolution:=optional}
javax.xml.stream
javax.xml.stream.events
org.codehaus.commons.compiler {resolution:=optional}
org.codehaus.groovy.control {resolution:=optional}
org.codehaus.groovy.control.customizers{resolution:=optional}
org.codehaus.groovy.reflection{resolution:=optional}
org.codehaus.groovy.runtime {resolution:=optional}
org.codehaus.groovy.runtime.callsite {resolution:=optional}
org.codehaus.groovy.runtime.typehandling{resolution:=optional}
org.codehaus.groovy.runtime.wrappers {resolution:=optional}
org.codehaus.janino {resolution:=optional}
org.osgi.framework{version=1.3}
org.osgi.util.tracker {version=[1.4,2)}
org.slf4j {version=[1.6,1.8)}
org.slf4j.helpers {version=[1.6,2)}
org.slf4j.spi {version=[1.6,1.8)}
org.xml.sax {resolution:=optional}
org.xml.sax.helpers {resolution:=optional}
sun.reflect {resolution:=optional}
{noformat}
So based on above we should not have imports for as others are system packages
so safe to have imports
* groovy.lang
* org.codehaus.groovy.*
> Reduce (transitive) package dependencies
>
>
> Key: SLING-4906
> URL: https://issues.apache.org/jira/browse/SLING-4906
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> It seems that updating innocent looking bundles cause the whole system to
> restart. We now had a case where a bundle containing some package was
> updated. This package was imported by the groovy bundle and the groovy bundle
> was imported by the commons.log bundle.
> Unfortunately, the log4j.api bundle - which is imported by nearly almost
> every bundle - imports the impl package which is exported by the commons.log
> bundle.
> Obviously the best solution would be if the log4j.api bundle would not import
> packages, but I guess that's not feasible the way log4j works.
> Therefore we should have a look at our commons.log bundle to see whether we
> can reduce the imports, or the effect of other bundles being updated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4906) Reduce (transitive) package dependencies
[ https://issues.apache.org/jira/browse/SLING-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned SLING-4906: -- Assignee: Chetan Mehrotra > Reduce (transitive) package dependencies > > > Key: SLING-4906 > URL: https://issues.apache.org/jira/browse/SLING-4906 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > It seems that updating innocent looking bundles cause the whole system to > restart. We now had a case where a bundle containing some package was > updated. This package was imported by the groovy bundle and the groovy bundle > was imported by the commons.log bundle. > Unfortunately, the log4j.api bundle - which is imported by nearly almost > every bundle - imports the impl package which is exported by the commons.log > bundle. > Obviously the best solution would be if the log4j.api bundle would not import > packages, but I guess that's not feasible the way log4j works. > Therefore we should have a look at our commons.log bundle to see whether we > can reduce the imports, or the effect of other bundles being updated -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4905) Log WebConsole Plugin should provide link to actual log file
[
https://issues.apache.org/jira/browse/SLING-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642314#comment-14642314
]
Chetan Mehrotra edited comment on SLING-4905 at 7/27/15 6:07 AM:
-
Log panel now generates and supports links like
http://localhost:8080/system/console/slinglog/?tail=
Where
* Appender name - Names would be like _/logs/error.log_
* tail - Number of lines to include in dump. -1 to include whole file. Feature
is based on SLING-4904
{noformat}
http://localhost:8080/system/console/slinglog/%2Flogs%2Ferror.log?tail=100
{noformat}
Implemented in http://svn.apache.org/r1692812
was (Author: chetanm):
Log panel now generates and supports links like
bq. http://localhost:8989/system/console/slinglog/?tail=
Where
* Appender name - Names would be like _/logs/error.log_
* tail - Number of lines to include in dump. -1 to include whole file. Feature
is based on SLING-4904
{noformat}
http://localhost:8989/system/console/slinglog/%2Flogs%2Ferror.log?tail=100
{noformat}
Implemented in http://svn.apache.org/r1692812
> Log WebConsole Plugin should provide link to actual log file
>
>
> Key: SLING-4905
> URL: https://issues.apache.org/jira/browse/SLING-4905
> Project: Sling
> Issue Type: New Feature
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> Currently the Sling Log Panel (Log component WebConsole Plugin) just provide
> listing of active log files. There is a config printer which dumps content of
> all active log file. It would be better if one can direct access log file
> content of specific file. Also in doing that it should be possible to specify
> how many line should be included
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4905) Log WebConsole Plugin should provide link to actual log file
[
https://issues.apache.org/jira/browse/SLING-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-4905.
Resolution: Fixed
Log panel now generates and supports links like
bq. http://localhost:8989/system/console/slinglog/?tail=
Where
* Appender name - Names would be like _/logs/error.log_
* tail - Number of lines to include in dump. -1 to include whole file. Feature
is based on SLING-4904
{noformat}
http://localhost:8989/system/console/slinglog/%2Flogs%2Ferror.log?tail=100
{noformat}
Implemented in http://svn.apache.org/r1692812
> Log WebConsole Plugin should provide link to actual log file
>
>
> Key: SLING-4905
> URL: https://issues.apache.org/jira/browse/SLING-4905
> Project: Sling
> Issue Type: New Feature
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> Currently the Sling Log Panel (Log component WebConsole Plugin) just provide
> listing of active log files. There is a config printer which dumps content of
> all active log file. It would be better if one can direct access log file
> content of specific file. Also in doing that it should be possible to specify
> how many line should be included
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4905) Log WebConsole Plugin should provide link to actual log file
Chetan Mehrotra created SLING-4905: -- Summary: Log WebConsole Plugin should provide link to actual log file Key: SLING-4905 URL: https://issues.apache.org/jira/browse/SLING-4905 Project: Sling Issue Type: New Feature Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Commons Log 4.0.4 Currently the Sling Log Panel (Log component WebConsole Plugin) just provide listing of active log files. There is a config printer which dumps content of all active log file. It would be better if one can direct access log file content of specific file. Also in doing that it should be possible to specify how many line should be included -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4904) Log Config printer should only dump last 'n' lines of the logs
[ https://issues.apache.org/jira/browse/SLING-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4904. Resolution: Fixed > Log Config printer should only dump last 'n' lines of the logs > -- > > Key: SLING-4904 > URL: https://issues.apache.org/jira/browse/SLING-4904 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 4.0.4 > > > SlingConfigurationPrinter in text mode it should only list the log files > available, and only include a a tail of the last n lines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4904) Log Config printer should only dump last 'n' lines of the logs
[
https://issues.apache.org/jira/browse/SLING-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641441#comment-14641441
]
Chetan Mehrotra commented on SLING-4904:
Added new config property {{org.apache.sling.commons.log.numOfLines}} which
defaults to 1000. If set to -1 then whole file would be included in the status
report in txt mode/
Support added in http://svn.apache.org/r1692605
> Log Config printer should only dump last 'n' lines of the logs
> --
>
> Key: SLING-4904
> URL: https://issues.apache.org/jira/browse/SLING-4904
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Log 4.0.4
>
>
> SlingConfigurationPrinter in text mode it should only list the log files
> available, and only include a a tail of the last n lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[ https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641406#comment-14641406 ] Chetan Mehrotra commented on SLING-4788: Opened SLING-4904 to track support for including only last 'n' lines in txt output > SlingConfigurationPrinter should use mode aware and only stream the full logs > in the zip version and avoid duplicate information > > > Key: SLING-4788 > URL: https://issues.apache.org/jira/browse/SLING-4788 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > Currently the SlingConfigurationPrinter is not mode aware, it produce a log > files.txt that contains / combine all the logs in one, which is an issue when > there are really a lot of logs and large. > Also the zip version will contains then both output once combined and once as > log attached. > To improve this it would be easier to use the mode aware interface > ModeAwareConfigurationPrinter, and define different output style. > In text mode it should only list the log files available, a tail of the last > n lines could be added. > In zip mode, it should then attache the logs, eventually an option to only > add logs that are n days old or n lines , to avoid too large zip files which > can also sometime be a problem when trying to analyze a recent issue. > I did a quick test based on the current release and that is possible to > achieve at least the mode awareness. > [~cziegeler] Can you check if that can be done for a future release of common > logs ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[ https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4788. Resolution: Fixed Fix Version/s: Commons Log 4.0.4 > SlingConfigurationPrinter should use mode aware and only stream the full logs > in the zip version and avoid duplicate information > > > Key: SLING-4788 > URL: https://issues.apache.org/jira/browse/SLING-4788 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > Currently the SlingConfigurationPrinter is not mode aware, it produce a log > files.txt that contains / combine all the logs in one, which is an issue when > there are really a lot of logs and large. > Also the zip version will contains then both output once combined and once as > log attached. > To improve this it would be easier to use the mode aware interface > ModeAwareConfigurationPrinter, and define different output style. > In text mode it should only list the log files available, a tail of the last > n lines could be added. > In zip mode, it should then attache the logs, eventually an option to only > add logs that are n days old or n lines , to avoid too large zip files which > can also sometime be a problem when trying to analyze a recent issue. > I did a quick test based on the current release and that is possible to > achieve at least the mode awareness. > [~cziegeler] Can you check if that can be done for a future release of common > logs ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4904) Log Config printer should only dump last 'n' lines of the logs
Chetan Mehrotra created SLING-4904: -- Summary: Log Config printer should only dump last 'n' lines of the logs Key: SLING-4904 URL: https://issues.apache.org/jira/browse/SLING-4904 Project: Sling Issue Type: Improvement Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Commons Log 4.0.4 SlingConfigurationPrinter in text mode it should only list the log files available, and only include a a tail of the last n lines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4903) ConcurrentModificationException in MapEntries
[
https://issues.apache.org/jira/browse/SLING-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640507#comment-14640507
]
Chetan Mehrotra commented on SLING-4903:
No instead of cloning just create a new list like {{ List
entriesCopy =new ArrayList(entries);}} and replaced the entry in
entryMap like below
{code}
/**
* Add an entry to the resolve map.
*/
private boolean addEntry(final Map> entryMap, final
String key, final MapEntry entry) {
if (entry==null){
return false;
}
List entries = entryMap.get(key);
if (entries == null) {
entries = new ArrayList();
entries.add(entry);
// and finally sort list
Collections.sort(entries);
entryMap.put(key, entries);
} else {
List entriesCopy =new ArrayList(entries);
entriesCopy.add(entry);
// and finally sort list
Collections.sort( entriesCopy);
entryMap.put(key, entriesCopy);
}
return true;
}
{code}
> ConcurrentModificationException in MapEntries
> -
>
> Key: SLING-4903
> URL: https://issues.apache.org/jira/browse/SLING-4903
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4883-patch.txt, SLING-4883-test-patch.txt
>
>
> {code}
> org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
> Throwable java.util.ConcurrentModificationException: null
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
> at java.util.ArrayList$Itr.next(ArrayList.java:831)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.seek(MapEntries.jav
> a:1499)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.next(MapEntries.jav
> a:1450)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.next(MapEntries.jav
> a:1411)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolveInternal(ResourceResolverIm
> pl.java:251)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolve(ResourceResolverImpl.java:
> 192)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4903) ConcurrentModificationException in MapEntries
[
https://issues.apache.org/jira/browse/SLING-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640388#comment-14640388
]
Chetan Mehrotra commented on SLING-4903:
If the write is not concurrent i.e. 2 thread writing to the list at same time
then instead of using CopyOnWriteArrayList you can just clone existing list
(copy content to new) and then replace the entry in the map with new sorted
list. This would ensure list is not modified while an iterator is opened
> ConcurrentModificationException in MapEntries
> -
>
> Key: SLING-4903
> URL: https://issues.apache.org/jira/browse/SLING-4903
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4883-patch.txt, SLING-4883-test-patch.txt
>
>
> {code}
> org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
> Throwable java.util.ConcurrentModificationException: null
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
> at java.util.ArrayList$Itr.next(ArrayList.java:831)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.seek(MapEntries.jav
> a:1499)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.next(MapEntries.jav
> a:1450)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.next(MapEntries.jav
> a:1411)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolveInternal(ResourceResolverIm
> pl.java:251)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolve(ResourceResolverImpl.java:
> 192)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-2884) [Log] Improvements to Web Console plugins
[ https://issues.apache.org/jira/browse/SLING-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-2884. Resolution: Fixed Assignee: Chetan Mehrotra Fix Version/s: Commons Log 4.0.4 Most part done. Tailing requirement being tracked in SLING-4897 > [Log] Improvements to Web Console plugins > - > > Key: SLING-2884 > URL: https://issues.apache.org/jira/browse/SLING-2884 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 3.0.0 >Reporter: Felix Meschberger >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > The current Web Console plugins of the Commons Log bundles show some > defficiencies IMHO: > (1) The Configuration Printer writes back all active log files in the > printConfiguration method. Probably it should not return the file contents > but just a list of active and rotated log files along with their sizes and > probably last modification time. (The getAttachments method is correct in > adding all active and rotated log files to the ZIP) > (2) The Web Console Plugin should not list the absolute path names of the log > files but the path names from the original configuration. This might require > a new SlingLoggerWriter.getName() method which returns the configured file > name. > (3) The Web Console Plugin should be extended to: > (3a) allow looking at a log file (maybe "trailing" it ?) > (3b) remove single log files > (3c) remove rotated log files: single, all, by age -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-2884) [Log] Improvements to Web Console plugins
[
https://issues.apache.org/jira/browse/SLING-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640351#comment-14640351
]
Chetan Mehrotra commented on SLING-2884:
{quote}
(1) The Configuration Printer writes back all active log files in the
printConfiguration method. Probably it should not return the file contents but
just a list of active and rotated log files along with their sizes and probably
last modification time. (The getAttachments method is correct in adding all
active and rotated log files to the ZIP)
(2) The Web Console Plugin should not list the absolute path names of the log
files but the path names from the original configuration. This might require a
new SlingLoggerWriter.getName() method which returns the configured file name.
{quote}
Done as part of SLING-4788 in http://svn.apache.org/r1692481
{quote}
(3) The Web Console Plugin should be extended to:
(3a) allow looking at a log file (maybe "trailing" it ?)
{quote}
Tracked via SLING-4897
> [Log] Improvements to Web Console plugins
> -
>
> Key: SLING-2884
> URL: https://issues.apache.org/jira/browse/SLING-2884
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 3.0.0
>Reporter: Felix Meschberger
>
> The current Web Console plugins of the Commons Log bundles show some
> defficiencies IMHO:
> (1) The Configuration Printer writes back all active log files in the
> printConfiguration method. Probably it should not return the file contents
> but just a list of active and rotated log files along with their sizes and
> probably last modification time. (The getAttachments method is correct in
> adding all active and rotated log files to the ZIP)
> (2) The Web Console Plugin should not list the absolute path names of the log
> files but the path names from the original configuration. This might require
> a new SlingLoggerWriter.getName() method which returns the configured file
> name.
> (3) The Web Console Plugin should be extended to:
> (3a) allow looking at a log file (maybe "trailing" it ?)
> (3b) remove single log files
> (3c) remove rotated log files: single, all, by age
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[
https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640349#comment-14640349
]
Chetan Mehrotra commented on SLING-4788:
Added support for limiting the number of rolled over files in the zip. This can
be controlled via {{org.apache.sling.commons.log.maxOldFileCountInDump}} prop
and defaults to 3
http://svn.apache.org/r1692482
> SlingConfigurationPrinter should use mode aware and only stream the full logs
> in the zip version and avoid duplicate information
>
>
> Key: SLING-4788
> URL: https://issues.apache.org/jira/browse/SLING-4788
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2
>Reporter: Thierry Ygé
>Assignee: Chetan Mehrotra
>
> Currently the SlingConfigurationPrinter is not mode aware, it produce a log
> files.txt that contains / combine all the logs in one, which is an issue when
> there are really a lot of logs and large.
> Also the zip version will contains then both output once combined and once as
> log attached.
> To improve this it would be easier to use the mode aware interface
> ModeAwareConfigurationPrinter, and define different output style.
> In text mode it should only list the log files available, a tail of the last
> n lines could be added.
> In zip mode, it should then attache the logs, eventually an option to only
> add logs that are n days old or n lines , to avoid too large zip files which
> can also sometime be a problem when trying to analyze a recent issue.
> I did a quick test based on the current release and that is possible to
> achieve at least the mode awareness.
> [~cziegeler] Can you check if that can be done for a future release of common
> logs ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[ https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640346#comment-14640346 ] Chetan Mehrotra commented on SLING-4788: For now I worked around dependency on inventory api by changing the method signature to (printWriter, mode). With that change the config printer would not dump file content twice. http://svn.apache.org/r1692481 > SlingConfigurationPrinter should use mode aware and only stream the full logs > in the zip version and avoid duplicate information > > > Key: SLING-4788 > URL: https://issues.apache.org/jira/browse/SLING-4788 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra > > Currently the SlingConfigurationPrinter is not mode aware, it produce a log > files.txt that contains / combine all the logs in one, which is an issue when > there are really a lot of logs and large. > Also the zip version will contains then both output once combined and once as > log attached. > To improve this it would be easier to use the mode aware interface > ModeAwareConfigurationPrinter, and define different output style. > In text mode it should only list the log files available, a tail of the last > n lines could be added. > In zip mode, it should then attache the logs, eventually an option to only > add logs that are n days old or n lines , to avoid too large zip files which > can also sometime be a problem when trying to analyze a recent issue. > I did a quick test based on the current release and that is possible to > achieve at least the mode awareness. > [~cziegeler] Can you check if that can be done for a future release of common > logs ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[ https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4788: --- Priority: Major (was: Minor) > SlingConfigurationPrinter should use mode aware and only stream the full logs > in the zip version and avoid duplicate information > > > Key: SLING-4788 > URL: https://issues.apache.org/jira/browse/SLING-4788 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra > > Currently the SlingConfigurationPrinter is not mode aware, it produce a log > files.txt that contains / combine all the logs in one, which is an issue when > there are really a lot of logs and large. > Also the zip version will contains then both output once combined and once as > log attached. > To improve this it would be easier to use the mode aware interface > ModeAwareConfigurationPrinter, and define different output style. > In text mode it should only list the log files available, a tail of the last > n lines could be added. > In zip mode, it should then attache the logs, eventually an option to only > add logs that are n days old or n lines , to avoid too large zip files which > can also sometime be a problem when trying to analyze a recent issue. > I did a quick test based on the current release and that is possible to > achieve at least the mode awareness. > [~cziegeler] Can you check if that can be done for a future release of common > logs ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3421) logback initialization does not initialize correct loggers if there's a single false one
[
https://issues.apache.org/jira/browse/SLING-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-3421.
Resolution: Fixed
Fix Version/s: Commons Log 4.0.4
Fixed with http://svn.apache.org/r1692244. In case of any error in pattern a
default pattern would be used
> logback initialization does not initialize correct loggers if there's a
> single false one
>
>
> Key: SLING-3421
> URL: https://issues.apache.org/jira/browse/SLING-3421
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> If you configure a logger wrongly, which eg results in this stacktrace:
> {code}
> 2014-02-28 11:59:17  ERROR  LogbackManager  Error occurred while configuring
> Logback
> java.lang.IllegalArgumentException: Cannot format given Object as a Date
> at java.text.DateFormat.format(DateFormat.java:281)
> at java.text.Format.format(Format.java:140)
> at java.text.MessageFormat.subformat(MessageFormat.java:1288)
> at java.text.MessageFormat.format(MessageFormat.java:836)
> at java.text.Format.format(Format.java:140)
> at java.text.MessageFormat.format(MessageFormat.java:812)
> at
> org.apache.sling.commons.log.logback.internal.LogConfig.createLayout(LogConfig.java:124)
> at
> org.apache.sling.commons.log.logback.internal.util.LoggerSpecificEncoder.addLogConfig(LoggerSpecificEncoder.java:72)
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.onResetComplete(LogConfigManager.java:283)
> at
> org.apache.sling.commons.log.logback.internal.LogbackManager.fireResetCompleteListeners(LogbackManager.java:266)
> at
> org.apache.sling.commons.log.logback.internal.OsgiInternalAction$ConfigCompleteListener.inPlay(OsgiInternalAction.java:158)
> at
> ch.qos.logback.core.joran.spi.InterpretationContext.fireInPlay(InterpretationContext.java:183)
> at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:61)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:149)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:99)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:49)
> at
> org.apache.sling.commons.log.logback.internal.LogbackManager$DefaultCallback.perform(LogbackManager.java:574)
> at
> org.apache.sling.commons.log.logback.internal.LogbackManager.configure(LogbackManager.java:322)
> at
> org.apache.sling.commons.log.logback.internal.LogbackManager.configure(LogbackManager.java:303)
> at
> org.apache.sling.commons.log.logback.internal.LogbackManager.access$200(LogbackManager.java:51)
> at
> org.apache.sling.commons.log.logback.internal.LogbackManager$1.run(LogbackManager.java:251)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> {code}
> logback initialization stops completely and no other logger will be honored.
> I think the logback initialization should continue and just mark the failing
> one prominently, instead of completely stopping.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-2458) Sling Embedded JCR repository integration
[ https://issues.apache.org/jira/browse/SLING-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-2458. Resolution: Incomplete > Sling Embedded JCR repository integration > - > > Key: SLING-2458 > URL: https://issues.apache.org/jira/browse/SLING-2458 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Maven Sling Plugin 2.1.0 > Environment: Windows 7 - Tomcat 7 - Hippo CMS - Apache Sling >Reporter: Mi >Priority: Minor > > Hello, > I am trying to use apache sling as an templating framework in front of Hippo > CMS (also uses JCR) so normally it should be possible to integrate Hippo CMS > with Sling I guess. > So what I did is in the configuration of Sling configured : Apache Sling > Embedded JCR Repository: > And i changed the values to: > Config file : > file://C:/java/appserver/apache-tomcat-7.0.6/conf/repository.xml > Repository home: C:\java\appserver\apache-tomcat-7.0.6\webapps\cms\storage > (If I change this to not the one that Hippo CMS is using everything is OK ) > Embedded JCR Repository Name : repositoryDS > Default workspace : default > .. > Aministrator : admin > Admin pwd : admin > And the other values remained the same. > Now when I try to get content or post content I get this error ( Unless as > described above , if I change the Repo home.) > The requested service (AuthenticationSupport service missing. Cannot > authenticate request.) is not currently available. > Can someone help me ? > Am I using the correct parameters ? Am I forgetting somehting or can someone > explain in more dept what I should put in ( in the values above). > thanks ! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4764) ClassCastException when trying to modify properties in custom appender Service
[ https://issues.apache.org/jira/browse/SLING-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4764. Resolution: Fixed Fix Version/s: Commons Log 4.0.4 Fixed along with testcase in http://svn.apache.org/r1692236 > ClassCastException when trying to modify properties in custom appender Service > -- > > Key: SLING-4764 > URL: https://issues.apache.org/jira/browse/SLING-4764 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.2, Commons Log 4.0.4 >Reporter: Andrey Bardashevsky >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > Exception: > java.lang.ClassCastException: > org.apache.sling.commons.log.logback.internal.AppenderTracker$AppenderInfo > cannot be cast to ch.qos.logback.core.Appender > at > org.apache.sling.commons.log.logback.internal.AppenderTracker.modifiedService(AppenderTracker.java:78) > Solution: > org.apache.sling.commons.log.logback.internal.AppenderTracker#addingService > should return Appender (a) instead of AppenderInfo (ai) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-1800) change default test urls to use port 8080
[ https://issues.apache.org/jira/browse/SLING-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-1800. Resolution: Won't Fix Opened long time ago and requirement not defined. Closing as Wont Fix > change default test urls to use port 8080 > - > > Key: SLING-1800 > URL: https://issues.apache.org/jira/browse/SLING-1800 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Justin Edelson >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4764) ClassCastException when trying to modify properties in custom appender Service
[ https://issues.apache.org/jira/browse/SLING-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned SLING-4764: -- Assignee: Chetan Mehrotra > ClassCastException when trying to modify properties in custom appender Service > -- > > Key: SLING-4764 > URL: https://issues.apache.org/jira/browse/SLING-4764 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.2, Commons Log 4.0.4 >Reporter: Andrey Bardashevsky >Assignee: Chetan Mehrotra > > Exception: > java.lang.ClassCastException: > org.apache.sling.commons.log.logback.internal.AppenderTracker$AppenderInfo > cannot be cast to ch.qos.logback.core.Appender > at > org.apache.sling.commons.log.logback.internal.AppenderTracker.modifiedService(AppenderTracker.java:78) > Solution: > org.apache.sling.commons.log.logback.internal.AppenderTracker#addingService > should return Appender (a) instead of AppenderInfo (ai) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[ https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636398#comment-14636398 ] Chetan Mehrotra commented on SLING-4788: [~cziegeler] I had earlier thought about using new inventory api [1] but was not sure about adding dependency (even optional) on Inventory API bundle which starts at higher level would be a good idea. Can we still achieve above requirements without depending on new inventory API [1] http://felix.apache.org/documentation/subprojects/apache-felix-inventory.html > SlingConfigurationPrinter should use mode aware and only stream the full logs > in the zip version and avoid duplicate information > > > Key: SLING-4788 > URL: https://issues.apache.org/jira/browse/SLING-4788 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra >Priority: Minor > > Currently the SlingConfigurationPrinter is not mode aware, it produce a log > files.txt that contains / combine all the logs in one, which is an issue when > there are really a lot of logs and large. > Also the zip version will contains then both output once combined and once as > log attached. > To improve this it would be easier to use the mode aware interface > ModeAwareConfigurationPrinter, and define different output style. > In text mode it should only list the log files available, a tail of the last > n lines could be added. > In zip mode, it should then attache the logs, eventually an option to only > add logs that are n days old or n lines , to avoid too large zip files which > can also sometime be a problem when trying to analyze a recent issue. > I did a quick test based on the current release and that is possible to > achieve at least the mode awareness. > [~cziegeler] Can you check if that can be done for a future release of common > logs ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4788) SlingConfigurationPrinter should use mode aware and only stream the full logs in the zip version and avoid duplicate information
[ https://issues.apache.org/jira/browse/SLING-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned SLING-4788: -- Assignee: Chetan Mehrotra > SlingConfigurationPrinter should use mode aware and only stream the full logs > in the zip version and avoid duplicate information > > > Key: SLING-4788 > URL: https://issues.apache.org/jira/browse/SLING-4788 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.0, Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra >Priority: Minor > > Currently the SlingConfigurationPrinter is not mode aware, it produce a log > files.txt that contains / combine all the logs in one, which is an issue when > there are really a lot of logs and large. > Also the zip version will contains then both output once combined and once as > log attached. > To improve this it would be easier to use the mode aware interface > ModeAwareConfigurationPrinter, and define different output style. > In text mode it should only list the log files available, a tail of the last > n lines could be added. > In zip mode, it should then attache the logs, eventually an option to only > add logs that are n days old or n lines , to avoid too large zip files which > can also sometime be a problem when trying to analyze a recent issue. > I did a quick test based on the current release and that is possible to > achieve at least the mode awareness. > [~cziegeler] Can you check if that can be done for a future release of common > logs ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4875) Enhance the SlingConfigurationPrinter for better handling of large logs
[ https://issues.apache.org/jira/browse/SLING-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-4875. Resolution: Duplicate [~petitbear68] I think this issue is duplicate of SLING-4788 logged earlier by you. For now I am closing this. Let me know if you think its a different issue > Enhance the SlingConfigurationPrinter for better handling of large logs > --- > > Key: SLING-4875 > URL: https://issues.apache.org/jira/browse/SLING-4875 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.2 >Reporter: Thierry Ygé > > Currently it often happen that the configuration status zip fail to create > (truncated zip is generated). > Most of the time it is due to large logs being added in the status. > There already the problem that logs are added "twice", once as txt in the > zip, and once as attachments, the first one must be the cause of the issues. > It would help to: > 1. only add the logs as attachment > 2. remove the "txt" version of the printed logs combined in one super large > file > 3. define a filter so that only recent logs are included and that any old > rotation are skipped (large logs could be scanned to tail only the recent > part like 1 day old , 2 day etc.. as configurable setting). > The class is located here: > http://svn.apache.org/viewvc/sling/trunk/bundles/commons/log/src/main/java/org/apache/sling/commons/log/logback/internal/SlingConfigurationPrinter.java?revision=1670022&view=markup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4875) Enhance the SlingConfigurationPrinter for better handling of large logs
[ https://issues.apache.org/jira/browse/SLING-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned SLING-4875: -- Assignee: Chetan Mehrotra > Enhance the SlingConfigurationPrinter for better handling of large logs > --- > > Key: SLING-4875 > URL: https://issues.apache.org/jira/browse/SLING-4875 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Log 4.0.2 >Reporter: Thierry Ygé >Assignee: Chetan Mehrotra > > Currently it often happen that the configuration status zip fail to create > (truncated zip is generated). > Most of the time it is due to large logs being added in the status. > There already the problem that logs are added "twice", once as txt in the > zip, and once as attachments, the first one must be the cause of the issues. > It would help to: > 1. only add the logs as attachment > 2. remove the "txt" version of the printed logs combined in one super large > file > 3. define a filter so that only recent logs are included and that any old > rotation are skipped (large logs could be scanned to tail only the recent > part like 1 day old , 2 day etc.. as configurable setting). > The class is located here: > http://svn.apache.org/viewvc/sling/trunk/bundles/commons/log/src/main/java/org/apache/sling/commons/log/logback/internal/SlingConfigurationPrinter.java?revision=1670022&view=markup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-2622) Framework does not log through the Sling Logging Infrastructure
[ https://issues.apache.org/jira/browse/SLING-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636391#comment-14636391 ] Chetan Mehrotra commented on SLING-2622: [~cziegeler] [~bosschaert] Would it be possible to implement this? Any pointers on that, otherwise we can close this issue > Framework does not log through the Sling Logging Infrastructure > --- > > Key: SLING-2622 > URL: https://issues.apache.org/jira/browse/SLING-2622 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log Service 1.0.0, Commons Log 3.0.0 >Reporter: Felix Meschberger > > When raising the log level to DEBUG on startup, the framework emits a lot of > logging. Unfortunately this log goes to stdout instead of through the Sling > Logging Infrastructure (probably the LogService would be good to use). > This prevents capturing these messages for support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3340) Warnings on startup regarding no-op loggers
[
https://issues.apache.org/jira/browse/SLING-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-3340.
Resolution: Fixed
Issue was fixed via update of Slf4j dependency. No change performed in Commons
Log
> Warnings on startup regarding no-op loggers
> ---
>
> Key: SLING-3340
> URL: https://issues.apache.org/jira/browse/SLING-3340
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 4.0.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> Depening on the order in which bundles are installed Slf4j might use NoOp
> loggers for loggers created before Logback is initialized. One would see a
> warning log like below
> {noformat}
> Slf4j is not initialized yet. Delaying Logback support initialization
> SLF4J: The following loggers will not work because they were created
> SLF4J: during the default configuration phase of the underlying logging
> system.
> SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.sling.commons.logservice
> SLF4J: org.apache.sling.installer.core
> SLF4J: org.apache.sling.installer.core.impl.OsgiInstallerImpl
> SLF4J: org.apache.sling.audit.osgi.installer
> SLF4J: org.apache.sling.installer.core.impl.PersistentResourceList
> SLF4J: org.apache.sling.installer.core.impl.EntityResourceList
> SLF4J: org.apache.sling.installer.core.impl.tasks.BundleTaskCreator
> SLF4J: org.apache.sling.installer.core.impl.DefaultTransformer
> SLF4J: org.apache.sling.installer.provider.file
> SLF4J: org.apache.sling.installer.provider.file.impl.ServicesListener
> SLF4J: org.apache.sling.installer.provider.file.impl.FileInstaller
> SLF4J: org.apache.sling.javax.activation
> SLF4J: org.apache.sling.javax.activation.internal.Activator
> SLF4J: org.apache.sling.javax.activation.internal.OsgiMailcapCommandMap
> SLF4J: org.apache.sling.launchpad.installer
> SLF4J: org.apache.sling.settings
> SLF4J: org.apache.sling.settings.impl.SlingSettingsServiceImpl
> SLF4J: org.apache.sling.launchpad.installer.impl.LaunchpadConfigInstaller
> SLF4J: org.apache.sling.installer.core.impl.tasks.RestartActiveBundlesTask
> {noformat}
> Given that log from Sling installer category are important and should not be
> lost we should avoid such scenario to be created.
> See thread http://markmail.org/thread/n4zyj5akkh24ahh5
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-3340) Warnings on startup regarding no-op loggers
[
https://issues.apache.org/jira/browse/SLING-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636383#comment-14636383
]
Chetan Mehrotra edited comment on SLING-3340 at 7/22/15 6:40 AM:
-
Issue was fixed via update of Slf4j dependency. No change performed in Commons
Log hence not setting any fix version
was (Author: chetanm):
Issue was fixed via update of Slf4j dependency. No change performed in Commons
Log
> Warnings on startup regarding no-op loggers
> ---
>
> Key: SLING-3340
> URL: https://issues.apache.org/jira/browse/SLING-3340
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 4.0.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> Depening on the order in which bundles are installed Slf4j might use NoOp
> loggers for loggers created before Logback is initialized. One would see a
> warning log like below
> {noformat}
> Slf4j is not initialized yet. Delaying Logback support initialization
> SLF4J: The following loggers will not work because they were created
> SLF4J: during the default configuration phase of the underlying logging
> system.
> SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.sling.commons.logservice
> SLF4J: org.apache.sling.installer.core
> SLF4J: org.apache.sling.installer.core.impl.OsgiInstallerImpl
> SLF4J: org.apache.sling.audit.osgi.installer
> SLF4J: org.apache.sling.installer.core.impl.PersistentResourceList
> SLF4J: org.apache.sling.installer.core.impl.EntityResourceList
> SLF4J: org.apache.sling.installer.core.impl.tasks.BundleTaskCreator
> SLF4J: org.apache.sling.installer.core.impl.DefaultTransformer
> SLF4J: org.apache.sling.installer.provider.file
> SLF4J: org.apache.sling.installer.provider.file.impl.ServicesListener
> SLF4J: org.apache.sling.installer.provider.file.impl.FileInstaller
> SLF4J: org.apache.sling.javax.activation
> SLF4J: org.apache.sling.javax.activation.internal.Activator
> SLF4J: org.apache.sling.javax.activation.internal.OsgiMailcapCommandMap
> SLF4J: org.apache.sling.launchpad.installer
> SLF4J: org.apache.sling.settings
> SLF4J: org.apache.sling.settings.impl.SlingSettingsServiceImpl
> SLF4J: org.apache.sling.launchpad.installer.impl.LaunchpadConfigInstaller
> SLF4J: org.apache.sling.installer.core.impl.tasks.RestartActiveBundlesTask
> {noformat}
> Given that log from Sling installer category are important and should not be
> lost we should avoid such scenario to be created.
> See thread http://markmail.org/thread/n4zyj5akkh24ahh5
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-2322) Add option in ScheduledFileRotator for deleting old log files after maximum number of files that should be kept is reached
[ https://issues.apache.org/jira/browse/SLING-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-2322: --- Fix Version/s: Commons Log 4.0.0 > Add option in ScheduledFileRotator for deleting old log files after maximum > number of files that should be kept is reached > -- > > Key: SLING-2322 > URL: https://issues.apache.org/jira/browse/SLING-2322 > Project: Sling > Issue Type: New Feature > Components: Commons >Affects Versions: Commons Log 2.0.2, Commons Log 2.0.4, Commons Log 2.0.6, > Commons Log 2.1.0, Commons Log 2.1.2 > Environment: any >Reporter: Miroslav Smiljanic >Priority: Minor > Labels: logging > Fix For: Commons Log 4.0.0 > > > Decision of not deleting old files is by design. Feature is available in > other implementation of FileRotator, SizeLimitedFileRotator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-2322) Add option in ScheduledFileRotator for deleting old log files after maximum number of files that should be kept is reached
[ https://issues.apache.org/jira/browse/SLING-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-2322. Resolution: Not A Problem With switch to Logback one can use its feature to manage file rotation > Add option in ScheduledFileRotator for deleting old log files after maximum > number of files that should be kept is reached > -- > > Key: SLING-2322 > URL: https://issues.apache.org/jira/browse/SLING-2322 > Project: Sling > Issue Type: New Feature > Components: Commons >Affects Versions: Commons Log 2.0.2, Commons Log 2.0.4, Commons Log 2.0.6, > Commons Log 2.1.0, Commons Log 2.1.2 > Environment: any >Reporter: Miroslav Smiljanic >Priority: Minor > Labels: logging > > Decision of not deleting old files is by design. Feature is available in > other implementation of FileRotator, SizeLimitedFileRotator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4840) Provide an option to disable a set of logger via config
[
https://issues.apache.org/jira/browse/SLING-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-4840.
Resolution: Fixed
Done in http://svn.apache.org/r1692218
Log config now support a log level {{DEFAULT}}. If the level is set to
{{DEFAULT}} then for those loggers the config would remain but the logger state
would be set to default
# additivity -> true
# level -> null thus they inherit the level from parent
# no appender registered
This would allow the Logger config to remain present but would not have any
affect on runtime logging behaviour thus effectively disabling that logger
config
> Provide an option to disable a set of logger via config
> ---
>
> Key: SLING-4840
> URL: https://issues.apache.org/jira/browse/SLING-4840
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.4
>
>
> Logsupport Web Console plugin simplifies configuring the loggers with content
> assist. At times for debugging purpose users routes logs from set of loggers
> to a specific file.
> Post debugging these loggers have to be deleted. It would helpful if UI
> provides an option to turn off the loggers i.e. have the config be there but
> not applied
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-3490) Updated embeded Logback version to 1.1.2
[ https://issues.apache.org/jira/browse/SLING-3490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3490. Resolution: Duplicate > Updated embeded Logback version to 1.1.2 > > > Key: SLING-3490 > URL: https://issues.apache.org/jira/browse/SLING-3490 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > A new release of Logback ver 1.1.2 is available [1]. One improvement of > interest would be [LOGBACK-268|http://jira.qos.ch/browse/LOGBACK-268] > [1] http://logback.qos.ch/news.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3913) Sling Logging fails to work in Eclipse Virgo
[
https://issues.apache.org/jira/browse/SLING-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-3913.
Resolution: Later
Fix Version/s: (was: Commons Log 4.0.4)
The above error is just a warning seen in log but logging would still work.
With some work the warning can be avoided. For now no plan to address that so
resolving as {{Later}}. If required the issue can be reopened later
> Sling Logging fails to work in Eclipse Virgo
>
>
> Key: SLING-3913
> URL: https://issues.apache.org/jira/browse/SLING-3913
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 4.0.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
>
> Logging fails to work initially in SAP NetWeaver environment which run on top
> of OSGi using Eclipse Virgo which already use Logback. Following error is
> seen in app server logs. Note that evetually later logging does work, just
> that initial few logs which are generated before Sling Logging bundle gets
> started are lost
> {noformat}
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##Reported
> exception:|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##java.lang.ClassNotFoundException:
> org.eclipse.virgo.medic.log.logback.DelegatingContextSelector not found by
> org.apache.sling.commons.log [14]|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1973)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at java.lang.ClassLoader.loadClass(ClassLoader.java:415)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at java.lang.Class.forName0(Native Method)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at java.lang.Class.forName(Class.java:186)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at ch.qos.logback.core.util.Loader.loadClass(Loader.java:185)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> ch.qos.logback.classic.util.ContextSelectorStaticBinder.dynamicalContextSelector(ContextSelectorStaticBinder.java:97)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> ch.qos.logback.classic.util.ContextSelectorStaticBinder.init(ContextSelectorStaticBinder.java:72)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:93)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> org.apache.sling.installer.provider.file.impl.ServicesListener.(ServicesListener.java:45)|
> 2014 09 04
> 06:43:32#+00#ERROR#System.err##anonymous#FelixStartLevel##adsdev#deployedauthor1#web##
>at
> or
[jira] [Commented] (SLING-4896) A race condition can prevent correctly disabling the EventHandler created by the ScriptCache implementation
[
https://issues.apache.org/jira/browse/SLING-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636171#comment-14636171
]
Chetan Mehrotra commented on SLING-4896:
[~radu.cotescu] I had earlier logged SLING-4893. Is that same as this one? Is
yes then can you close that as duplicate of this
> A race condition can prevent correctly disabling the EventHandler created by
> the ScriptCache implementation
> ---
>
> Key: SLING-4896
> URL: https://issues.apache.org/jira/browse/SLING-4896
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Core 2.0.30
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.32
>
>
> A race condition can make the
> {{org.apache.sling.scripting.core.impl.ScriptCacheImpl}} component to not
> correctly unregister the {{EventHandler}} it dynamically creates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4891) Improve MapEntries to cache searched vanity paths
[
https://issues.apache.org/jira/browse/SLING-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634967#comment-14634967
]
Chetan Mehrotra commented on SLING-4891:
Looks fine. However as discussed these config switches are bit confusing and
best option eventually is use a LRU map and then user has just one setting to
worry i.e. maxSize
> Improve MapEntries to cache searched vanity paths
> --
>
> Key: SLING-4891
> URL: https://issues.apache.org/jira/browse/SLING-4891
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4891-patch.txt, SLING-4891-patch2.txt,
> SLING-4891-patch3.txt
>
>
> At the moment {{PROP_MAX_CACHED_VANITY_PATHS}} limits the number of in memory
> cached vanity paths in order to have a faster startup.
> I'd propose to slightly change the semantic of the limit of the cache .
> We can indeed limit the cache only for startup and when a vanity path query
> is executed and results are returned those can be added to the cache (and not
> thrown away as is now).
> If this same entry will be again requested it will be delivered from the
> cache, so fast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4893) Service already unregistered exception in ScriptCacheImpl
Chetan Mehrotra created SLING-4893:
--
Summary: Service already unregistered exception in ScriptCacheImpl
Key: SLING-4893
URL: https://issues.apache.org/jira/browse/SLING-4893
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Core 2.0.28
Reporter: Chetan Mehrotra
Assignee: Radu Cotescu
Priority: Minor
Seeing following error on startup with latest Launchpad from trunk
{noformat}
20.07.2015 20:29:10.310 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.scripting.core.impl.ScriptCacheImpl)]
org.apache.sling.scripting.core.impl.ScriptEngineManagerFactory Script
extension 'jspf' is now handled by ScriptEngine 'Apache Sling Scripting JSP
Support', version='2.1.6',
class='org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScriptEngine'
20.07.2015 20:29:10.310 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.scripting.core.impl.ScriptCacheImpl)]
org.apache.sling.scripting.core.impl.ScriptEngineManagerFactory Script
extension 'jspx' is now handled by ScriptEngine 'Apache Sling Scripting JSP
Support', version='2.1.6',
class='org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScriptEngine'
20.07.2015 20:29:10.311 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.scripting.core.impl.ScriptCacheImpl)]
org.apache.sling.scripting.core Service [361,
[org.osgi.service.event.EventHandler]] ServiceEvent UNREGISTERING
20.07.2015 20:29:10.316 *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.scripting.core.impl.ScriptCacheImpl)]
org.apache.sling.scripting.core
[org.apache.sling.scripting.core.impl.ScriptCacheImpl(114)] The deactivate
method has thrown an exception (java.lang.IllegalStateException: Service
already unregistered.)
java.lang.IllegalStateException: Service already unregistered.
at
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:136)
at
org.apache.sling.scripting.core.impl.ScriptCacheImpl.deactivate(ScriptCacheImpl.java:269)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
at
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
at
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
at
org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:355)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:170)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:929)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:915)
at
org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(ServiceRegistrationImpl.java:384)
{noformat}
Looking at {{ScriptCacheImpl}} the service reg is getting unregistered at two
place. So probably at {{configureCache}} it should null the reference
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4891) Improve MapEntries to cache searched vanity paths
[
https://issues.apache.org/jira/browse/SLING-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633627#comment-14633627
]
Chetan Mehrotra commented on SLING-4891:
{noformat}
+private void doAddVanity(Resource resource) {
+// fill up the cache and the bloom filter
+loadVanityPath(resource, resolveMapsMap, vanityTargets, true
/*addToCache*/, true /*newVanity*/);
+vanityCounter.incrementAndGet();
updateBloomFilterFile = true;
}
{noformat}
With new change any cache miss would lead to updateBloomFilterFile set to true.
Which is technically not required as the vanityPath might already be recorded
in bloom filter so update of bloom filter would not be required. Though looking
at impl it would not add much to performance cost but still something to
consider
> Improve MapEntries to cache searched vanity paths
> --
>
> Key: SLING-4891
> URL: https://issues.apache.org/jira/browse/SLING-4891
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4891-patch.txt
>
>
> At the moment {{PROP_MAX_CACHED_VANITY_PATHS}} limits the number of in memory
> cached vanity paths in order to have a faster startup.
> I'd propose to slightly change the semantic of the limit of the cache .
> We can indeed limit the cache only for startup and when a vanity path query
> is executed and results are returned those can be added to the cache (and not
> thrown away as is now).
> If this same entry will be again requested it will be delivered from the
> cache, so fast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4891) Improve MapEntries to cache searched vanity paths
[
https://issues.apache.org/jira/browse/SLING-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633394#comment-14633394
]
Chetan Mehrotra commented on SLING-4891:
[~asanso] Another aspect which we should look for is support for negative
cache. This would be useful for case where a given url is considered by bloom
filter as a vanity path (false positive) but is actually not a vanity url. For
such a case current logic would end up firing a new query always. For such
cases have a negative cache.
Now to determine if such cases are common we would need some JMX stats around
how effective is vanity path logic in presence of bloom filter
> Improve MapEntries to cache searched vanity paths
> --
>
> Key: SLING-4891
> URL: https://issues.apache.org/jira/browse/SLING-4891
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>
> At the moment {{PROP_MAX_CACHED_VANITY_PATHS}} limits the number of in memory
> cached vanity paths in order to have a faster startup.
> I'd propose to slightly change the semantic of the limit of the cache .
> We can indeed limit the cache only for startup and when a vanity path query
> is executed and results are returned those can be added to the cache (and not
> thrown away as is now).
> If this same entry will be again requested it will be delivered from the
> cache, so fast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4882) Shared session usage in Sling MapEntries causes contention
[
https://issues.apache.org/jira/browse/SLING-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627616#comment-14627616
]
Chetan Mehrotra commented on SLING-4882:
+1. This would avoid contention due to shared Jcr session
> Shared session usage in Sling MapEntries causes contention
> --
>
> Key: SLING-4882
> URL: https://issues.apache.org/jira/browse/SLING-4882
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-4882-patch.txt, SLING-4882-patchv2.txt
>
>
> {code:none}
> "pool-7-thread-103" prio=10 tid=0x7fede006c000 nid=0x6db8 waiting on
> condition [0x7fecdbb7a000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005063f5b00> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:775)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:271)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:127)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.refresh(SessionImpl.java:430)
> at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
> at com.sun.proxy.$Proxy7.refresh(Unknown Source)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.refresh(JcrResourceProvider.java:545)
> at
> org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.refresh(ResourceResolverContext.java:192)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.refresh(ResourceResolverImpl.java:1186)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:321)
> at
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:776)
> at
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
> at
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
> at
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
> at
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
> at
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
> at
> org.apache.sling.jcr.resource.internal.OakResourceListener.added(OakResourceListener.java:109)
> at
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:209)
> at
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
> at
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:182)
> at
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:124)
> at
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:124)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:118)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745
[jira] [Created] (SLING-4847) NullPointerException in MapEntries handleEvent
Chetan Mehrotra created SLING-4847:
--
Summary: NullPointerException in MapEntries handleEvent
Key: SLING-4847
URL: https://issues.apache.org/jira/browse/SLING-4847
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.14
Reporter: Chetan Mehrotra
Priority: Minor
On a running system at times following exceptions are seen
{noformat}
30.06.2015 09:00:34.108 *WARN* [pool-5-thread-115] org.apache.felix.eventadmin
Service [Map Entries Observation,1094] EventAdmin: Exception during event
dispatch [org.osgi.service.event.Event
[topic=org/apache/sling/api/resource/Resource/ADDED] |
[org.osgi.service.event.EventHandler] |
Bundle(org.apache.sling.resourceresolver [211])]
(java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.sling.resourceresolver.impl.mapping.MapEntries.doNodeAdded(MapEntries.java:300)
at
org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:769)
at
org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
at
org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
at
org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
at
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
at
org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
at
org.apache.sling.jcr.resource.internal.OakResourceListener.added(OakResourceListener.java:109)
at
org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:209)
at
org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
at
org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:182)
at
org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:124)
at
org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:163)
at
org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:124)
at
org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:118)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Looking at
[code|https://github.com/apache/sling/blob/a3f25af5da1edb9f2719f04b560370c5cb6464c3/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L299]
the resource might be null by the time event is processed. So code should
guard against that
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4840) Provide an option to disable a set of logger via config
[ https://issues.apache.org/jira/browse/SLING-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4840: --- Description: Logsupport Web Console plugin simplifies configuring the loggers with content assist. At times for debugging purpose users routes logs from set of loggers to a specific file. Post debugging these loggers have to be deleted. It would helpful if UI provides an option to turn off the loggers i.e. have the config be there but not applied was: Logsupport Web Console plugin simplifies configuring the loggers with content assist. At times for debugging purpose users routes logs from set of loggers to a specific file. Post debugging these loggers have to be deleted. It would helpful if UI provides an option to turn off the loggers > Provide an option to disable a set of logger via config > --- > > Key: SLING-4840 > URL: https://issues.apache.org/jira/browse/SLING-4840 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Commons Log 4.0.4 > > > Logsupport Web Console plugin simplifies configuring the loggers with content > assist. At times for debugging purpose users routes logs from set of loggers > to a specific file. > Post debugging these loggers have to be deleted. It would helpful if UI > provides an option to turn off the loggers i.e. have the config be there but > not applied -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4840) Provide an option to disable a set of logger via config
Chetan Mehrotra created SLING-4840: -- Summary: Provide an option to disable a set of logger via config Key: SLING-4840 URL: https://issues.apache.org/jira/browse/SLING-4840 Project: Sling Issue Type: Improvement Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Commons Log 4.0.4 Logsupport Web Console plugin simplifies configuring the loggers with content assist. At times for debugging purpose users routes logs from set of loggers to a specific file. Post debugging these loggers have to be deleted. It would helpful if UI provides an option to turn off the loggers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4839) Allow to configure logger additivity via OSGi Config UI
Chetan Mehrotra created SLING-4839: -- Summary: Allow to configure logger additivity via OSGi Config UI Key: SLING-4839 URL: https://issues.apache.org/jira/browse/SLING-4839 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons Log 4.0.2 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Commons Log 4.0.4 While configuring the loggers via OSGi Commons Log sets the additivity to false by default. Due to this logs from those categories are not routed to main error log. This at times causes important exceptions from getting noticed and hence might get missed out. Commons Log does support controlling the additivity via OSGi config but that setting is not exposed in UI. This setting should be exposed via UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4739) Log Tracer - To enable logs for specific category at specific level and only for specific request
[
https://issues.apache.org/jira/browse/SLING-4739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-4739.
--
> Log Tracer - To enable logs for specific category at specific level and only
> for specific request
> -
>
> Key: SLING-4739
> URL: https://issues.apache.org/jira/browse/SLING-4739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 0.0.2
>
>
> Tracer [1] simplifies enabling the logs for specific category at specific
> level and only for specific request. It provides a very fine level of control
> via config provided as part of HTTP request around how the logging should be
> performed for given category.
> For e.g. determining what nodes are written for a given POST request can be
> simply done by including an extra request parameter "tracer"
> {noformat}
> curl -D - -u admin:admin \
> -d "./jcr:content/jcr:title=Summer Collection" \
> -d ":name=summer-collection" \
> -d "./jcr:primaryType=sling:Folder" \
> -d "./jcr:content/jcr:primaryType=nt:unstructured" \
> -d "tracers=oak-writes" \
> http://localhost:8080/content/dam/
> {noformat}
> One can also specify actual categories as part of request param itself. For
> complete details refer to [1] (docs to be moved to Sling site)
> Refer to [1] for related discussion
> [1] http://markmail.org/thread/mijnl2mpxu4nzqkb
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4739) Log Tracer - To enable logs for specific category at specific level and only for specific request
[
https://issues.apache.org/jira/browse/SLING-4739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-4739.
Resolution: Fixed
> Log Tracer - To enable logs for specific category at specific level and only
> for specific request
> -
>
> Key: SLING-4739
> URL: https://issues.apache.org/jira/browse/SLING-4739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 0.0.2
>
>
> Tracer [1] simplifies enabling the logs for specific category at specific
> level and only for specific request. It provides a very fine level of control
> via config provided as part of HTTP request around how the logging should be
> performed for given category.
> For e.g. determining what nodes are written for a given POST request can be
> simply done by including an extra request parameter "tracer"
> {noformat}
> curl -D - -u admin:admin \
> -d "./jcr:content/jcr:title=Summer Collection" \
> -d ":name=summer-collection" \
> -d "./jcr:primaryType=sling:Folder" \
> -d "./jcr:content/jcr:primaryType=nt:unstructured" \
> -d "tracers=oak-writes" \
> http://localhost:8080/content/dam/
> {noformat}
> One can also specify actual categories as part of request param itself. For
> complete details refer to [1] (docs to be moved to Sling site)
> Refer to [1] for related discussion
> [1] http://markmail.org/thread/mijnl2mpxu4nzqkb
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4811) Handle OSGi event in a separate thread to prevent being blacklisted by the OSGi Event Admin
[
https://issues.apache.org/jira/browse/SLING-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587852#comment-14587852
]
Chetan Mehrotra commented on SLING-4811:
You can possibly use [Scheduler.schedule(runnable,
Scheduler.NOW())|https://github.com/apache/sling/blob/trunk/bundles/commons/scheduler/src/main/java/org/apache/sling/commons/scheduler/Scheduler.java#L123]
> Handle OSGi event in a separate thread to prevent being blacklisted by the
> OSGi Event Admin
> ---
>
> Key: SLING-4811
> URL: https://issues.apache.org/jira/browse/SLING-4811
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: i18n 2.4.2
>Reporter: Konrad Windszus
>
> Since Apache Felix blacklists all OSGi Event Handlers which take too long to
> complete it would be good if all long-running tasks would be executed in a
> separate thread (like preloading resource bundles).
> Otherwise the {{JcrResourceBundleProvider}} might get blacklisted if the
> instance is under load and in the future is not notified about any changes.
> The default timeout of Apache Felix is 5 seconds
> (http://felix.apache.org/documentation/subprojects/apache-felix-event-admin.html).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4676) Clean up threads or refresh threads when put back into the pool
[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583090#comment-14583090 ] Chetan Mehrotra commented on SLING-4676: For reflection based (best effort basis) approach we make use of logic used in Tomcat [1] [1] https://github.com/apache/tomcat/blob/6030b7ff6d600d95db3bd3f8794fc64432856e72/java/org/apache/catalina/loader/WebappClassLoaderBase.java#L2014 > Clean up threads or refresh threads when put back into the pool > --- > > Key: SLING-4676 > URL: https://issues.apache.org/jira/browse/SLING-4676 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > Fix For: Commons Threads 3.2.2 > > > A thread from the pool might use thread locals which are - for whatever > reason - not cleaned up, when the thread is put back into the pool. > This can lead to memory leaks. > We should protect against this. > Unfortunately there is no official API to clean up thread locals. There are > solutions out there using reflection. > Another option is to simply discard the thread object after some time of > usage and use a fresh one. This needs to include thread objects staying in > the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4739) Log Tracer - To enable logs for specific category at specific level and only for specific request
[
https://issues.apache.org/jira/browse/SLING-4739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14555912#comment-14555912
]
Chetan Mehrotra commented on SLING-4739:
Updated the docs at
http://sling.apache.org/documentation/bundles/log-tracers.html
> Log Tracer - To enable logs for specific category at specific level and only
> for specific request
> -
>
> Key: SLING-4739
> URL: https://issues.apache.org/jira/browse/SLING-4739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.0
>
>
> Tracer [1] simplifies enabling the logs for specific category at specific
> level and only for specific request. It provides a very fine level of control
> via config provided as part of HTTP request around how the logging should be
> performed for given category.
> For e.g. determining what nodes are written for a given POST request can be
> simply done by including an extra request parameter "tracer"
> {noformat}
> curl -D - -u admin:admin \
> -d "./jcr:content/jcr:title=Summer Collection" \
> -d ":name=summer-collection" \
> -d "./jcr:primaryType=sling:Folder" \
> -d "./jcr:content/jcr:primaryType=nt:unstructured" \
> -d "tracers=oak-writes" \
> http://localhost:8080/content/dam/
> {noformat}
> One can also specify actual categories as part of request param itself. For
> complete details refer to [1] (docs to be moved to Sling site)
> Refer to [1] for related discussion
> [1] http://markmail.org/thread/mijnl2mpxu4nzqkb
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4739) Log Tracer - To enable logs for specific category at specific level and only for specific request
[
https://issues.apache.org/jira/browse/SLING-4739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14555887#comment-14555887
]
Chetan Mehrotra commented on SLING-4739:
Moved the code to Sling with http://svn.apache.org/r1681054
> Log Tracer - To enable logs for specific category at specific level and only
> for specific request
> -
>
> Key: SLING-4739
> URL: https://issues.apache.org/jira/browse/SLING-4739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.0
>
>
> Tracer [1] simplifies enabling the logs for specific category at specific
> level and only for specific request. It provides a very fine level of control
> via config provided as part of HTTP request around how the logging should be
> performed for given category.
> For e.g. determining what nodes are written for a given POST request can be
> simply done by including an extra request parameter "tracer"
> {noformat}
> curl -D - -u admin:admin \
> -d "./jcr:content/jcr:title=Summer Collection" \
> -d ":name=summer-collection" \
> -d "./jcr:primaryType=sling:Folder" \
> -d "./jcr:content/jcr:primaryType=nt:unstructured" \
> -d "tracers=oak-writes" \
> http://localhost:8080/content/dam/
> {noformat}
> One can also specify actual categories as part of request param itself. For
> complete details refer to [1] (docs to be moved to Sling site)
> Refer to [1] for related discussion
> [1] http://markmail.org/thread/mijnl2mpxu4nzqkb
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4739) Log Tracer - To enable logs for specific category at specific level and only for specific request
Chetan Mehrotra created SLING-4739:
--
Summary: Log Tracer - To enable logs for specific category at
specific level and only for specific request
Key: SLING-4739
URL: https://issues.apache.org/jira/browse/SLING-4739
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: Log Tracer 1.0.0
Tracer [1] simplifies enabling the logs for specific category at specific level
and only for specific request. It provides a very fine level of control via
config provided as part of HTTP request around how the logging should be
performed for given category.
For e.g. determining what nodes are written for a given POST request can be
simply done by including an extra request parameter "tracer"
{noformat}
curl -D - -u admin:admin \
-d "./jcr:content/jcr:title=Summer Collection" \
-d ":name=summer-collection" \
-d "./jcr:primaryType=sling:Folder" \
-d "./jcr:content/jcr:primaryType=nt:unstructured" \
-d "tracers=oak-writes" \
http://localhost:8080/content/dam/
{noformat}
One can also specify actual categories as part of request param itself. For
complete details refer to [1] (docs to be moved to Sling site)
Refer to [1] for related discussion
[1] http://markmail.org/thread/mijnl2mpxu4nzqkb
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4717) Option to indent output in request progress tracker log
[
https://issues.apache.org/jira/browse/SLING-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-4717:
---
Attachment: SLING-4717-v2.patch
[updated patch|^SLING-4717-v2.patch] which just indents in the Web Console
plugin and not in normal logging. As the {{RequestHistoryConsolePlugin}} and
{{SlingRequestProgressTracker}} live in same package the plugin can rely on
implementation detail. So the indent information would be made part of
{{TrackingEntry}} and would be used via web console plugin.
So this can be enabled by default. If required we can have a request param to
disable indentation
> Option to indent output in request progress tracker log
> ---
>
> Key: SLING-4717
> URL: https://issues.apache.org/jira/browse/SLING-4717
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Alexander Klimetschek
>Priority: Minor
> Attachments: SLING-4717-v2.patch, SLING-4717.patch, indented-log.png
>
>
> For requests with large nested inclusions of resource trees, visually
> scanning the request progress tracker log is difficult. It would help if it's
> indented based on the inclusion level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4717) Option to indent output in request progress tracker log
[ https://issues.apache.org/jira/browse/SLING-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549932#comment-14549932 ] Chetan Mehrotra commented on SLING-4717: Missed the facts that its configurable. So +1 for this patch would allow better use of the progress tracker logs. btw bit related to this. Recently I added support for routing normal logs to progress tracker on per request basis to ACS Tools [1]. Probably we can make it part of Sling itself [1] https://github.com/Adobe-Consulting-Services/acs-aem-tools/pull/100 > Option to indent output in request progress tracker log > --- > > Key: SLING-4717 > URL: https://issues.apache.org/jira/browse/SLING-4717 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek >Priority: Minor > Attachments: SLING-4717.patch, indented-log.png > > > For requests with large nested inclusions of resource trees, visually > scanning the request progress tracker log is difficult. It would help if it's > indented based on the inclusion level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4717) Option to indent output in request progress tracker log
[ https://issues.apache.org/jira/browse/SLING-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547654#comment-14547654 ] Chetan Mehrotra commented on SLING-4717: bq. This log file has a good structure and can easily be automatically processed. Adding indentation makes it (somewhat) harder. Probably that can be done as part of WebConsole plugin which renders the request progress tracker collected logs > Option to indent output in request progress tracker log > --- > > Key: SLING-4717 > URL: https://issues.apache.org/jira/browse/SLING-4717 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Alexander Klimetschek >Priority: Minor > Attachments: SLING-4717.patch, indented-log.png > > > For requests with large nested inclusions of resource trees, visually > scanning the request progress tracker log is difficult. It would help if it's > indented based on the inclusion level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4563) Log start level number on STARTLEVEL CHANGED event
[
https://issues.apache.org/jira/browse/SLING-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392095#comment-14392095
]
Chetan Mehrotra commented on SLING-4563:
+1 to include this support. I always wondered with that log as to whats the
current level it moved to. So thanks [~alexander.klimetschek] for addressing
this!
> Log start level number on STARTLEVEL CHANGED event
> --
>
> Key: SLING-4563
> URL: https://issues.apache.org/jira/browse/SLING-4563
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Alexander Klimetschek
> Attachments: SLING-4563.patch
>
>
> Currently, the Sling logservice just logs that an osgi start level has
> changed, without indicating which one:
> {noformat}
> ...org.apache.felix.framework FrameworkEvent STARTLEVEL CHANGED
> {noformat}
> This should include the current framework startlevel:
> {noformat}
> ...org.apache.felix.framework FrameworkEvent STARTLEVEL CHANGED to 14
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4564) Use a single listener registered for multiple path in JCR installer
Chetan Mehrotra created SLING-4564:
--
Summary: Use a single listener registered for multiple path in JCR
installer
Key: SLING-4564
URL: https://issues.apache.org/jira/browse/SLING-4564
Project: Sling
Issue Type: Improvement
Components: Installer
Affects Versions: JCR Installer 3.1.8
Reporter: Chetan Mehrotra
Sling Jcr installer currently registers one listener per watched folder. On an
application like AEM this results in ~150 listeners out of total 210 to belong
to Jcr installer.
Recently Jackrabbit introduced support for adding [additional
path|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/observation/JackrabbitEventFilter.java#L232]
to listen to as part of JCR-3745. This can be leveraged by the Jcr installer
to avoid registering multiple listeners and instead use one listener.
The above feature can be used in following form
{code}
String[] paths = searchPaths.toArray(new String[]{});
JackrabbitEventFilter eventFilter = new JackrabbitEventFilter()
.setAbsPath(paths[0])
.setEventTypes(Event.NODE_ADDED |
Event.NODE_REMOVED |
Event.NODE_MOVED |
Event.PROPERTY_ADDED |
Event.PROPERTY_CHANGED |
Event.PROPERTY_REMOVED )
.setIsDeep(true)
.setNoLocal(false)
.setNoExternal(true);
if (paths.length > 1) {
eventFilter.setAdditionalPaths(paths);
}
JackrabbitObservationManager observationManager =
(JackrabbitObservationManager)
adminSession.getWorkspace().getObservationManager();
observationManager.addEventListener(this, eventFilter);
{code}
This would allow more efficient observation processing and avoid putting load
on system as Oak currently maintains one queue per listener.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4528) Moving to Oak
[
https://issues.apache.org/jira/browse/SLING-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14376021#comment-14376021
]
Chetan Mehrotra commented on SLING-4528:
[~olli] JcrRepositoryHacks does not look good in name! In January I got most of
the IT in Sling pass with Oak however was not able to cleanup the server bundle
code. Unfortunately I do not yet have time to look into this. Hopefully would
have some time post 1.2 release
> Moving to Oak
> -
>
> Key: SLING-4528
> URL: https://issues.apache.org/jira/browse/SLING-4528
> Project: Sling
> Issue Type: Task
> Components: JCR
>Reporter: Oliver Lietz
> Labels: oak
> Fix For: JCR Oak Server 1.0.0
>
>
> _Apache Sling Oak Repository Server_ ({{org.apache.sling.jcr.oak.server}}) is
> not released and contains some TODOs and {{JcrRepositoryHacks}}.
> What needs to be done for a first release, [~bdelacretaz] and [~mduerig]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4512) Traversal Warnings in OAK while creating i18n JcrResourceBundle
[
https://issues.apache.org/jira/browse/SLING-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-4512:
---
Issue Type: Improvement (was: Bug)
> Traversal Warnings in OAK while creating i18n JcrResourceBundle
> ---
>
> Key: SLING-4512
> URL: https://issues.apache.org/jira/browse/SLING-4512
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Srijan Bhatnagar
>
> org.apache.sling.i18n.impl.JcrResourceBundle#loadFully uses an XPath query to
> load [sling:Message] nodes under given paths. If the subtree under the path
> is too big (>1000), we receive traversal warnings in Oak. The following
> warning is generated if the path is /libs/wcm/core/i18n/de :
> {code}
> GET /content/geometrixx/de.html HTTP/1.1]
> org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor Traversed 1000
> nodes with filter Filter(query=select [jcr:path], [jcr:score], * from
> [sling:Message] as a where isdescendantnode(a, '/libs/wcm/core/i18n/de') /*
> xpath: /jcr:root/libs/wcm/core/i18n/de//element(*,sling:Message) */,
> path=/libs/wcm/core/i18n/de//*); consider creating an index or changing the
> query
> {code}
> A suggestion would be to use
> [TreeTraverser|http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/commons/flat/TreeTraverser.html]
> instead of XPath query since the subtree is mostly a flat list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4503) Provide a mechanism to notify a JMX Bean about startup progress
[ https://issues.apache.org/jira/browse/SLING-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362692#comment-14362692 ] Chetan Mehrotra commented on SLING-4503: May be we can make use of [JMX Notification| http://docs.oracle.com/javase/tutorial/jmx/notifs/] for such kind of scenarios > Provide a mechanism to notify a JMX Bean about startup progress > --- > > Key: SLING-4503 > URL: https://issues.apache.org/jira/browse/SLING-4503 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Launchpad Base 2.5.10 > > > Although we have a StartupListener interface that allows notifications within > the OSGi framework about startup, there is no way to notify anything outside > the framework. > We could add a listener that notifies a JMX Bean that has been registered > outside the framework. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4472) MockBundleContent.getProperty should return null
Chetan Mehrotra created SLING-4472:
--
Summary: MockBundleContent.getProperty should return null
Key: SLING-4472
URL: https://issues.apache.org/jira/browse/SLING-4472
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing OSGi Mock 1.2.0
Reporter: Chetan Mehrotra
Priority: Minor
{{MockBundleContext.getProperty}} currently throws
{{UnsupportedOperationException}}. Instead if it can return null that would
allow some scenarios to be tested where logic checks for Framework properties.
Or if possible allow passing of Properties to represent Framework properties
say why delegating to System property to passing an explicit set of properties
while instantiate {{MockBundleContext}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4470) OSGi mock has compile time dependency on slf4j-simple
[
https://issues.apache.org/jira/browse/SLING-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346805#comment-14346805
]
Chetan Mehrotra commented on SLING-4470:
In Jackrabbit Oak we use Logback for testcase and have a custom
logback-test.xml. So having multiple provider would cause issue as only one
would be picked and in our case we want the Logback one to be used.
bq. if we remove this dependency or change it to "test" it is not active in the
project that has the test code and on every project you would have to include
slf4j-simple and a matching logging configuration yourself to ensure a proper
logging setup
I think that should be the way. OSGi Mock is a library which the project use
and it should not effect the way logging happens in the project. That should be
left to project to decide
> OSGi mock has compile time dependency on slf4j-simple
> -
>
> Key: SLING-4470
> URL: https://issues.apache.org/jira/browse/SLING-4470
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 1.2.0
>Reporter: Chetan Mehrotra
>Priority: Minor
>
> org.apache.sling.testing.osgi-mock has a compile time dependency on
> slf4j-simple which triggers warning by slf4j
> {noformat}
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/home/user/.m2/repository/ch/qos/logback/logback-classic/1.1.0/logback-classic-1.1.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/home/user/.m2/repository/org/slf4j/slf4j-simple/1.7.6/slf4j-simple-1.7.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> {noformat}
> Scope for slf4j-simple should be test or provided
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4470) OSGi mock has compile time dependency on slf4j-simple
[
https://issues.apache.org/jira/browse/SLING-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346432#comment-14346432
]
Chetan Mehrotra commented on SLING-4470:
It also seems to package simplelog.properties [1] which should also avoided
[1]
https://github.com/apache/sling/blob/trunk/testing/mocks/osgi-mock/src/main/resources/simplelogger.properties
> OSGi mock has compile time dependency on slf4j-simple
> -
>
> Key: SLING-4470
> URL: https://issues.apache.org/jira/browse/SLING-4470
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 1.2.0
>Reporter: Chetan Mehrotra
>Priority: Minor
>
> org.apache.sling.testing.osgi-mock has a compile time dependency on
> slf4j-simple which triggers warning by slf4j
> {noformat}
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/home/user/.m2/repository/ch/qos/logback/logback-classic/1.1.0/logback-classic-1.1.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/home/user/.m2/repository/org/slf4j/slf4j-simple/1.7.6/slf4j-simple-1.7.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> {noformat}
> Scope for slf4j-simple should be test or provided
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4470) OSGi mock has compile time dependency on slf4j-simple
Chetan Mehrotra created SLING-4470:
--
Summary: OSGi mock has compile time dependency on slf4j-simple
Key: SLING-4470
URL: https://issues.apache.org/jira/browse/SLING-4470
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing OSGi Mock 1.2.0
Reporter: Chetan Mehrotra
Priority: Minor
org.apache.sling.testing.osgi-mock has a compile time dependency on
slf4j-simple which triggers warning by slf4j
{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/home/user/.m2/repository/ch/qos/logback/logback-classic/1.1.0/logback-classic-1.1.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/user/.m2/repository/org/slf4j/slf4j-simple/1.7.6/slf4j-simple-1.7.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
{noformat}
Scope for slf4j-simple should be test or provided
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[ https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325815#comment-14325815 ] Chetan Mehrotra commented on SLING-4429: Also it would be simpler if the listener can get the config from Framework properties. Then we would not have to modify the web.xml of a packaged webapp. [~cziegeler] Would it be possible to access the Framework properties in the listener somehow? > Support JNDI lookup in JDBC DataSource Provider for App Servers > --- > > Key: SLING-4429 > URL: https://issues.apache.org/jira/browse/SLING-4429 > Project: Sling > Issue Type: Improvement > Components: Extensions, Launchpad >Reporter: Ankit Aggarwal >Assignee: Chetan Mehrotra > Attachments: SLING-4429.patch > > > JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735. > (Where we are trying the JNDI access from a thread that is not managed by the > J2EE.). > In this case, We will create a Listener in sling launchpad webapp and then > register the JNDI DataSource in DummyContext which would then be available in > OSGI environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[
https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325810#comment-14325810
]
Chetan Mehrotra commented on SLING-4429:
bq We could store the app server context in a static variable in the
ServletContextListener and then somehow do some magic
Not sure if keeping the {{InitialContext}} would help. My thinking is that all
those JEE rules (invoke from managed thread) is invoked on caller thread when
actual lookup is performed. As then the content implementation can map the
callers content to the correct JNDI sub tree view. So it would be safer to just
copy the stuff when you can do that legally and expose it via static map. Kind
of cheating but then we do not have any other option ;)
> Support JNDI lookup in JDBC DataSource Provider for App Servers
> ---
>
> Key: SLING-4429
> URL: https://issues.apache.org/jira/browse/SLING-4429
> Project: Sling
> Issue Type: Improvement
> Components: Extensions, Launchpad
>Reporter: Ankit Aggarwal
>Assignee: Chetan Mehrotra
> Attachments: SLING-4429.patch
>
>
> JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735.
> (Where we are trying the JNDI access from a thread that is not managed by the
> J2EE.).
> In this case, We will create a Listener in sling launchpad webapp and then
> register the JNDI DataSource in DummyContext which would then be available in
> OSGI environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[
https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325810#comment-14325810
]
Chetan Mehrotra edited comment on SLING-4429 at 2/18/15 12:12 PM:
--
bq. We could store the app server context in a static variable in the
ServletContextListener and then somehow do some magic
Not sure if keeping the {{InitialContext}} would help. My thinking is that all
those JEE rules (invoke from managed thread) is invoked on caller thread when
actual lookup is performed. As then the content implementation can map the
callers content to the correct JNDI sub tree view. So it would be safer to just
copy the stuff when you can do that legally and expose it via static map. Kind
of cheating but then we do not have any other option ;)
was (Author: chetanm):
bq We could store the app server context in a static variable in the
ServletContextListener and then somehow do some magic
Not sure if keeping the {{InitialContext}} would help. My thinking is that all
those JEE rules (invoke from managed thread) is invoked on caller thread when
actual lookup is performed. As then the content implementation can map the
callers content to the correct JNDI sub tree view. So it would be safer to just
copy the stuff when you can do that legally and expose it via static map. Kind
of cheating but then we do not have any other option ;)
> Support JNDI lookup in JDBC DataSource Provider for App Servers
> ---
>
> Key: SLING-4429
> URL: https://issues.apache.org/jira/browse/SLING-4429
> Project: Sling
> Issue Type: Improvement
> Components: Extensions, Launchpad
>Reporter: Ankit Aggarwal
>Assignee: Chetan Mehrotra
> Attachments: SLING-4429.patch
>
>
> JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735.
> (Where we are trying the JNDI access from a thread that is not managed by the
> J2EE.).
> In this case, We will create a Listener in sling launchpad webapp and then
> register the JNDI DataSource in DummyContext which would then be available in
> OSGI environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[
https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325792#comment-14325792
]
Chetan Mehrotra edited comment on SLING-4429 at 2/18/15 11:52 AM:
--
[~aagarwa] Thanks for the patch. It would be better if {{SlingJNDIListener}} is
generic can bind instance of any type. It should not be concerned with the type
of object it is binding (can be anything from DataSource, TransactionManager
etc)
[~cziegeler] [~fmeschbe] Attached patch is based on the approach you suggested
sometime back to copy the JNDI instances from within a
{{ServletContextListener}} which is executed on a server managed thread and
hence can access the JNDI content to a static map in a dummy InitialContext
implementation. Sling DataSource bundle can then lookup via the dummy content
and bind the instance to OSGi.
So can you have a look so that it can be added to launchpad
[~reschke] This should enable looup of JNDI bound DataSource in any app server
environment
was (Author: chetanm):
[~aagarwa] Thanks for the patch. It would be better if {{SlingJNDIListener}} is
generic can bind instance of any type. It should not be concerned with the type
of object it is binding (can be anything from DataSource, TransactionManager
etc)
[~cziegeler] [~fmeschbe] Attached based is based on the approach you suggested
sometime back to copy the JNDI instances from within a
{{ServletContextListener}} which is executed on a server managed thread and
hence can access the JNDI content to a static map in a dummy InitialContext
implementation. Sling DataSource bundle can then lookup via the dummy content
and bind the instance to OSGi.
So can you have a look so that it can be added to launchpad
[~reschke] This should enable looup of JNDI bound DataSource in any app server
environment
> Support JNDI lookup in JDBC DataSource Provider for App Servers
> ---
>
> Key: SLING-4429
> URL: https://issues.apache.org/jira/browse/SLING-4429
> Project: Sling
> Issue Type: Improvement
> Components: Extensions, Launchpad
>Reporter: Ankit Aggarwal
>Assignee: Chetan Mehrotra
> Attachments: SLING-4429.patch
>
>
> JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735.
> (Where we are trying the JNDI access from a thread that is not managed by the
> J2EE.).
> In this case, We will create a Listener in sling launchpad webapp and then
> register the JNDI DataSource in DummyContext which would then be available in
> OSGI environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[ https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4429: --- Issue Type: Improvement (was: Bug) > Support JNDI lookup in JDBC DataSource Provider for App Servers > --- > > Key: SLING-4429 > URL: https://issues.apache.org/jira/browse/SLING-4429 > Project: Sling > Issue Type: Improvement > Components: Extensions, Launchpad >Reporter: Ankit Aggarwal >Assignee: Chetan Mehrotra > Attachments: SLING-4429.patch > > > JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735. > (Where we are trying the JNDI access from a thread that is not managed by the > J2EE.). > In this case, We will create a Listener in sling launchpad webapp and then > register the JNDI DataSource in DummyContext which would then be available in > OSGI environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[
https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325792#comment-14325792
]
Chetan Mehrotra commented on SLING-4429:
[~aagarwa] Thanks for the patch. It would be better if {{SlingJNDIListener}} is
generic can bind instance of any type. It should not be concerned with the type
of object it is binding (can be anything from DataSource, TransactionManager
etc)
[~cziegeler] [~fmeschbe] Attached based is based on the approach you suggested
sometime back to copy the JNDI instances from within a
{{ServletContextListener}} which is executed on a server managed thread and
hence can access the JNDI content to a static map in a dummy InitialContext
implementation. Sling DataSource bundle can then lookup via the dummy content
and bind the instance to OSGi.
So can you have a look so that it can be added to launchpad
[~reschke] This should enable looup of JNDI bound DataSource in any app server
environment
> Support JNDI lookup in JDBC DataSource Provider for App Servers
> ---
>
> Key: SLING-4429
> URL: https://issues.apache.org/jira/browse/SLING-4429
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Launchpad
>Reporter: Ankit Aggarwal
>Priority: Critical
> Attachments: SLING-4429.patch
>
>
> JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735.
> (Where we are trying the JNDI access from a thread that is not managed by the
> J2EE.).
> In this case, We will create a Listener in sling launchpad webapp and then
> register the JNDI DataSource in DummyContext which would then be available in
> OSGI environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[ https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4429: --- Priority: Major (was: Critical) > Support JNDI lookup in JDBC DataSource Provider for App Servers > --- > > Key: SLING-4429 > URL: https://issues.apache.org/jira/browse/SLING-4429 > Project: Sling > Issue Type: Bug > Components: Extensions, Launchpad >Reporter: Ankit Aggarwal >Assignee: Chetan Mehrotra > Attachments: SLING-4429.patch > > > JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735. > (Where we are trying the JNDI access from a thread that is not managed by the > J2EE.). > In this case, We will create a Listener in sling launchpad webapp and then > register the JNDI DataSource in DummyContext which would then be available in > OSGI environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[ https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned SLING-4429: -- Assignee: Chetan Mehrotra > Support JNDI lookup in JDBC DataSource Provider for App Servers > --- > > Key: SLING-4429 > URL: https://issues.apache.org/jira/browse/SLING-4429 > Project: Sling > Issue Type: Bug > Components: Extensions, Launchpad >Reporter: Ankit Aggarwal >Assignee: Chetan Mehrotra >Priority: Critical > Attachments: SLING-4429.patch > > > JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735. > (Where we are trying the JNDI access from a thread that is not managed by the > J2EE.). > In this case, We will create a Listener in sling launchpad webapp and then > register the JNDI DataSource in DummyContext which would then be available in > OSGI environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[ https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4429: --- Summary: Support JNDI lookup in JDBC DataSource Provider for App Servers (was: Support JNDI lookup in JDBC DataSource Provider for WebSphere) > Support JNDI lookup in JDBC DataSource Provider for App Servers > --- > > Key: SLING-4429 > URL: https://issues.apache.org/jira/browse/SLING-4429 > Project: Sling > Issue Type: Bug > Components: Extensions, Launchpad >Reporter: Ankit Aggarwal >Priority: Critical > Attachments: SLING-4429.patch > > > JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735. > (Where we are trying the JNDI access from a thread that is not managed by the > J2EE.). > In this case, We will create a Listener in sling launchpad webapp and then > register the JNDI DataSource in DummyContext which would then be available in > OSGI environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4429) Support JNDI lookup in JDBC DataSource Provider for App Servers
[ https://issues.apache.org/jira/browse/SLING-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-4429: --- Component/s: Launchpad > Support JNDI lookup in JDBC DataSource Provider for App Servers > --- > > Key: SLING-4429 > URL: https://issues.apache.org/jira/browse/SLING-4429 > Project: Sling > Issue Type: Bug > Components: Extensions, Launchpad >Reporter: Ankit Aggarwal >Priority: Critical > Attachments: SLING-4429.patch > > > JNDI lookup fails in case of WebSphere as mentioned in JIRA SLING-3735. > (Where we are trying the JNDI access from a thread that is not managed by the > J2EE.). > In this case, We will create a Listener in sling launchpad webapp and then > register the JNDI DataSource in DummyContext which would then be available in > OSGI environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4397) JDBC Datasource: Add support for system properties
[
https://issues.apache.org/jira/browse/SLING-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313670#comment-14313670
]
Chetan Mehrotra commented on SLING-4397:
[~amitjain] It would be better to make use of Framework properties instead of
system properties. With Sling the framework property can be set at command line
itself via {{-D}} [commandline
option|http://sling.apache.org/documentation/the-sling-engine/the-sling-launchpad.html#command-line-options].
This would however not work with Webapp based deployment. Probably that should
be fine as in such deplyments JNDI based DataSource would be used
> JDBC Datasource: Add support for system properties
> --
>
> Key: SLING-4397
> URL: https://issues.apache.org/jira/browse/SLING-4397
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Amit Jain
> Fix For: DataSource Provider 1.0.0
>
>
> Currently, the DB properties are configured through a file. For db connection
> properties like url, username, password it is better to provide an override
> mechanism through the system properties.
> This would enable applications to bundle a default config which can be
> overridden through command-line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
