from:"Chetan Mehrotra"


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

Chetan Mehrotra updated SLING-3463:
---

Description: 
Sling Installer provides support for installing OSGi config files by placing 
them in external directories. So one can place config file in sling 
home/install folder and they would be automatically installed by Sling OSGi 
Installer upon system start. Further these config are given higher priority 
over packaged config file.

This logic fails to work on Windows. For example if place config through 
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg file and 
same file is also packaged within the launchpad then only the launchpad one is 
picked up. Sling Installer tab on WebConsole shows following entries

Entry 1
-
EntityId - 
fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
 
fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.47a70bec-964a-4655-b6c4-141dc22c354b
  

ba55ef93ba200825e9cf9fa7fcff14d3/100

fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx-quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg
 

INSTALLED 11:56:09:406 2014-Mar-19

Entry 2
--

EntityId  - org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService   

4e2f24f28879a116c45e7aea547909fd/55 
launchpad:resources/config/crx3tar/org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config

INSTALLED 11:56:09:542 2014-Mar-19
--

As cane be seen EntityId for external file is not correct due to which it does 
not get proper pid. Hence any config created via external file route would not 
work on Windows



  was:
Sling Installer provides support for installing OSGi config files by placing 
them in external directories. So one can place config file in sling 
home/install folder and they would be automatically installed by Sling OSGi 
Installer upon system start. Further these config are given higher priority 
over packaged config file.

This logic fails to work on Windows. For example if place config through 
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg file and 
same file is also packaged within the launchpad then only the launchpad one is 
picked up. Sling Installer tab on WebConsole shows following entries

Entry 1
-
EntityId - 
fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
 
fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.47a70bec-964a-4655-b6c4-141dc22c354b
  

ba55ef93ba200825e9cf9fa7fcff14d3/100

fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx-quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg
 

INSTALLED 11:56:09:406 2014-Mar-19

Entry 2
--

EntityId  - org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService   

4e2f24f28879a116c45e7aea547909fd/55 
launchpad:resources/config/crx3tar/org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config

INSTALLED 11:56:09:542 2014-Mar-19
--

As cane be seen EntityId for external file is not correct due to which it does 
not get proper pid




 Config files cannot be installed via FileProvider on Windows
 

 Key: SLING-3463
 URL: https://issues.apache.org/jira/browse/SLING-3463
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Configuration Factory 1.0.10
Reporter: Chetan Mehrotra

 Sling Installer provides support for installing OSGi config files by placing 
 them in external directories. So one can place config file in sling 
 home/install folder and they would be automatically installed by Sling OSGi 
 Installer upon system start. Further these config are given higher priority 
 over packaged config file.
 This logic fails to work on Windows. For example if place config through 
 org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg file 
 and same file is also packaged within the launchpad then only the launchpad 
 one is picked up. Sling Installer tab on WebConsole shows following entries
 Entry 1
 -
 EntityId - 
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService

[jira] [Updated] (SLING-3463) Config files cannot be installed via FileProvider on Windows


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

Chetan Mehrotra updated SLING-3463:
---

Attachment: SLING-3463.patch

This support is implemented in FileInstaller [1]

It uses the File absolutePath as InstallableResource id. Later the 
ConfigTaskCreator constructs extracts the configPid from file path. However it 
looks for '/' in path to determine configPid. This fails for Windows paths. As 
a fix it should first normalize the path to use '/' as path separator and then 
extract the configPid.

Attaching patch for the same

[1] 
https://github.com/apache/sling/blob/trunk/installer/providers/file/src/main/java/org/apache/sling/installer/provider/file/impl/Installer.java#L145

 Config files cannot be installed via FileProvider on Windows
 

 Key: SLING-3463
 URL: https://issues.apache.org/jira/browse/SLING-3463
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Configuration Factory 1.0.10
Reporter: Chetan Mehrotra
 Attachments: SLING-3463.patch


 Sling Installer provides support for installing OSGi config files by placing 
 them in external directories. So one can place config file in sling 
 home/install folder and they would be automatically installed by Sling OSGi 
 Installer upon system start. Further these config are given higher priority 
 over packaged config file.
 This logic fails to work on Windows. For example if place config through 
 org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg file 
 and same file is also packaged within the launchpad then only the launchpad 
 one is picked up. Sling Installer tab on WebConsole shows following entries
 Entry 1
 -
 EntityId - 
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
  
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.47a70bec-964a-4655-b6c4-141dc22c354b
   
 ba55ef93ba200825e9cf9fa7fcff14d3/100
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx-quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg
  
 INSTALLED 11:56:09:406 2014-Mar-19
 Entry 2
 --
 EntityId  - org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService 
   
 4e2f24f28879a116c45e7aea547909fd/55 
 launchpad:resources/config/crx3tar/org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config
 
 INSTALLED 11:56:09:542 2014-Mar-19
 --
 As cane be seen EntityId for external file is not correct due to which it 
 does not get proper pid. Hence any config created via external file route 
 would not work on Windows



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3463) Config files cannot be installed via FileProvider on Windows


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

Chetan Mehrotra resolved SLING-3463.


   Resolution: Fixed
Fix Version/s: Installer Configuration Factory 1.0.12
 Assignee: Chetan Mehrotra

 Config files cannot be installed via FileProvider on Windows
 

 Key: SLING-3463
 URL: https://issues.apache.org/jira/browse/SLING-3463
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Configuration Factory 1.0.10
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: Installer Configuration Factory 1.0.12

 Attachments: SLING-3463.patch


 Sling Installer provides support for installing OSGi config files by placing 
 them in external directories. So one can place config file in sling 
 home/install folder and they would be automatically installed by Sling OSGi 
 Installer upon system start. Further these config are given higher priority 
 over packaged config file.
 This logic fails to work on Windows. For example if place config through 
 org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg file 
 and same file is also packaged within the launchpad then only the launchpad 
 one is picked up. Sling Installer tab on WebConsole shows following entries
 Entry 1
 -
 EntityId - 
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
  
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.47a70bec-964a-4655-b6c4-141dc22c354b
   
 ba55ef93ba200825e9cf9fa7fcff14d3/100
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx-quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg
  
 INSTALLED 11:56:09:406 2014-Mar-19
 Entry 2
 --
 EntityId  - org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService 
   
 4e2f24f28879a116c45e7aea547909fd/55 
 launchpad:resources/config/crx3tar/org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config
 
 INSTALLED 11:56:09:542 2014-Mar-19
 --
 As cane be seen EntityId for external file is not correct due to which it 
 does not get proper pid. Hence any config created via external file route 
 would not work on Windows



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3463) Config files cannot be installed via FileProvider on Windows


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

Chetan Mehrotra commented on SLING-3463:


bq. however I would just use File.separatorChar and replace File.separatorChar 
with /

