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 bas
Hi Chetan,
On Tue, Nov 19, 2013 at 12:12 PM, Chetan Mehrotra
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.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
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
wrote:
> Hi Justin,
>
> On Tue, Nov 19, 2013 at 5:55 PM, Justin Edelson
> wrote:
>> I don't see why logging requires going outside this practice. It
>> d
Hi Justin,
On Tue, Nov 19, 2013 at 5:55 PM, Justin Edelson
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
supporti
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
.conf
Hi
Am 16.11.2013 um 17:36 schrieb Chetan Mehrotra :
>> 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
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
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 :-)
mo
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 immediateFlus
On Fri, Nov 15, 2013 at 5:49 PM, Alexander Klimetschek
wrote:
> On 15.11.2013, at 03:29, Chetan Mehrotra 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
On 15.11.2013, at 03:29, Chetan Mehrotra 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
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 l
13 matches
Mail list logo
