You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2013/11/15 12:29:31 UTC
New way of configuring Logging in Sling
Hi,
I am updating the Logging documentation with Logback related changes
[1]. In doing that I need some suggestion on how should we now
recommend Sling user to configure Logging
The current Sling Logging feature set provided two set of configurations
1. Logger config - Ability to configure Log level for various logger
and also provide the file name to which logging must be directed
(optional). So it mixes Logger and Appender config
2. Log Writer Config or Appender Config - Captures details around how
the file based appender should work i.e. rotation
Now with Logback these can be configured in a xml file and still be
augmented via OSGi config. Further the above mode of configuring
appender would not be able to use full feature set of Logback config.
So for new setup we can probably suggest following way
1. Ship a default logback.xml as part of Sling distribution which
would be unpacked at say ${sling.home}/etc/logback.xml
2. Configure some default appenders and loggers
3. Do away with OSGi config for LogWriters completely. FOr backward
compatibility this feature would continue to be supported
4. Also do away with OSGi config for Loggers also or just configure
appender in Logback config file and Loggers via OSGi config
If we have agreement then I would not include section on size rotation
etc in new documentation and would just add links to Logback manual
Note that
1. Current Log support enables extending OSGi based appender
configuration from within Logback config
file [2]. So we can enrich existing config easily
2. It is also possible to extend Logback config file with config
fragment support [3]. And later we can provide a JCR integration which
can use this feature and allows config to be provided via JCR content
3. I intend to provide support for editing Logback config (external
file based) from within Felix WebConsole
WDYT?
Chetan Mehrotra
[1] http://sling.apache.org/documentation/development/logging-new.html
[2] http://sling.apache.org/documentation/development/logging-new.html#configuring-osgi-based-appenders-in-logback-config
[3] sling.apache.org/documentation/development/logging-new.html#logback-config-fragment-support
Re: New way of configuring Logging in Sling
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Chetan
I have to agree with the others: The primary configuration mechanism for logging is and remains to be OSGi configuration. That was one of the reasons for writing our own slf4j implementation in the first place and it was one of my requirements for another implementation (which is why it took so long to be realized).
I agree (and am thankfull for that) that appenders can be provided as services to dynamically extend the logging.
I agree that for extended and more stuff, support for XML configuration is good and great (yet, I also agree with Justin, that we might want to explore supporting more features of LogBack through OSGi configuration).
Finally: I would prefer to keep the default XML empty ! If we want specialized configuration for Jackrabbit (which may be usefull) features then the Jackrabbit bundle should provide it.
Regards
Felix
—
Felix Meschberger | Principal Scientist | Adobe
Am 15.11.2013 um 22:29 schrieb Chetan Mehrotra <ch...@gmail.com>:
> Hi,
>
> I am updating the Logging documentation with Logback related changes
> [1]. In doing that I need some suggestion on how should we now
> recommend Sling user to configure Logging
>
> The current Sling Logging feature set provided two set of configurations
>
> 1. Logger config - Ability to configure Log level for various logger
> and also provide the file name to which logging must be directed
> (optional). So it mixes Logger and Appender config
>
> 2. Log Writer Config or Appender Config - Captures details around how
> the file based appender should work i.e. rotation
>
> Now with Logback these can be configured in a xml file and still be
> augmented via OSGi config. Further the above mode of configuring
> appender would not be able to use full feature set of Logback config.
> So for new setup we can probably suggest following way
>
> 1. Ship a default logback.xml as part of Sling distribution which
> would be unpacked at say ${sling.home}/etc/logback.xml
> 2. Configure some default appenders and loggers
> 3. Do away with OSGi config for LogWriters completely. FOr backward
> compatibility this feature would continue to be supported
> 4. Also do away with OSGi config for Loggers also or just configure
> appender in Logback config file and Loggers via OSGi config
>
> If we have agreement then I would not include section on size rotation
> etc in new documentation and would just add links to Logback manual
>
> Note that
> 1. Current Log support enables extending OSGi based appender
> configuration from within Logback config
> file [2]. So we can enrich existing config easily
>
> 2. It is also possible to extend Logback config file with config
> fragment support [3]. And later we can provide a JCR integration which
> can use this feature and allows config to be provided via JCR content
>
> 3. I intend to provide support for editing Logback config (external
> file based) from within Felix WebConsole
>
> WDYT?
>
> Chetan Mehrotra
> [1] http://sling.apache.org/documentation/development/logging-new.html
> [2] http://sling.apache.org/documentation/development/logging-new.html#configuring-osgi-based-appenders-in-logback-config
> [3] sling.apache.org/documentation/development/logging-new.html#logback-config-fragment-support
Re: New way of configuring Logging in Sling
Posted by Tobias Bocanegra <tr...@apache.org>.
sorry for my ignorance, but what is the advantage of logback? was
there anything missing in log4j?
and I agree with alex and justin, that moving away from osgi
configurability for logging contradicts all paradigms of sling :-)
sling tries so hard to make everything else configurable by osgi :-)
moving the config to pure xml files, would take away the possibility
to configure a system with content package, http calls, etc.
regards, toby
On Fri, Nov 15, 2013 at 6:59 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> On Fri, Nov 15, 2013 at 5:49 PM, Alexander Klimetschek
> <ak...@adobe.com> wrote:
>> On 15.11.2013, at 03:29, Chetan Mehrotra <ch...@gmail.com> wrote:
>>
>>> 3. Do away with OSGi config for LogWriters completely. FOr backward
>>> compatibility this feature would continue to be supported
>>
>> Why? I actually like it very much that there is a UI with help text for e.g. the formatting string, instead of having to understand some special xml format...
>
> Totally agree with Alex. I think it is safe to assume that the
> existing file-based logging would represent the primary use cases for
> logging, even with the enhanced options provided by Logback. So why
> not continue to make the most common use case simple? XML file editing
> should only be necessary in edge cases (or not-so-edge cases which we
> just haven't had time to simplify yet).
>
> Also, the statements "...do away with..." and "...would continue to be
> supported..." would seem to be contradictory.
>
>
>>
>> And it's 2013, we are still wrapping another generic logging handling around another one?
>
> I'm guessing that Logback wasn't interested in adding first class OSGi
> support. Which is really too bad as that would have been the best
> option all around IMHO.
>
> Justin
>
>>
>> Cheers,
>> Alex
Re: New way of configuring Logging in Sling
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Justin,
The point I am try to emphasize is that Log bundle sits at the lowest
level of the bundle stack. At that level it cannot have a direct
dependency on a layer (like ResourceResolver API) which is higher in
the stack. It should only be dependent on OSGi Framework API. And
having an xml based mechanism (completely optional) to configure
Logback without depending on any other sub system would allow me to
use its full feature set in troubleshooting issues.
If Log system has to rely on a component like
FileSystemResourceProvider (Sling API starts at Level 20) then that
would make it much harder to debug startup issues say issues which
occur when repository starts (start level 15). IMHO Log bundle must be
robust and hence should not depend on external systems for core
feature set.
Further answers inline.
On Tue, Nov 19, 2013 at 11:20 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> Hi Chetan,
>
>
> As I said, if you want to configure logging using a file, you can do
> this with the File System Resource Provider. If you want to support
> directly loading from a file for bootstrapping purposes, i.e. there's
> a path in a framework property which is used until the
> ResourceResolverFactory is available, that's fine with me, but IMHO
> overkill as we already have the org.apache.sling.commons.log.level
> property which is there to help troubleshoot issues during
> bootstrapping.
Tweaking the Log level to debug is just one of the various features.
With Logback I can also enable logging of caller stack, MDC data, in
line event evaluation etc which prove to be very useful for me in
troubleshooting. And you never know what you might require to
troubleshoot bootstrapping which in env like OSGi might be quite
involved. And as explained above relying till the time File System
Resource Provider comes up would not be good as it comes too late in
the startup cycle.
> My point is that "one" shouldn't need to implement this. It needs to
> be a standard feature. And it should be documented as the secondary
> way to configure Logback, with ConfigAdmin being the primary way.
As mentioned in starting Log bundle cannot directly depend on the
Sling API. It can expose extension points which can be implemented by
components which come later in startup. Having a bundle which collects
Logback config fragments from JCR is on my ToDo list and would later
be provided as part of Sling. ConfigAdmin is already supported
directly.
> As I said, my concern is one of consistency. The first goal of Sling
> log support should be to support Sling-based applications. If it can
> work outside of Sling, that would be nice to have, but IMHO is a
> non-goal, especially if it results in an inconsistency.
I still do not see the inconsistency. As mentioned earlier the
logback.xml usage pattern is similar to how JR2 used to use
repository.xml. Further in Log bundle case it supports various others
modes of configuration and does not limit/force the user to use the
xml route to configure it which was not the case with JR2.
regards
Chetan
Re: New way of configuring Logging in Sling
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Chetan,
On Tue, Nov 19, 2013 at 12:12 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
>>> 1. Configures itself with a pre packaged config file within the Bundle
>>
>> To which bundle is this referring? The Logback integration bundle? If
>> so, when would this file be used?
>
> It refers to the org.apache.sling.commons.log-4.0.0 bundle which
> packages a default logback.xml as part of bundle classpath. This file
> is used to bootstrap Logback
>
>>> 2. Can be configured to configure Logback from a file on file system.
>>> This would allow one to customize it on a per Sling instance basis
>>
>> I think this functionality needs to be removed as it isn't consistent
>> with the rest of Sling.
>
> I disagree. This functionality proves to be quite useful in
> configuring Logging and I would not like that Logging system depends
> completely on any other system for configuration. At very minimum it
> should be possible to configure Logging without depending on any other
> support. One use would be in cluster deployment where to troubleshoot
> issue on a particular node an admin can start the system with specific
> logback.xml. It can use those Logback features which are not possible
> to configure via OSGi.
As I said, if you want to configure logging using a file, you can do
this with the File System Resource Provider. If you want to support
directly loading from a file for bootstrapping purposes, i.e. there's
a path in a framework property which is used until the
ResourceResolverFactory is available, that's fine with me, but IMHO
overkill as we already have the org.apache.sling.commons.log.level
property which is there to help troubleshoot issues during
bootstrapping.
>
> This is similar to how so far JR2 configuration was handled via
> repository.xml and Repository bundle provided an option to provide a
> custom repository.xml for first startup.
>
>>> 4. Can be further extended via Config Fragments [2]. It supports an
>>> extension point to provide
>>> xml fragments from different source. Later we can add an impl which
>>> can look up config
>>> fragments in JCR repo and provide it to Common Log
>>
>> This needs to be done against the resource resolver, not the JCR
>> directly. And if you do that, then #2 isn't necessary as you can use
>> the File System Resource Provider to point the configured resource
>> path to a file system resource.
>
> Commons Log bundle exposes an extension point and that can be
> implemented using any possible means. In Sling one can implement it
> against ResourceProvider also. However it would always be *one* of the
> option.
My point is that "one" shouldn't need to implement this. It needs to
be a standard feature. And it should be documented as the secondary
way to configure Logback, with ConfigAdmin being the primary way.
>
>> In my opinion, these are showstoppers and warrant cancelling the
>> release. Otherwise, we are stuck with a backwards compatibility issue.
>
> I still do not get the concern here. The Log bundle provides various
> means to configure Logback and users are free to use any of the means.
> Currently the Log bundle can has no dependency on Sling API and can
> easily be used in non Sling containers also. All these options are
> fully supported and well documented with backing testcase.
As I said, my concern is one of consistency. The first goal of Sling
log support should be to support Sling-based applications. If it can
work outside of Sling, that would be nice to have, but IMHO is a
non-goal, especially if it results in an inconsistency.
Justin
>
> regards
> Chetan
Re: New way of configuring Logging in Sling
Posted by Chetan Mehrotra <ch...@gmail.com>.
>> 1. Configures itself with a pre packaged config file within the Bundle
>
> To which bundle is this referring? The Logback integration bundle? If
> so, when would this file be used?
It refers to the org.apache.sling.commons.log-4.0.0 bundle which
packages a default logback.xml as part of bundle classpath. This file
is used to bootstrap Logback
>> 2. Can be configured to configure Logback from a file on file system.
>> This would allow one to customize it on a per Sling instance basis
>
> I think this functionality needs to be removed as it isn't consistent
> with the rest of Sling.
I disagree. This functionality proves to be quite useful in
configuring Logging and I would not like that Logging system depends
completely on any other system for configuration. At very minimum it
should be possible to configure Logging without depending on any other
support. One use would be in cluster deployment where to troubleshoot
issue on a particular node an admin can start the system with specific
logback.xml. It can use those Logback features which are not possible
to configure via OSGi.
This is similar to how so far JR2 configuration was handled via
repository.xml and Repository bundle provided an option to provide a
custom repository.xml for first startup.
>> 4. Can be further extended via Config Fragments [2]. It supports an
>> extension point to provide
>> xml fragments from different source. Later we can add an impl which
>> can look up config
>> fragments in JCR repo and provide it to Common Log
>
> This needs to be done against the resource resolver, not the JCR
> directly. And if you do that, then #2 isn't necessary as you can use
> the File System Resource Provider to point the configured resource
> path to a file system resource.
Commons Log bundle exposes an extension point and that can be
implemented using any possible means. In Sling one can implement it
against ResourceProvider also. However it would always be *one* of the
option.
> In my opinion, these are showstoppers and warrant cancelling the
> release. Otherwise, we are stuck with a backwards compatibility issue.
I still do not get the concern here. The Log bundle provides various
means to configure Logback and users are free to use any of the means.
Currently the Log bundle can has no dependency on Sling API and can
easily be used in non Sling containers also. All these options are
fully supported and well documented with backing testcase.
regards
Chetan
Re: New way of configuring Logging in Sling
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Chetan,
Thanks for this summary. Very helpful to understand the issues.
Comments inline...
On Tue, Nov 19, 2013 at 8:41 AM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> Hi Justin,
>
> On Tue, Nov 19, 2013 at 5:55 PM, Justin Edelson
> <ju...@justinedelson.com> wrote:
>> I don't see why logging requires going outside this practice. It
>> didn't before Logback.
>
> Looks like there is some confusion around various ways with which
> logging can be configured with Logback. Logging with Logback is
> supporting all the following configuration modes
>
> 1. Configures itself with a pre packaged config file within the Bundle
To which bundle is this referring? The Logback integration bundle? If
so, when would this file be used?
>
> 2. Can be configured to configure Logback from a file on file system.
> This would allow one to customize it on a per Sling instance basis
I think this functionality needs to be removed as it isn't consistent
with the rest of Sling.
>
> 3. Can be further extended via OSGi based config as has been supported
> by previous Logging impl [1]
>
> 4. Can be further extended via Config Fragments [2]. It supports an
> extension point to provide
> xml fragments from different source. Later we can add an impl which
> can look up config
> fragments in JCR repo and provide it to Common Log
This needs to be done against the resource resolver, not the JCR
directly. And if you do that, then #2 isn't necessary as you can use
the File System Resource Provider to point the configured resource
path to a file system resource.
In my opinion, these are showstoppers and warrant cancelling the
release. Otherwise, we are stuck with a backwards compatibility issue.
Regards,
Justin
>
> 5. Can be further extended via Appender/Filter registered as OSGi service
>
> What I was proposing that we modify the Launchpad support to dump an
> xml at pre defined location and allow users to customize it. However
> all other modes of configuring Logback would continue to work
>
> Chetan Mehrotra
> [1] http://sling.apache.org/documentation/development/logging.html#user-configuration-osgi-based
> [2] http://sling.apache.org/documentation/development/logging.html#logback-config-fragment-support
Re: New way of configuring Logging in Sling
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Justin,
On Tue, Nov 19, 2013 at 5:55 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> I don't see why logging requires going outside this practice. It
> didn't before Logback.
Looks like there is some confusion around various ways with which
logging can be configured with Logback. Logging with Logback is
supporting all the following configuration modes
1. Configures itself with a pre packaged config file within the Bundle
2. Can be configured to configure Logback from a file on file system.
This would allow one to customize it on a per Sling instance basis
3. Can be further extended via OSGi based config as has been supported
by previous Logging impl [1]
4. Can be further extended via Config Fragments [2]. It supports an
extension point to provide
xml fragments from different source. Later we can add an impl which
can look up config
fragments in JCR repo and provide it to Common Log
5. Can be further extended via Appender/Filter registered as OSGi service
What I was proposing that we modify the Launchpad support to dump an
xml at pre defined location and allow users to customize it. However
all other modes of configuring Logback would continue to work
Chetan Mehrotra
[1] http://sling.apache.org/documentation/development/logging.html#user-configuration-osgi-based
[2] http://sling.apache.org/documentation/development/logging.html#logback-config-fragment-support
Re: New way of configuring Logging in Sling
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Chetan,
The issue for me is one of consistency. One of the key design
principals of Sling is that everything is a resource. Which includes
configuration. In our ecosystem, we have multiple different
configuration methods:
1) OSGi ConfigAdmin - configured through sling:OsgiConfig nodes and
.config files, including writeback to ensure consistency.
2) Resource Structures, e.g. /etc/map and rewriter configuration -
these are used in cases where the configuration is too complex for
ConfigAdmin
3) XML files as resource - used where the effort of creating support
for a resource structure is too high compared with the amount of
expected change. The only example I'm aware of in Sling is the
Jackrabbit repository.xml. It is a bit more common in CQ, e.g. XSL:FO
configuration and XSS Protection. Where this is done, the path to the
resource should be configurable (this, sadly, is not always done, but
those are IMHO bugs).
4) Framework properties - used for bootstrapping, e.g. runmodes.
In some cases, we *combine* these techniques, i.e. configuration from
/etc/map is combined with the ConfigAdmin-based configuration of the
ResourceResolver.
I don't see why logging requires going outside this practice. It
didn't before Logback.
For the bootstrap problem, we were doing this before with framework
properties. Couldn't Logback be configured using the same framework
properties as before and then switch over to a resource-based
configuration once the resource resolver was available?
Regards,
Justin
On Sat, Nov 16, 2013 at 1:36 AM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> Probably I was not clear in my earlier mail
>
> I am suggesting that we ship a default logback.xml with Sling which
> gets placed under ${sling.home}/etc/logback.xml. The default xml would
> look like [1]. It provide following benefits
>
> 1. For log files which are not that critical we can set immediateFlush
> to false thereby increasing performance a bit
> 2. Document some useful logger categories which have there log level
> set to INFO by default. A user can then set it to debug for debugging
> purpose
> 3. It also provides an easier way to bootstrap logging config in
> automatic deployments.
> 4. It simplifies using Logback features which are not possible via
> OSGi way. If we do not ship such default config xml users would have
> to setup on there own thus making such Logback features difficult to
> configure
>
> The user can still continue to use OSGi based configuration for log
> writers and loggers
>
> In addition I was also suggesting that we do not document the OSGi
> config way to configure the appender and instead recommend users to
> configure appenders in logback.xml. But looks like people prefer the
> OSGi way (see below). In that case I would continue to include doc
> about that feature in new doc.
>
>> . I think it is safe to assume that the
>> existing file-based logging would represent the primary use cases for
>> logging, even with the enhanced options provided by Logback. So why
>> not continue to make the most common use case simple
>
> ACK. The OSGi way would continue to be supported as mentioned earlier
>
>> XML file editing
>> should only be necessary in edge cases (or not-so-edge cases which we
>> just haven't had time to simplify yet).
>
> FWIW I find the logger names distributed across multiple OSGi configs
> difficult to use. For example in current mode you cannot change log
> level of just one category in a particular OSGi config. To change log
> level you need to remove that logger form given config and create a
> new osgi config with different log level. For me its easier if all
> such logger levels are configured discretely in a xml file and I can
> directly tweak them there.
>
>> And it's 2013, we are still wrapping another generic logging handling around another one?
>
> Do not know what do you mean by wrapping here. In current
> implementation we are not wrapping any other library. Its default
> Logback directly being used which natively implements the Slf4j API.
> We just provide a better integration with OSGi feature set
>
> Chetan Mehrotra
> [1] https://gist.github.com/chetanmeh/7496571
Re: New way of configuring Logging in Sling
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 16.11.2013 um 17:36 schrieb Chetan Mehrotra <ch...@gmail.com>:
>> XML file editing
>> should only be necessary in edge cases (or not-so-edge cases which we
>> just haven't had time to simplify yet).
>
> FWIW I find the logger names distributed across multiple OSGi configs
> difficult to use. For example in current mode you cannot change log
> level of just one category in a particular OSGi config. To change log
> level you need to remove that logger form given config and create a
> new osgi config with different log level. For me its easier if all
> such logger levels are configured discretely in a xml file and I can
> directly tweak them there.
This is only true, if the logger you want to reconfigure is configured along with other loggers. If your logger is configured with its own config or if you want to change the level for all the loggers in the same config you just need to change the level value in the config.
Other than that: If you think that we should improve the web console support for logging configuration, I am all in ;-)
Regards
Felix
Re: New way of configuring Logging in Sling
Posted by Chetan Mehrotra <ch...@gmail.com>.
Probably I was not clear in my earlier mail
I am suggesting that we ship a default logback.xml with Sling which
gets placed under ${sling.home}/etc/logback.xml. The default xml would
look like [1]. It provide following benefits
1. For log files which are not that critical we can set immediateFlush
to false thereby increasing performance a bit
2. Document some useful logger categories which have there log level
set to INFO by default. A user can then set it to debug for debugging
purpose
3. It also provides an easier way to bootstrap logging config in
automatic deployments.
4. It simplifies using Logback features which are not possible via
OSGi way. If we do not ship such default config xml users would have
to setup on there own thus making such Logback features difficult to
configure
The user can still continue to use OSGi based configuration for log
writers and loggers
In addition I was also suggesting that we do not document the OSGi
config way to configure the appender and instead recommend users to
configure appenders in logback.xml. But looks like people prefer the
OSGi way (see below). In that case I would continue to include doc
about that feature in new doc.
> . I think it is safe to assume that the
> existing file-based logging would represent the primary use cases for
> logging, even with the enhanced options provided by Logback. So why
> not continue to make the most common use case simple
ACK. The OSGi way would continue to be supported as mentioned earlier
> XML file editing
> should only be necessary in edge cases (or not-so-edge cases which we
> just haven't had time to simplify yet).
FWIW I find the logger names distributed across multiple OSGi configs
difficult to use. For example in current mode you cannot change log
level of just one category in a particular OSGi config. To change log
level you need to remove that logger form given config and create a
new osgi config with different log level. For me its easier if all
such logger levels are configured discretely in a xml file and I can
directly tweak them there.
> And it's 2013, we are still wrapping another generic logging handling around another one?
Do not know what do you mean by wrapping here. In current
implementation we are not wrapping any other library. Its default
Logback directly being used which natively implements the Slf4j API.
We just provide a better integration with OSGi feature set
Chetan Mehrotra
[1] https://gist.github.com/chetanmeh/7496571
Re: New way of configuring Logging in Sling
Posted by Justin Edelson <ju...@justinedelson.com>.
On Fri, Nov 15, 2013 at 5:49 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> On 15.11.2013, at 03:29, Chetan Mehrotra <ch...@gmail.com> wrote:
>
>> 3. Do away with OSGi config for LogWriters completely. FOr backward
>> compatibility this feature would continue to be supported
>
> Why? I actually like it very much that there is a UI with help text for e.g. the formatting string, instead of having to understand some special xml format...
Totally agree with Alex. I think it is safe to assume that the
existing file-based logging would represent the primary use cases for
logging, even with the enhanced options provided by Logback. So why
not continue to make the most common use case simple? XML file editing
should only be necessary in edge cases (or not-so-edge cases which we
just haven't had time to simplify yet).
Also, the statements "...do away with..." and "...would continue to be
supported..." would seem to be contradictory.
>
> And it's 2013, we are still wrapping another generic logging handling around another one?
I'm guessing that Logback wasn't interested in adding first class OSGi
support. Which is really too bad as that would have been the best
option all around IMHO.
Justin
>
> Cheers,
> Alex
Re: New way of configuring Logging in Sling
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 15.11.2013, at 03:29, Chetan Mehrotra <ch...@gmail.com> wrote:
> 3. Do away with OSGi config for LogWriters completely. FOr backward
> compatibility this feature would continue to be supported
Why? I actually like it very much that there is a UI with help text for e.g. the formatting string, instead of having to understand some special xml format...
And it's 2013, we are still wrapping another generic logging handling around another one?
Cheers,
Alex