That can be used but then testcase would not pass on Unix system as there we 
forcefully use a Windows path for test. 

Applied the patch with http://svn.apache.org/r1579534



 Config files cannot be installed via FileProvider on Windows
 

 Key: SLING-3463
 URL: https://issues.apache.org/jira/browse/SLING-3463
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: Installer Configuration Factory 1.0.10
Reporter: Chetan Mehrotra
 Fix For: Installer Configuration Factory 1.0.12

 Attachments: SLING-3463.patch


 Sling Installer provides support for installing OSGi config files by placing 
 them in external directories. So one can place config file in sling 
 home/install folder and they would be automatically installed by Sling OSGi 
 Installer upon system start. Further these config are given higher priority 
 over packaged config file.
 This logic fails to work on Windows. For example if place config through 
 org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg file 
 and same file is also packaged within the launchpad then only the launchpad 
 one is picked up. Sling Installer tab on WebConsole shows following entries
 Entry 1
 -
 EntityId - 
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
  
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx.47a70bec-964a-4655-b6c4-141dc22c354b
   
 ba55ef93ba200825e9cf9fa7fcff14d3/100
 fileinstallc17bbadb679768c7784c80352bf17196:C:\Data\Work\InstalledSoftware\granite\crx-quickstart\install\org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg
  
 INSTALLED 11:56:09:406 2014-Mar-19
 Entry 2
 --
 EntityId  - org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService 
   
 4e2f24f28879a116c45e7aea547909fd/55 
 launchpad:resources/config/crx3tar/org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config
 
 INSTALLED 11:56:09:542 2014-Mar-19
 --
 As cane be seen EntityId for external file is not correct due to which it 
 does not get proper pid. Hence any config created via external file route 
 would not work on Windows



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE RESULT] Release Apache Sling Commons Log 4.0.0

2014-03-06 Thread Chetan Mehrotra

Thanks Carsten!!
Chetan Mehrotra


On Fri, Mar 7, 2014 at 11:44 AM, Carsten Ziegeler cziege...@apache.org wrote:
 Hi,

 I've released the artifact, updated the dist dir, jira and the website

 Carsten


 2014-03-05 14:49 GMT+01:00 Chetan Mehrotra chetan.mehro...@gmail.com:

 Hi,

 The vote has passed with the following result :

 +1 (binding): Carsten Ziegeler, Bertrand Delacretaz and Ian Boston
 +1 (non binding): Chetan Mehrotra

 Thanks everyone for voting

 Can someone from PMC team promote the release?

 Chetan Mehrotra




 --
 Carsten Ziegeler
 cziege...@apache.org

[VOTE RESULT] Release Apache Sling Commons Log 4.0.0

2014-03-05 Thread Chetan Mehrotra

Hi,

The vote has passed with the following result :

+1 (binding): Carsten Ziegeler, Bertrand Delacretaz and Ian Boston
+1 (non binding): Chetan Mehrotra

Thanks everyone for voting

Can someone from PMC team promote the release?

Chetan Mehrotra

Re: [VOTE] Release Apache Sling Commons Log 4.0.0

2014-03-04 Thread Chetan Mehrotra

One more binding vote required!!

Chetan Mehrotra


On Tue, Mar 4, 2014 at 6:33 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 +1, checked signatures, build and that the below archive matches the
 corresponding svn tag:

 MD5 
 (./org.apache.sling.commons.log/4.0.0/org.apache.sling.commons.log-4.0.0-source-release.zip)
 = 1b0cfce87b564c4a6ff6b5731d11bb89


 -Bertrand

Re: [VOTE] Release Apache Sling Commons Log 4.0.0

2014-03-02 Thread Chetan Mehrotra

Hi Justin,

As per Sling Release Process [1] I have my key listed under
https://people.apache.org/keys/group/sling.asc. Do I have to publish
it in some other place also?

Chetan Mehrotra
[1] 
http://sling.apache.org/documentation/development/release-management.html#appendix-a-create-and-add-your-key-to-httpspeopleapacheorgkeysgroupslingasc


On Mon, Mar 3, 2014 at 4:08 AM, Justin Edelson jus...@justinedelson.com wrote:
 Hi Chetan,
 I think your GPG key is missing from
 http://svn.apache.org/repos/asf/sling/trunk/KEYS

 Please add it.

 Regards,
 Justin

 On Thu, Feb 27, 2014 at 6:13 AM, Chetan Mehrotra
 chetan.mehro...@gmail.com wrote:
 +1 (Non Binding)

 Chetan Mehrotra


 On Thu, Feb 27, 2014 at 4:42 PM, Chetan Mehrotra
 chetan.mehro...@gmail.com wrote:
 Hi,

 This is to vote for the Apache Sling Commons Log 4.0.0 release. This
 is the first release which uses Logback as the logging backend. We
 solved 20 issues in this release

 The docs are up to date at
 http://sling.apache.org/documentation/development/logging.html

 Issues fixed
 https://issues.apache.org/jira/browse/SLING/fixforversion/12324947

 Release Notes
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324947projectId=12310710

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachesling-1014/

 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

 Usage:
 sh check_staged_release.sh 1014 /tmp/sling-staging

 Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

 This vote will be open for 72 hours.

 Chetan Mehrotra

[jira] [Updated] (SLING-3421) logback initialization does not initialize correct loggers if there's a single false one

2014-02-28 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated SLING-3421:
---

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

  was:
If you configure a logger wrongly, which eg results in this stacktrace:

{code}
java.io.IOException: Bad file descriptor
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:282)
at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at 
ch.qos.logback.core.recovery.ResilientOutputStreamBase.flush(ResilientOutputStreamBase.java:79)
at 
org.apache.sling.commons.log.logback.internal.util.LoggerSpecificEncoder.doEncode(LoggerSpecificEncoder.java:46)
at 
org.apache.sling.commons.log.logback.internal.util.LoggerSpecificEncoder.doEncode(LoggerSpecificEncoder.java:34)
at 
ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:188)
at ch.qos.logback.core.FileAppender.writeOut(FileAppender.java:206)
at 
ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212)
at 
ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:175)
at 
ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103)
at 
ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88)
at 
ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:273)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:260)
at 
ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:442)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:396)
at ch.qos.logback.classic.Logger.log(Logger.java:788)
at 
org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:620)
{code}

logback

[jira] [Commented] (SLING-3421) logback initialization does not initialize correct loggers if there's a single false one

2014-02-28 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3421:


One thing to note that logging would still work and all log message with level 
INFO+ would be directed to stdout.log. So no loss of imp log message here. 

Would update the configuration logic to handle such cases if possible and 
ignore malformed message formats


 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

 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.1.5#6160)

[jira] [Resolved] (SLING-3410) Log the Logback initialization related logs to normal log for transient errors

