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 <[email protected]> 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
