[jira] [Created] (SLING-4223) make Content Loader extensible to support new import formats
Oliver Lietz created SLING-4223:
---
Summary: make Content Loader extensible to support new import
formats
Key: SLING-4223
URL: https://issues.apache.org/jira/browse/SLING-4223
Project: Sling
Issue Type: Improvement
Components: JCR
Affects Versions: JCR ContentLoader 2.1.10
Reporter: Oliver Lietz
The current Content Loader supports a basic set of import formats which are
identified by extension: {{.xml}}, {{.jcr.xml}}, {{.json}}, {{.jar}} and
{{.zip}}.
There is a [user
request|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3cd0a6198c.20fbeb%25bruce.e...@nextissuemedia.com%3e]
to support custom formats like Adobe Folio and [some ideas how to
implement|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3ca2ab572f-fa83-4ae2-806e-49cce87b9...@adobe.com%3e]:
* we create a new org.apache.sling.contentloader.reader package to be exported
at version 1.0
* move the ContentCreator (@ProviderType) and ContentReader (@ConsumerType) to
that new package
* convert the BaseImportLoader into a standalone ContentReader service holder
used by the DefaultContentImporter and ContentLoaderService components.
* For the ContentReader service interface we define service registration
properties for the service to expose the file name extension (and maybe content
type) the reader supports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4223) make Content Loader extensible to support new import formats
[
https://issues.apache.org/jira/browse/SLING-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lietz updated SLING-4223:
Fix Version/s: JCR ContentLoader 2.2.0
make Content Loader extensible to support new import formats
Key: SLING-4223
URL: https://issues.apache.org/jira/browse/SLING-4223
Project: Sling
Issue Type: Improvement
Components: JCR
Affects Versions: JCR ContentLoader 2.1.10
Reporter: Oliver Lietz
Fix For: JCR ContentLoader 2.2.0
The current Content Loader supports a basic set of import formats which are
identified by extension: {{.xml}}, {{.jcr.xml}}, {{.json}}, {{.jar}} and
{{.zip}}.
There is a [user
request|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3cd0a6198c.20fbeb%25bruce.e...@nextissuemedia.com%3e]
to support custom formats like Adobe Folio and [some ideas how to
implement|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3ca2ab572f-fa83-4ae2-806e-49cce87b9...@adobe.com%3e]:
* we create a new org.apache.sling.contentloader.reader package to be
exported at version 1.0
* move the ContentCreator (@ProviderType) and ContentReader (@ConsumerType)
to that new package
* convert the BaseImportLoader into a standalone ContentReader service holder
used by the DefaultContentImporter and ContentLoaderService components.
* For the ContentReader service interface we define service registration
properties for the service to expose the file name extension (and maybe
content type) the reader supports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3533) improve error handling and logging in content loader
[ https://issues.apache.org/jira/browse/SLING-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-3533: Fix Version/s: JCR ContentLoader 2.2.0 improve error handling and logging in content loader Key: SLING-3533 URL: https://issues.apache.org/jira/browse/SLING-3533 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR ContentLoader 2.1.6 Reporter: Oliver Lietz Assignee: Oliver Lietz Fix For: JCR ContentLoader 2.2.0 handle errors more appropriate and use proper log levels -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3535) reduce duplicated code in content loader
[
https://issues.apache.org/jira/browse/SLING-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lietz updated SLING-3535:
Fix Version/s: JCR ContentLoader 2.2.0
reduce duplicated code in content loader
Key: SLING-3535
URL: https://issues.apache.org/jira/browse/SLING-3535
Project: Sling
Issue Type: Improvement
Components: JCR
Affects Versions: JCR ContentLoader 2.1.6
Reporter: Oliver Lietz
Assignee: Oliver Lietz
Fix For: JCR ContentLoader 2.2.0
e.g. {{DefaultContentImporter}} and {{Loader}} can share more code in
{{BaseImportLoader}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3534) separate node name and content type in content loader
[ https://issues.apache.org/jira/browse/SLING-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-3534: Fix Version/s: JCR ContentLoader 2.2.0 separate node name and content type in content loader - Key: SLING-3534 URL: https://issues.apache.org/jira/browse/SLING-3534 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR ContentLoader 2.1.6 Reporter: Oliver Lietz Assignee: Oliver Lietz Fix For: JCR ContentLoader 2.2.0 extend API (node name and content type are currently taken from file name) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3619) Content Loader should handle input errors gracefully
[ https://issues.apache.org/jira/browse/SLING-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-3619: Fix Version/s: JCR ContentLoader 2.2.0 Content Loader should handle input errors gracefully Key: SLING-3619 URL: https://issues.apache.org/jira/browse/SLING-3619 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: JCR ContentLoader 2.1.8 Reporter: Yogesh Upadhyay Assignee: Oliver Lietz Priority: Minor Fix For: JCR ContentLoader 2.2.0 After upgrading to latest sling jar file, content loader stopped working to load content using Sling-Initial-Content. Getting following message in log 29.05.2014 23:20:21.504 *INFO* [Background Install /var/folders/mh/tkx6mmq53tb_bcph_cfp7wzmgn/T/install277506169886207.tmp] org.apache.sling.jcr.contentloader.internal.DefaultContentCreator createFile: Cannot find content type for body.jsp, using application/octet-stream -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Classloading issues with Sling Models IT
I am experiencing a weird bug in Sling Models IT. It seems that both Models API 1.1.1-SNAPSHOT and Models Impl 1.1.1-SNAPSHOT are part of the Sling Launchpad 8-SNAPSHOT. If I now run the Sling Models IT and deploy my own versions of those bundles, the API bundle is replaced by the newer version (which is correct), but both bundles are still available in Felix (due to class loading caching issues I guess). The following happens: 1.) Sling Launchpad starts up with its own version of Models API (has bundle id 108) 2.) Models IT deploys its own version of Models API (gets bundle id 110) 3.) Now the web console only exposes the bundle 110 and no longer bundle 108. When I try to execute some test now I get the following exception: Caused by: java.lang.ClassNotFoundException: org.apache.sling.models.factory.ModelClassException not found by org.apache.sling.models.api [108] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1397) at org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1577) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1507) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 79 common frames omitted This is due to the fact that the Models Impl is bound to the two different version of Models API at the same time: This is the import package section of the Models Impl Bundle: == javax.annotation,version=0.0.0.1_007_JavaSE from org.apache.felix.framework (0) http://localhost:58498/system/console/bundles/0 javax.inject,version=0.0.0 from org.apache.sling.models.api (110) http://localhost:58498/system/console/bundles/110 javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 org.apache.commons.collections.comparators,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.keyvalue,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.list,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.set,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (64) http://localhost:58498/system/console/bundles/64 org.apache.commons.logging,version=1.1.1 from jcl.over.slf4j (1) http://localhost:58498/system/console/bundles/1 org.apache.sling.api,version=2.3.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.adapter,version=2.2.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.resource,version=2.6.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.scripting,version=2.1.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.commons.osgi,version=2.2.0 from org.apache.sling.commons.osgi (78) http://localhost:58498/system/console/bundles/78 org.apache.sling.models.annotations,version=1.2.0 from org.apache.sling.models.api (110) http://localhost:58498/system/console/bundles/110 org.apache.sling.models.annotations.injectorspecific,version=1.1.0 from org.apache.sling.models.api (110) http://localhost:58498/system/console/bundles/110 org.apache.sling.models.factory,version=1.0.0 from org.apache.sling.models.api (108) http://localhost:58498/system/console/bundles/108 org.apache.sling.models.spi,version=1.0.2 from org.apache.sling.models.api (108) http://localhost:58498/system/console/bundles/108 org.apache.sling.models.spi.injectorspecific,version=1.1.0 from org.apache.sling.models.api (110) http://localhost:58498/system/console/bundles/110
Re: Classloading issues with Sling Models IT
It does work, if I I modify org.apache.sling.testing.tools.sling.BundlesInstaller to not uninstall the previous SNAPSHOT bundle before installing the new version (comment out line 80). What was the reason for first uninstalling the bundle? Usually an upgrade works much smoother (at least if the version is not downgraded). So what about the following change: Uninstall only if the previously installed versionis higher than the version which is about to be installed. Otherwise we might easily run into the same problems for other bundles, which cannot easily be uninstalled. On 07 Dec 2014, at 14:34, Konrad Windszus konra...@gmx.de wrote: I am experiencing a weird bug in Sling Models IT. It seems that both Models API 1.1.1-SNAPSHOT and Models Impl 1.1.1-SNAPSHOT are part of the Sling Launchpad 8-SNAPSHOT. If I now run the Sling Models IT and deploy my own versions of those bundles, the API bundle is replaced by the newer version (which is correct), but both bundles are still available in Felix (due to class loading caching issues I guess). The following happens: 1.) Sling Launchpad starts up with its own version of Models API (has bundle id 108) 2.) Models IT deploys its own version of Models API (gets bundle id 110) 3.) Now the web console only exposes the bundle 110 and no longer bundle 108. When I try to execute some test now I get the following exception: Caused by: java.lang.ClassNotFoundException: org.apache.sling.models.factory.ModelClassException not found by org.apache.sling.models.api [108] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1397) at org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1577) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1507) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 79 common frames omitted This is due to the fact that the Models Impl is bound to the two different version of Models API at the same time: This is the import package section of the Models Impl Bundle: == javax.annotation,version=0.0.0.1_007_JavaSE from org.apache.felix.framework (0) http://localhost:58498/system/console/bundles/0 javax.inject,version=0.0.0 from org.apache.sling.models.api (110) http://localhost:58498/system/console/bundles/110 javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 org.apache.commons.collections.comparators,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.keyvalue,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.list,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.set,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (64) http://localhost:58498/system/console/bundles/64 org.apache.commons.logging,version=1.1.1 from jcl.over.slf4j (1) http://localhost:58498/system/console/bundles/1 org.apache.sling.api,version=2.3.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.adapter,version=2.2.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.resource,version=2.6.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.scripting,version=2.1.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.commons.osgi,version=2.2.0 from org.apache.sling.commons.osgi (78) http://localhost:58498/system/console/bundles/78
Re: Classloading issues with Sling Models IT
Ok, that modification did not solve everything. With that change the integration tests are executed too fast (before the actual upgrade of the bundle took place). I guess the waitForBundlesInstalled method needs to be changed as well. On 07 Dec 2014, at 15:17, Konrad Windszus konra...@gmx.de wrote: It does work, if I I modify org.apache.sling.testing.tools.sling.BundlesInstaller to not uninstall the previous SNAPSHOT bundle before installing the new version (comment out line 80). What was the reason for first uninstalling the bundle? Usually an upgrade works much smoother (at least if the version is not downgraded). So what about the following change: Uninstall only if the previously installed versionis higher than the version which is about to be installed. Otherwise we might easily run into the same problems for other bundles, which cannot easily be uninstalled. On 07 Dec 2014, at 14:34, Konrad Windszus konra...@gmx.de wrote: I am experiencing a weird bug in Sling Models IT. It seems that both Models API 1.1.1-SNAPSHOT and Models Impl 1.1.1-SNAPSHOT are part of the Sling Launchpad 8-SNAPSHOT. If I now run the Sling Models IT and deploy my own versions of those bundles, the API bundle is replaced by the newer version (which is correct), but both bundles are still available in Felix (due to class loading caching issues I guess). The following happens: 1.) Sling Launchpad starts up with its own version of Models API (has bundle id 108) 2.) Models IT deploys its own version of Models API (gets bundle id 110) 3.) Now the web console only exposes the bundle 110 and no longer bundle 108. When I try to execute some test now I get the following exception: Caused by: java.lang.ClassNotFoundException: org.apache.sling.models.factory.ModelClassException not found by org.apache.sling.models.api [108] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1397) at org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1577) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1507) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 79 common frames omitted This is due to the fact that the Models Impl is bound to the two different version of Models API at the same time: This is the import package section of the Models Impl Bundle: == javax.annotation,version=0.0.0.1_007_JavaSE from org.apache.felix.framework (0) http://localhost:58498/system/console/bundles/0 javax.inject,version=0.0.0 from org.apache.sling.models.api (110) http://localhost:58498/system/console/bundles/110 javax.servlet,version=2.6.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet,version=3.0.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet.http,version=2.6.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 javax.servlet.http,version=3.0.0 from org.apache.felix.http.servlet-api (24) http://localhost:58498/system/console/bundles/24 org.apache.commons.collections.comparators,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.keyvalue,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.list,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.collections.set,version=3.2.1 from org.apache.commons.collections (60) http://localhost:58498/system/console/bundles/60 org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (64) http://localhost:58498/system/console/bundles/64 org.apache.commons.logging,version=1.1.1 from jcl.over.slf4j (1) http://localhost:58498/system/console/bundles/1 org.apache.sling.api,version=2.3.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.adapter,version=2.2.0 from org.apache.sling.api (71) http://localhost:58498/system/console/bundles/71 org.apache.sling.api.resource,version=2.6.0 from org.apache.sling.api (71)
[jira] [Created] (SLING-4224) Avoid NPE after HeartbeatHandler deactivation
Stefan Egli created SLING-4224:
--
Summary: Avoid NPE after HeartbeatHandler deactivation
Key: SLING-4224
URL: https://issues.apache.org/jira/browse/SLING-4224
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Priority: Minor
Fix For: Discovery Impl 1.0.14
The following order of messages, including a NPE, where witnessed:
{code}
27.11.2014 17:04:53.913 *INFO* [FelixShutdown] org.apache.felix.framework
BundleEvent STOPPING
...
27.11.2014 17:05:07.080 *INFO* [FelixStartLevel]
org.apache.sling.discovery.impl Service
[org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler,3149]
ServiceEvent UNREGISTERING
...
27.11.2014 17:05:07.094 *ERROR* [pool-9-thread-1]
org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
execution of
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4d2581b9 :
null
java.lang.NullPointerException: null
at
org.apache.sling.discovery.impl.cluster.voting.VotingHelper.listOpenNonWinningVotings(VotingHelper.java:53)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:441)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:409)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:212)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105)
at org.quartz.core.JobRunShell.run(JobRunShell.java:207)
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)
{code}
This indicates, that the HeartbeatHandler is executing the checkView method
even after deactivation - thus having the config null - thus running into a NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4225) The root directory for Sling logging should be configurable explicitly
Jörg Hoh created SLING-4225:
---
Summary: The root directory for Sling logging should be
configurable explicitly
Key: SLING-4225
URL: https://issues.apache.org/jira/browse/SLING-4225
Project: Sling
Issue Type: Improvement
Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Jörg Hoh
The directory, which is used to resolve relative path names against, should be
configurable instead of always being ${sling.home}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4225) The root directory for Sling logging should be configurable explicitly
[
https://issues.apache.org/jira/browse/SLING-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Hoh updated SLING-4225:
Attachment: SLING-4225.patch
This patch allows one to provide a property sling.log.root (in
sling.properties) to explicitly set the log directory; as fallback the property
sling.home is taken as it was the current behaviour.
The root directory for Sling logging should be configurable explicitly
--
Key: SLING-4225
URL: https://issues.apache.org/jira/browse/SLING-4225
Project: Sling
Issue Type: Improvement
Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Jörg Hoh
Attachments: SLING-4225.patch
The directory, which is used to resolve relative path names against, should
be configurable instead of always being ${sling.home}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4225) The root directory for Sling logging should be configurable explicitly
[
https://issues.apache.org/jira/browse/SLING-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned SLING-4225:
--
Assignee: Chetan Mehrotra
The root directory for Sling logging should be configurable explicitly
--
Key: SLING-4225
URL: https://issues.apache.org/jira/browse/SLING-4225
Project: Sling
Issue Type: Improvement
Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Jörg Hoh
Assignee: Chetan Mehrotra
Attachments: SLING-4225.patch
The directory, which is used to resolve relative path names against, should
be configurable instead of always being ${sling.home}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4225) The root directory for Sling logging should be configurable explicitly
[
https://issues.apache.org/jira/browse/SLING-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-4225:
---
Priority: Minor (was: Major)
The root directory for Sling logging should be configurable explicitly
--
Key: SLING-4225
URL: https://issues.apache.org/jira/browse/SLING-4225
Project: Sling
Issue Type: Improvement
Components: Commons
Affects Versions: Commons Log 4.0.0
Reporter: Jörg Hoh
Assignee: Chetan Mehrotra
Priority: Minor
Attachments: SLING-4225.patch
The directory, which is used to resolve relative path names against, should
be configurable instead of always being ${sling.home}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