2014-02-27 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra resolved SLING-3410.


Resolution: Fixed

Fix implemented seems to work for now. Resolving the bug

 Log the Logback initialization related logs to normal log for transient errors
 --

 Key: SLING-3410
 URL: https://issues.apache.org/jira/browse/SLING-3410
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


 Currently Sling Log would dump Logback status message to system out in case 
 some warning/error are observed in Logback initialization. If the overall 
 Logback initialization is successful then these logs should be logged as part 
 of normal logging flow



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[VOTE] Release Apache Sling Commons Log 4.0.0

2014-02-27 Thread Chetan Mehrotra

Hi,

This is to vote for the Apache Sling Commons Log 4.0.0 release. This
is the first release which uses Logback as the logging backend. We
solved 20 issues in this release

The docs are up to date at
http://sling.apache.org/documentation/development/logging.html

Issues fixed
https://issues.apache.org/jira/browse/SLING/fixforversion/12324947

Release Notes
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324947projectId=12310710

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1014/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1014 /tmp/sling-staging

Please vote to approve this release:

 [ ] +1 Approve the release
 [ ]  0 Don't care
 [ ] -1 Don't release, because ...

This vote will be open for 72 hours.

Chetan Mehrotra

Re: [VOTE] Release Apache Sling Commons Log 4.0.0

2014-02-27 Thread Chetan Mehrotra

+1 (Non Binding)

Chetan Mehrotra


On Thu, Feb 27, 2014 at 4:42 PM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
 Hi,

 This is to vote for the Apache Sling Commons Log 4.0.0 release. This
 is the first release which uses Logback as the logging backend. We
 solved 20 issues in this release

 The docs are up to date at
 http://sling.apache.org/documentation/development/logging.html

 Issues fixed
 https://issues.apache.org/jira/browse/SLING/fixforversion/12324947

 Release Notes
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324947projectId=12310710

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachesling-1014/

 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

 Usage:
 sh check_staged_release.sh 1014 /tmp/sling-staging

 Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

 This vote will be open for 72 hours.

 Chetan Mehrotra

[jira] [Resolved] (SLING-3045) [logback]Warning logs logged for 'No appenders present in context [sling] for logger'

2014-02-25 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra resolved SLING-3045.


Resolution: Fixed

In some cases such logs would be observed and cannot be avoided. These are 
handled in a better way with SLING-3410

 [logback]Warning logs logged for 'No appenders present in context [sling] for 
 logger'
 -

 Key: SLING-3045
 URL: https://issues.apache.org/jira/browse/SLING-3045
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0

 Attachments: SLING-3045.patch


 During system startup at times following warning is seen
 ---
 14:48:24,969 |-WARN in 
 Logger[org.apache.sling.installer.core.impl.OsgiInstallerImpl] - No appenders 
 present in context [sling] for logger 
 [org.apache.sling.installer.core.impl.OsgiInstallerImpl].
 ---
 Further some debug level logs are also seen during the startup



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (SLING-3364) All rotated log files are not made part of the zip provided through webconsole

2014-02-25 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra resolved SLING-3364.


Resolution: Fixed

Added support in http://svn.apache.org/r1571618

This fix would enable including files which are rotated via simple patterns 
i.e. which do not change the prefix, which do not create rotated file in 
different directory etc would get included in zip



 All rotated log files are not made part of the zip provided through webconsole
 --

 Key: SLING-3364
 URL: https://issues.apache.org/jira/browse/SLING-3364
 Project: Sling
  Issue Type: Bug
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: Commons Log 4.0.0


 Sling Log bundle so far provided ability to dump all the rotated log files as 
 part of zip generated via Felix WebConsole support. With shift to Logback its 
 not straightforward to  determine location of all rotated logs files e.g. one 
 created via config xml 
 Need to find a way to determine all such rotated log files and dump them. 
 1. Dump all files from log folder
 2. Dump only the file created via OSGi configuration as we know the pattern 
 used and then use a logic similar to earlier version to determine all such 
 files. For files generated by other appenders (one configured via xml) its 
 not possible to determine the pattern post initialization



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (SLING-3410) Log the Logback initialization related logs to normal log for transient errors

Chetan Mehrotra created SLING-3410:
--

 Summary: Log the Logback initialization related logs to normal log 
for transient errors
 Key: SLING-3410
 URL: https://issues.apache.org/jira/browse/SLING-3410
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor


Currently Sling Log would dump Logback status message to system out in case 
some warning/error are observed in Logback initialization. If the overall 
Logback initialization is successful then these logs should be logged as part 
of normal logging flow



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (SLING-3410) Log the Logback initialization related logs to normal log for transient errors


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

Chetan Mehrotra commented on SLING-3410:


Added support in r1571283 and r1571284

Now in case transient issues are observed in Logback status then those logs 
would be routed to normal logs and a marker '\*Logback Status\*' would be added 
to line as shown below.

In case Logback was not successfully initialized then this marker would not be 
added. 

{noformat}
19:01:05,627 *Logback Status* |-WARN in 
org.apache.sling.commons.log.logback.internal.LogbackManager@6563068f - 
Context: sling reloaded.
19:01:05,631 *Logback Status* |-INFO in 
ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not 
set
{noformat}

 Log the Logback initialization related logs to normal log for transient errors
 --

 Key: SLING-3410
 URL: https://issues.apache.org/jira/browse/SLING-3410
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


 Currently Sling Log would dump Logback status message to system out in case 
 some warning/error are observed in Logback initialization. If the overall 
 Logback initialization is successful then these logs should be logged as part 
 of normal logging flow



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (SLING-3410) Log the Logback initialization related logs to normal log for transient errors


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

Chetan Mehrotra updated SLING-3410:
---

Fix Version/s: Commons Log 4.0.0

 Log the Logback initialization related logs to normal log for transient errors
 --

 Key: SLING-3410
 URL: https://issues.apache.org/jira/browse/SLING-3410
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


 Currently Sling Log would dump Logback status message to system out in case 
 some warning/error are observed in Logback initialization. If the overall 
 Logback initialization is successful then these logs should be logged as part 
 of normal logging flow



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (SLING-3411) Enable configuring the maxCallerDataDepth in Logback LoggerContext

Chetan Mehrotra created SLING-3411:
--

 Summary: Enable configuring the maxCallerDataDepth in Logback 
LoggerContext
 Key: SLING-3411
 URL: https://issues.apache.org/jira/browse/SLING-3411
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


Logback support dumping the caller statcktrace [1] as part of the log message. 
By default it computes upto 7 frames. However in case of Sling most of the time 
these 7 frames are consumed by Sling framework classes itself

To see application code frames this limits needs to be increased

[1] http://logback.qos.ch/manual/layouts.html#caller



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (SLING-3275) Add Buffered Logging Configuration in Apache Sling Logging Logger


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

Chetan Mehrotra resolved SLING-3275.


Resolution: Fixed

Added support in [r1571319|http://svn.apache.org/r1571319]

LogWriter config now has option to enable buffered logging configured via 
'org.apache.sling.commons.log.file.buffered' property

 Add Buffered Logging Configuration in Apache Sling Logging Logger
 ---

 Key: SLING-3275
 URL: https://issues.apache.org/jira/browse/SLING-3275
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor

 Logback supports buffered logging [1]. As of now it can be used directly by 
 configuring the appender via Logback xml file [2]. To simplify its usage we 
 should expose a config as part of OSGi config
 [1] http://logback.qos.ch/manual/encoders.html#immediateFlush
 [2] 
 http://sling.apache.org/documentation/development/logging.html#wzxhzdk13wzxhzdk14configuring-osgi-appenders-in-the-logback-config



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (SLING-3275) Add Buffered Logging Configuration in Apache Sling Logging Logger


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

Chetan Mehrotra updated SLING-3275:
---

Fix Version/s: Commons Log 4.0.0

 Add Buffered Logging Configuration in Apache Sling Logging Logger
 ---

 Key: SLING-3275
 URL: https://issues.apache.org/jira/browse/SLING-3275
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


 Logback supports buffered logging [1]. As of now it can be used directly by 
 configuring the appender via Logback xml file [2]. To simplify its usage we 
 should expose a config as part of OSGi config
 [1] http://logback.qos.ch/manual/encoders.html#immediateFlush
 [2] 
 http://sling.apache.org/documentation/development/logging.html#wzxhzdk13wzxhzdk14configuring-osgi-appenders-in-the-logback-config



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (SLING-3411) Enable configuring the maxCallerDataDepth in Logback LoggerContext


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

Chetan Mehrotra resolved SLING-3411.


Resolution: Fixed

Added support in [r1571318|http://svn.apache.org/r1571318].

One can set the maxCallerDepth by configuring the 'Sling Commons Logging' 
config 

 Enable configuring the maxCallerDataDepth in Logback LoggerContext
 --

 Key: SLING-3411
 URL: https://issues.apache.org/jira/browse/SLING-3411
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


 Logback support dumping the caller statcktrace [1] as part of the log 
 message. By default it computes upto 7 frames. However in case of Sling most 
 of the time these 7 frames are consumed by Sling framework classes itself
 To see application code frames this limits needs to be increased
 [1] http://logback.qos.ch/manual/layouts.html#caller



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (SLING-3340) Warnings on startup regarding no-op loggers

2014-02-23 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3340:


Updated the Slf4j related bundle versions in http://svn.apache.org/r1571156

 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.1.5#6160)

[jira] [Commented] (SLING-3383) Non stopping thread in AbstractJobQueue causes classloader leak

2014-02-19 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3383:


Not sure on easy way. You can possibly try refreshing the Event bundle multiple 
times and then use the Classloader Leak Detector (SLING-3359) to see if it 
highlights any leak

 Non stopping thread in AbstractJobQueue causes classloader leak 
 

 Key: SLING-3383
 URL: https://issues.apache.org/jira/browse/SLING-3383
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Event 3.3.4
Reporter: Chetan Mehrotra
Assignee: Carsten Ziegeler
 Fix For: Event 3.3.6


 While analyzing heap dump for classloader leaks using script [1] following 
 possible leak was reported 
 {noformat}
   org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
Following are few of the live paths found
Live path
   
 org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
   java.lang.Thread@0x12547e888
   [Ljava.lang.Thread;@0x124f18f58
   java.lang.ThreadGroup@0x123346e80
   java.lang.Thread@0x126635c48
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x13161da50
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253e0
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253c0
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253a0
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a128c90
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c198
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c178
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c158
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c138
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c118
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0f8
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0d8
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0b8
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c098
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c078
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c058
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e30
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e10
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007df0
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007dd0
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007db0
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d90
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d70
   
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@0x125d2c968
   java.lang.Thread@0x126637b00
   java.util.concurrent.ThreadPoolExecutor$Worker@0x126637b68
   java.util.HashMap$Entry@0x126640058
   [Ljava.util.HashMap$Entry;@0x12663fde8
   java.util.HashMap@0x125d2ca08
   java.util.HashSet@0x125d2c9f8
   java.util.concurrent.ThreadPoolExecutor@0x125d2c8a0
   
 org.apache.sling.commons.threads.impl.DefaultThreadPool@0x125d2c7b0 [*]
   
 org.apache.sling.commons.threads.impl.ThreadPoolFacade@0x125d2c798 [*]
   
 org.apache.sling.commons.threads.impl.DefaultThreadPoolManager$Entry@0x125d535d0
  [*]
   java.util.HashMap$Entry@0x125d535b0
   [Ljava.util.HashMap$Entry;@0x124147940
   java.util.HashMap@0x124147910
   
 org.apache.sling.commons.threads.impl.DefaultThreadPoolManager@0x124146e50 [*]
   org.apache.felix.framework.ServiceRegistrationImpl@0x12414f3e8
   org.apache.sling.commons.threads.impl.Activator@0x12414f3d0 [*]
   org.apache.felix.framework.BundleImpl@0x122809f78
   org.apache.felix.framework.ServiceRegistrationImpl@0x1241e8c40
   class org.apache.sling.commons.threads.impl.WebConsolePrinter
   
 org.apache.sling.commons.threads.impl.WebConsolePrinter@0x1241e8a70 [*]
 {noformat}
 It appears that the thread created

Re: Installation and start order for logging (was: [jira] [Commented] (SLING-3386) Enable support starting bundle in custom oreder at start level 1)

2014-02-17 Thread Chetan Mehrotra

Hi Carsten,

To summarize.

1. Need to clear the start level 1 and keep only logging related
bundles and framework fragments at that level. Move all other bundles
to Start Level 2
2. For upgraded system we implement a new Bootstrap command say
ChangeStartLevelCommand. This would change the start level of bundle
from a to b. This would then be used to implement #1
3. For new system the list.xml needs to be updated

I would be trying out #2 and come back to the list on how it works in
practice. It might take some time given some other work in progress

Chetan Mehrotra


On Mon, Feb 17, 2014 at 5:37 PM, Carsten Ziegeler cziege...@apache.org wrote:
 Can someone please summarize what exactly is proposed, especially for
 SLING-3388 ?

 Thanks
 Carsten


 2014-02-12 11:14 GMT+01:00 Felix Meschberger fmesc...@adobe.com:


 Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra chetan.mehro...@gmail.com
 :

  For now I think we can keep the implementation simple. For example in
  current case we do not have to change start level for Fragments and
  Slf4j related bundle. So need to change start level of some listed
  bundles only
 
  startlevel 20 40
  Do not see a requirement to move all existing bundle to different level

 ok

 
  startlevel .* 2
  startlevel .*\.installer\..* 2
 
  For now would like to keep it simple to
 
  changestartlevel symbolic name:version? target level

 I still would suggest to support a version range, though.

 
  If need arises for more advance usecase then they can be added later
 
  Created  SLING-3388 for the same.

 Thanks
 Felix

  Chetan Mehrotra
 
 
  On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger fmesc...@adobe.com
 wrote:
  Hi
 
  Am 12.02.2014 um 09:58 schrieb Felix Meschberger fmesc...@adobe.com:
 
  Hi
 
  Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra 
 chetan.mehro...@gmail.com:
 
  On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger 
 fmesc...@adobe.com wrote:
  Hence, I would really prefer to get our start levels straight and
 reserve 1 to logging and move the install stuff to 2.
 
  You never allow to take the short cut :)
 
  I fight special cases as long as possible, yes :-)
 
 
  Okie thinking about tackling the real problem of moving existing
  bundle to start level  1 I can think of following approach
 
  1. Currently we are not using startlevel 2,3,4
 
  Yes.
 
 
  2. Introduce a new command ChangeStartLevelCommand which would use the
  StartLevel service to change the start level of non fragment bundle
  having existing level 1. or it can be generic to change the level from
  a - b.
 
  One thing to decide at this step is that command should work on
  explicit parameters e.g. change start level only for list bundles
  OR Is an automatic one where it would find all bundles at 1 and change
  levels for non fragment and non logging related bundle
 
  You mean a command for  bootstrap.txt like uninstall ? Sounds good.
 
  This command could take a regular expression for symbolic names and
 optionally a version range to select bundles and then a target start level.
 Optionally it could take a source start level and a target start level to
 move all bundles with the source start level to the target start level
 
  EBND definition:
 
   StartLevelCommand = startlevel Source TargetStartLevel .
   Source = SourceStartLevel
  | Bundle .
   SourceStartLevel = numeric startlevel value  0 .
   TargetStartLevel = numeric startlevel value  0 .
   Bundle = BundleSymbolicName VersionRange .
   BundleSymbolicName = regular expression match for bundle symbolic name
 .
   VersionRange = OSGi version range to match bundles .
 
  Examples:
 
   # move all bundles currently set to startlevel 20 to startlevel 40
   startlevel 20 40
 
   # move all bundles to startlevel 2
   startlevel .* 2
 
   # move installer bundles to startlevel 2
   startlevel .*\.installer\..* 2
 
  Regards
  Felix
 
 
  +1
 
 
  3. Change the list.xml and move non fragment bundle (except loggging
  related) to level 2
 
  +1
 
 
  Would this work or is something missing here?
 
  Sounds good to me.
 
  Regards
  Felix
 
 
  Chetan Mehrotra
 
 




 --
 Carsten Ziegeler
 cziege...@apache.org

Enabling Github integration for Apache Sling Infra

2014-02-16 Thread Chetan Mehrotra

Saw this news regarding Github and Apache infra integration [1]. I
would be good if we get these features enabled for Sling.

thoughts?

Chetan Mehrotra
[1] https://blogs.apache.org/infra/entry/improved_integration_between_apache_and

Re: Installation and start order for logging (was: [jira] [Commented] (SLING-3386) Enable support starting bundle in custom oreder at start level 1)

2014-02-12 Thread Chetan Mehrotra

On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger fmesc...@adobe.com wrote:
 Hence, I would really prefer to get our start levels straight and reserve 1 
 to logging and move the install stuff to 2.

You never allow to take the short cut :)

Okie thinking about tackling the real problem of moving existing
bundle to start level  1 I can think of following approach

1. Currently we are not using startlevel 2,3,4

2. Introduce a new command ChangeStartLevelCommand which would use the
StartLevel service to change the start level of non fragment bundle
having existing level 1. or it can be generic to change the level from
a - b.

One thing to decide at this step is that command should work on
explicit parameters e.g. change start level only for list bundles
OR Is an automatic one where it would find all bundles at 1 and change
levels for non fragment and non logging related bundle

3. Change the list.xml and move non fragment bundle (except loggging
related) to level 2

Would this work or is something missing here?

Chetan Mehrotra

[jira] [Updated] (SLING-3388) Enable changing of bundle start level in upgrade

2014-02-12 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated SLING-3388:
---

Description: 
For certain cases we need to change the start level of existing bundles. For 
example to properly solve SLING-3340 we need to move all non log related 
bundles to Start level  1

Currently the Launchpad bootstrap support custom commands which are executed 
upon system start. For now they are used to uninstall bundles.

On similar like we can have changestartlevel command to change the start level 
of bundle

Refer to http://markmail.org/thread/2b5m7hq22p7b5vq3 for more details


  was:
For certain cases we need to change the start level of existing bundles. For 
example to properly solve SLING-3340 we need to move all non log related 
bundles to Start level  1

Currently the Launchpad bootstrap support custom commands which are executed 
upon system start. For now they are used to uninstall bundles.

On similar like we can have changestartlevel command to change the start level 
of bundle




 Enable changing of bundle start level in upgrade
 

 Key: SLING-3388
 URL: https://issues.apache.org/jira/browse/SLING-3388
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Affects Versions: Launchpad Base 2.5.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra

 For certain cases we need to change the start level of existing bundles. For 
 example to properly solve SLING-3340 we need to move all non log related 
 bundles to Start level  1
 Currently the Launchpad bootstrap support custom commands which are executed 
 upon system start. For now they are used to uninstall bundles.
 On similar like we can have changestartlevel command to change the start 
 level of bundle
 Refer to http://markmail.org/thread/2b5m7hq22p7b5vq3 for more details



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (SLING-3386) Enable support starting bundle in custom oreder at start level 1

2014-02-12 Thread Chetan Mehrotra (JIRA)

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

Chetan Mehrotra resolved SLING-3386.

Resolution: Won't Fix

The original issue would now be addressed via SLING-3388

Enable support starting bundle in custom oreder at start level 1

Key: SLING-3386
URL: https://issues.apache.org/jira/browse/SLING-3386
Project: Sling
Issue Type: Improvement
Components: Launchpad
Affects Versions: Launchpad Base 2.5.0
Reporter: Chetan Mehrotra
Priority: Minor
Attachments: SLING-3386.patch

By default OSGi framework does not define the order in which bundles would be
started in a given start level. The only way is to use to use start level.
However in case of bundle like Logging its desriable that Log bundle is the
first bundle to start in the system such that it does not miss any log
message. The problem is described in more details at SLING-3340.
As Sling uses Felix framework by default it is possible to control the start
order by controlling the order in which bundles are installed on the
framework. As per current Felix Framework implementation [1] bundle within
same start level are started in the order of bundleId.
The way patch works is
1. Bundle which start at start level 1 can define a header
'X-Sling-Start-Order' to provide a start order hint. Lower the level then
earlier the bundle would be started
2. BootstrapInstaller would sort the files obtained from directly listing
based on this header.
3. Sorted list would be used to install the bundles
I understand that this is a very much implementation specific fix and might
not work if Felix changes the internal logic. But then the feature is meant
to be used in best effort basis!!.
[1]
https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L4873

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (SLING-3386) Enable support starting bundle in custom oreder at start level 1

2014-02-11 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created SLING-3386:
--

Summary: Enable support starting bundle in custom oreder at start
level 1
Key: SLING-3386
URL: https://issues.apache.org/jira/browse/SLING-3386
Project: Sling
Issue Type: Improvement
Components: Launchpad
Affects Versions: Launchpad Base 2.5.0
Reporter: Chetan Mehrotra
Priority: Minor

By default OSGi framework does not define the order in which bundles would be
started in a given start level. The only way is to use to use start level.

However in case of bundle like Logging its desriable that Log bundle is the
first bundle to start in the system such that it does not miss any log message.
The problem is described in more details at SLING-3340.

As Sling uses Felix framework by default it is possible to control the start
order by controlling the order in which bundles are installed on the framework.
As per current Felix Framework implementation [1] bundle within same start
level are started in the order of bundleId.

The way patch works is

1. Bundle which start at start level 1 can define a header
'X-Sling-Start-Order' to provide a start order hint. Lower the level then
earlier the bundle would be started
2. BootstrapInstaller would sort the files obtained from directly listing based
on this header.
3. Sorted list would be used to install the bundles

I understand that this is a very much implementation specific fix and might not
work if Felix changes the internal logic. But then the feature is meant to be
used in best effort basis!!.

[1]
https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L4873

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (SLING-3386) Enable support starting bundle in custom oreder at start level 1

2014-02-11 Thread Chetan Mehrotra (JIRA)

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

Chetan Mehrotra updated SLING-3386:
---

Attachment: SLING-3386.patch

Patch as per approach explained above

Enable support starting bundle in custom oreder at start level 1

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (SLING-3386) Enable support starting bundle in custom oreder at start level 1

2014-02-11 Thread Chetan Mehrotra (JIRA)

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

Chetan Mehrotra commented on SLING-3386:

bq. treat logging specially in that we define a new folder which is handled
first by the bootstrap installer

The patch takes a bit different route but aim is same i.e. enable influencing
the order in which bootstrap installer would install bundle files

bq. move all non-logging bundles from startlevel 1 to startlevel 2

That would be the proper and stable fix. However it would cause issue in case
of upgrades as we would have to change the bundle start levels. Such a change
would require lot more effort and we would need to ensure that all cases are
handled properly. Thats the reason I am taking the proposed approach as it is a
small change in current startup process. And yes this fix would also not handle
the upgrade scenario

bq. The BundleStartLevelSorter.parseStartOrder may throw an exception if the
header happens to not be an Integer.

I thought about that but then I preferred to have a fail fast approach where if
there is a problem in value then it gets noticed right away.

bq. Also every reference to start order (or even start level in that method)
would have to be rephrased to install order. Also, I would call the header
X-Sling-Bootstrap-Install-Order to indicate it is just the bootstrap
installer respecting this as the installation order.

Ack. Would change that.

Enable support starting bundle in custom oreder at start level 1

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (SLING-3045) [logback]Warning logs logged for 'No appenders present in context [sling] for logger'

2014-02-10 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3045:


Updated the logic in [r1566597|http://svn.apache.org/r1566597] to be more robust

 [logback]Warning logs logged for 'No appenders present in context [sling] for 
 logger'
 -

 Key: SLING-3045
 URL: https://issues.apache.org/jira/browse/SLING-3045
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0

 Attachments: SLING-3045.patch


 During system startup at times following warning is seen
 ---
 14:48:24,969 |-WARN in 
 Logger[org.apache.sling.installer.core.impl.OsgiInstallerImpl] - No appenders 
 present in context [sling] for logger 
 [org.apache.sling.installer.core.impl.OsgiInstallerImpl].
 ---
 Further some debug level logs are also seen during the startup



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (SLING-3322) Export additional mozilla rhino packages

2014-02-10 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3322:


Applied the patch in [566989|http://svn.apache.org/r1]. Also updated the 
package exports to have versions

Earlier
{noformat}
  org.apache.sling.scripting.javascript 
  org.mozilla.javascript   
{noformat}

Now
{noformat}
  org.apache.sling.scripting.javascript {version=0.1.0, imported-as=[0.1,1)}
  org.mozilla.classfile {version=0.0.0.1_7R4, 
imported-as=[0.0,1)}
  org.mozilla.javascript{version=0.0.0.1_7R4}
  org.mozilla.javascript.debug  {version=0.0.0.1_7R4, 
imported-as=[0.0,1)}
{noformat}

 Export additional  mozilla rhino packages
 -

 Key: SLING-3322
 URL: https://issues.apache.org/jira/browse/SLING-3322
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting JavaScript 2.0.12
Reporter: Rohit Kumar
Priority: Minor
 Fix For: Scripting JavaScript 2.0.14

 Attachments: Sling-3322.patch


 Our project requires following rhino packages:
 org.mozilla.classfile,
 org.mozilla.javascript.debug
 It would be better if Sling exposes them.
 Attaching patch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (SLING-3322) Export additional mozilla rhino packages

2014-02-10 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra resolved SLING-3322.


   Resolution: Fixed
Fix Version/s: Scripting JavaScript 2.0.14
 Assignee: Chetan Mehrotra

 Export additional  mozilla rhino packages
 -

 Key: SLING-3322
 URL: https://issues.apache.org/jira/browse/SLING-3322
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting JavaScript 2.0.12
Reporter: Rohit Kumar
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Scripting JavaScript 2.0.14

 Attachments: Sling-3322.patch


 Our project requires following rhino packages:
 org.mozilla.classfile,
 org.mozilla.javascript.debug
 It would be better if Sling exposes them.
 Attaching patch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (SLING-3383) Non stopping thread in AbstractJobQueue causes classloader leak

2014-02-09 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created SLING-3383:
--

 Summary: Non stopping thread in AbstractJobQueue causes 
classloader leak 
 Key: SLING-3383
 URL: https://issues.apache.org/jira/browse/SLING-3383
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Event 3.3.4
Reporter: Chetan Mehrotra


While analyzing heap dump for classloader leaks using script [1] following 
possible leak was reported 

{noformat}
org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
 Following are few of the live paths found
 Live path

org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
java.lang.Thread@0x12547e888
[Ljava.lang.Thread;@0x124f18f58
java.lang.ThreadGroup@0x123346e80
java.lang.Thread@0x126635c48

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x13161da50

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253e0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253c0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253a0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a128c90

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c198

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c178

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c158

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c138

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c118

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0f8

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0d8

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0b8

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c098

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c078

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c058

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e30

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e10

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007df0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007dd0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007db0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d90

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d70

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@0x125d2c968
java.lang.Thread@0x126637b00
java.util.concurrent.ThreadPoolExecutor$Worker@0x126637b68
java.util.HashMap$Entry@0x126640058
[Ljava.util.HashMap$Entry;@0x12663fde8
java.util.HashMap@0x125d2ca08
java.util.HashSet@0x125d2c9f8
java.util.concurrent.ThreadPoolExecutor@0x125d2c8a0

org.apache.sling.commons.threads.impl.DefaultThreadPool@0x125d2c7b0 [*]

org.apache.sling.commons.threads.impl.ThreadPoolFacade@0x125d2c798 [*]

org.apache.sling.commons.threads.impl.DefaultThreadPoolManager$Entry@0x125d535d0
 [*]
java.util.HashMap$Entry@0x125d535b0
[Ljava.util.HashMap$Entry;@0x124147940
java.util.HashMap@0x124147910

org.apache.sling.commons.threads.impl.DefaultThreadPoolManager@0x124146e50 [*]
org.apache.felix.framework.ServiceRegistrationImpl@0x12414f3e8
org.apache.sling.commons.threads.impl.Activator@0x12414f3d0 [*]
org.apache.felix.framework.BundleImpl@0x122809f78
org.apache.felix.framework.ServiceRegistrationImpl@0x1241e8c40
class org.apache.sling.commons.threads.impl.WebConsolePrinter

org.apache.sling.commons.threads.impl.WebConsolePrinter@0x1241e8a70 [*]
{noformat}

It appears that the thread created in AbstractJobQueue [2] is not interrupting 
the thread upon deactivation/shutdown. So the thread remains blocked in waiting 
(in take method of various implementations) and never gets a chance to check 
for the running flag. A better way would be to handle the InterruptedException 
properly [3] and exit the thread as part of InterruptedException exception 
handling

[1] https://gist.github.com/chetanmeh/8860776 
[2] 
https://github.com/apache/sling/blob/trunk

[jira] [Commented] (SLING-3359) Classloader Leak Detector Console Tab

2014-02-09 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3359:


As an extension one can found out possible leak suspects (actual root cause) 
using the script provided at [1]. This script can be executed as part of jHat 
OQL [2]. The script dumps the report printing out the live path of object which 
is preventing it from getting GC. Below is a portion of the report generated 
from one of the heap dumps analyzed

{noformat}
org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
 Following are few of the live paths found
 Live path

org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
java.lang.Thread@0x12547e888
[Ljava.lang.Thread;@0x124f18f58
java.lang.ThreadGroup@0x123346e80
java.lang.Thread@0x126635c48

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x13161da50

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253e0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253c0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253a0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a128c90

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c198

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c178

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c158

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c138

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c118

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0f8

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0d8

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0b8

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c098

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c078

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c058

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e30

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e10

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007df0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007dd0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007db0

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d90

java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d70

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@0x125d2c968
java.lang.Thread@0x126637b00
java.util.concurrent.ThreadPoolExecutor$Worker@0x126637b68
java.util.HashMap$Entry@0x126640058
[Ljava.util.HashMap$Entry;@0x12663fde8
java.util.HashMap@0x125d2ca08
java.util.HashSet@0x125d2c9f8
java.util.concurrent.ThreadPoolExecutor@0x125d2c8a0

org.apache.sling.commons.threads.impl.DefaultThreadPool@0x125d2c7b0 [*]

org.apache.sling.commons.threads.impl.ThreadPoolFacade@0x125d2c798 [*]

org.apache.sling.commons.threads.impl.DefaultThreadPoolManager$Entry@0x125d535d0
 [*]
java.util.HashMap$Entry@0x125d535b0
[Ljava.util.HashMap$Entry;@0x124147940
java.util.HashMap@0x124147910

org.apache.sling.commons.threads.impl.DefaultThreadPoolManager@0x124146e50 [*]
org.apache.felix.framework.ServiceRegistrationImpl@0x12414f3e8
org.apache.sling.commons.threads.impl.Activator@0x12414f3d0 [*]
org.apache.felix.framework.BundleImpl@0x122809f78
org.apache.felix.framework.ServiceRegistrationImpl@0x1241e8c40
class org.apache.sling.commons.threads.impl.WebConsolePrinter

org.apache.sling.commons.threads.impl.WebConsolePrinter@0x1241e8a70 [*]
{noformat}

Logged SLING-3383 based on above. 

[1] https://gist.github.com/chetanmeh/8860776
[2] http://docs.oracle.com/javase/6/docs/technotes/tools/share/jhat.html

 Classloader Leak Detector Console Tab
 -

 Key: SLING-3359
 URL: https://issues.apache.org/jira/browse/SLING-3359
 Project: Sling
  Issue Type: New Feature
  Components: Console

[jira] [Commented] (SLING-3359) Classloader Leak Detector Console Tab

2014-02-05 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3359:


Also opened enhancement bug FELIX-4418 to enable some support from framework in 
identifying such leaky classloaders while doing heap dump analysis

 Classloader Leak Detector Console Tab
 -

 Key: SLING-3359
 URL: https://issues.apache.org/jira/browse/SLING-3359
 Project: Sling
  Issue Type: New Feature
  Components: Console
Reporter: Ian Boston
Assignee: Chetan Mehrotra
 Attachments: 
 org.apache.sling.extensions.classloader-leak-detector-0.0.1-SNAPSHOT-src.zip


 Chetan has created a classloader leak detector console at 
 https://github.com/chetanmeh/sling-leak-detector. It would be really good to 
 get this into the contrib are and released so that consumers of Sling can use 
 it to locate code in bundles that is leaking classloaders.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (SLING-3340) Warnings on startup regarding no-op loggers

2014-02-05 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on SLING-3340:


The bug has been fixed in Slf4j and a new release 1.7.6 with the fix is 
available [1]

[1] http://www.slf4j.org/news.html

 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.1.5#6160)

Re: [logging] warnings on startup regarding no-op loggers

2014-02-05 Thread Chetan Mehrotra

Just an update. The issue has now been fixed on Slf4j side and a new
release 1.7.6 was made which contains the fix. So this completes the
#3 approach mentioned previously.

With this there is just a small issue that while Slf4j is getting
initialized the log message would get lost as at that time NOP Loggers
are used. Once initialization is complete the log message from such
loggers would be handled in default way. To fix this we would need to
control the startup order and get the Commons Log bundle started
first.
Chetan Mehrotra


On Wed, Jan 29, 2014 at 4:47 PM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
 On Wed, Jan 29, 2014 at 4:39 PM, Carsten Ziegeler cziege...@apache.org 
 wrote:
 never ever rely on that.
 Agreed. But ...

And for B we would need changes at least in the launchpad - for A we just
 fix slf4j
 Change in our code is in our control and easy to do without incurring
 any penalty. Fix in Slf4j might take time. So its like a workaround
 untill proper fix is done.

 Chetan Mehrotra

[jira] [Resolved] (SLING-3341) [logback] Race condition in configuring Logback


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

Chetan Mehrotra resolved SLING-3341.


Resolution: Fixed

issue has not surfaced/reported again post this fix. Current fixes looks 
sufficient. Closing it for now

 [logback] Race condition in configuring Logback
 ---

 Key: SLING-3341
 URL: https://issues.apache.org/jira/browse/SLING-3341
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra

 Current way to configure Logback works like as below
 1. Any change in config finally leads a call to 
 org.apache.sling.commons.log.logback.internal.LogbackManager#configChanged
 2. The config change is not done in concurrent way. A thread must acquire the 
 {{resetLock}} to trigger  Logback reset. If this lock cannot be acquired then 
 it just sets a flag {{configChanged}} to true. The Logback reset job upon 
 completion checks {{configChanged}} . if found to be true then it reschedules 
 the job to load Logback again
 In current impl there is a small race condition where its possible that 
 Logback reset job does not see the {{configChanged}} flag and hence Logback 
 does not get reinitialized and is configured with stale config



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [osgi] Using Inventory API in Commons Log

2014-02-03 Thread Chetan Mehrotra

Thanks for the clarification Felix!

Just to confirm though ... if Inventory bundle is later
patched/refreshed it would then lead to refresh of Commons Log bundle
also. Would that mean framework would be bought down to level 1 and
restarted again
Chetan Mehrotra


On Mon, Feb 3, 2014 at 2:21 PM, Felix Meschberger fmesc...@adobe.com wrote:
 Hi

 Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra chetan.mehro...@gmail.com:

 Hi,

 For SLING-3264 I was thinking to provide Inventory integration in
 Commons Logs. However the Commons Log bundle starts at level 1 while
 the Inventory bundle starts at Level 5. The log bundle would use the
 ServiceFactory approach to expose the Inventory service and would not
 have required dependency on Inventory API.

 So just wanted to confirm that would it be fine to depend on classes
 from a bundle which starts at later start level or not?

 Sure. This is what we are using ServiceFactory and dynamic/delayed import all 
 over places. See for example the Configuration Admin binding the Apache Felix 
 SCR bundle.

 So, what seems to boild down to kind of a best practice is to:

   * use ServiceFactory for optional services
   * use Import-Package with resolution:=optional to have
   static wiring if possible
   * use DynamicImport-Package to have dynamic wiring
   on-demand

 It is just very important to thouroughly test this to not get inadvertend 
 ClassNotFoundExceptions, for example if the optional classes appear in the 
 method signature of a required class (see the 
 ResourceResolverActivator.getFeaures() method which returns Object to work 
 around this issue).

 Regards
 Felix

Re: [osgi] Using Inventory API in Commons Log

2014-02-03 Thread Chetan Mehrotra

On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger fmesc...@adobe.com wrote:
 So the question really is: what happens to the logger instances held by the 
 bundles 

Before answering that I need to confirm would a new classloader be
created for Commons Log upon package refresh? Probably yes then it
that case existing Logger instances would be referring to old
classloader. The other bundle would be bound to Sl4j API so they would
not be refreshed but there logger instances would be referring to
Logback provided classes.

So one should probably avoid external dependency for a bundle like Commons Log?

Chetan Mehrotra

Re: [osgi] Using Inventory API in Commons Log

2014-02-03 Thread Chetan Mehrotra

 Yes, that probably is the consequence and we should refrain from adding 
 Inventory API binding -- unless the commons log bundle exports the inventory 
 API itself

Well I required Inventory API to expose the logback state in JSON
format (not that strong requirement though). Currently WebConsole
supports Configuration Printer which do not explicitly implement
Inventory API i.e. it supports any class which provides a method like
[1] with some service properties. However that mode looks like does
not support json mode. If it can support that then there is no string
need for using Inventory API

public void printConfiguration(PrintWriter printWriter)
Chetan Mehrotra


On Mon, Feb 3, 2014 at 3:11 PM, Felix Meschberger fmesc...@adobe.com wrote:
 Hi

 Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra chetan.mehro...@gmail.com:

 On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger fmesc...@adobe.com wrote:
 So the question really is: what happens to the logger instances held by the 
 bundles 

 Before answering that I need to confirm would a new classloader be
 created for Commons Log upon package refresh? Probably yes then it
 that case existing Logger instances would be referring to old
 classloader. The other bundle would be bound to Sl4j API so they would
 not be refreshed but there logger instances would be referring to
 Logback provided classes.

 So one should probably avoid external dependency for a bundle like Commons 
 Log?

 Yes, that probably is the consequence and we should refrain from adding 
 Inventory API binding -- unless the commons log bundle exports the inventory 
 API itself...

 On the other hand: considering both the Inventory and the Web Console API to 
 be crucial, it might be conceivable to create API only bundles for these...

 Regards
 Felix


 Chetan Mehrotra

[jira] [Created] (SLING-3363) Make Logback status part of Configuration Printer output

Chetan Mehrotra created SLING-3363:
--

 Summary: Make Logback status part of Configuration Printer output
 Key: SLING-3363
 URL: https://issues.apache.org/jira/browse/SLING-3363
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor


Sling Log Configuration Printer currently dump the content of various Log file 
as part of output. It would be good to have the Logback status also part of 
same output



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (SLING-3363) Make Logback status part of Configuration Printer output


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

Chetan Mehrotra resolved SLING-3363.


   Resolution: Fixed
Fix Version/s: Commons Log 4.0.0

Done with http://svn.apache.org/r1563820

 Make Logback status part of Configuration Printer output
 

 Key: SLING-3363
 URL: https://issues.apache.org/jira/browse/SLING-3363
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Commons Log 4.0.0


 Sling Log Configuration Printer currently dump the content of various Log 
 file as part of output. It would be good to have the Logback status also part 
 of same output



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [osgi] Using Inventory API in Commons Log

2014-02-03 Thread Chetan Mehrotra

On Mon, Feb 3, 2014 at 3:50 PM, Felix Meschberger fmesc...@adobe.com wrote:
 Well, officially, ConfigurationPrinter does not support JSON, but you can 
 write JSON as TXT output

I can ... but rendering JSON in TXT does not look pretty!!. Probably
it can be officially made to support json.


Chetan Mehrotra

[jira] [Created] (SLING-3364) All rotated log files are not made part of the zip provided through webconsole