On 15 April 2014 04:44, Łukasz Dywicki <[email protected]> wrote: > Hey, > My replies inline: > > Wiadomość napisana przez Matt Sicker <[email protected]> w dniu 15 kwi > 2014, o godz. 03:08: > > It would defeat the purpose of using OSGi. Plus, how would that work if > you wanted to use log4j-to-slf4j? > > Currently with pax-logging implementation (provides OSGi "LogService") > slf4j bridges are completelly ignored because it requires real logging > backend to work. I did not thing about this yet, but bridge could help here > to forward all slf4j calls to log4j without any troubles. Only one thing > which will be left is MDC. > > The log4j-to-slf4j is a JAR that makes calls to the log4j-api use slf4j as the backend. The log4j-slf4j-impl JAR is for making slf4j-api calls use log4j-core as the backend.
Matt, you are right about initialization - we can’t be 100% sure if all > things are present at the boot time, however in OSGi we can set up start > level which lets start up things in certain order and logging is regular > "core service” you usually depend on. You can start up without logging > backend (ie. without slf4j bridge), then install it, but it’s normal in > this case to refresh some bundles and force re-initialization. From other > hand, if we have backend present then bundle activation is synchronous and > we can rely on that. I think LoggerContextFactory is so far sufficient. > > Oh, that makes sense. The scenario I was thinking about in regards to plugins can be easily handled by an alternative plugin manager implementation for OSGi that uses a service tracker or bundle tracker. I'm looking more into this. *** As a separate proposal, I'm thinking we should move the core SPI classes (i.e., Appender, Filter, etc.) into its own core.spi package. This could also be split out into its own module, but really, there isn't much point in doing so as any plugins to Log4j will most likely need classes from log4j-core as it is. Either way, putting them in an spi package would make sense. The reasoning behind this is also due to the fact that several SPI-like classes are scattered about in core and are usually in the same package as its implementations. Also, if we were to split off a log4j-spi module, then OSGi users could query for services using those interfaces (and the usual LDAP-style filters) to get information about the logging runtime. This can allow better decoupling as the programmer would only need to use classes from log4j-api and log4j-spi to get concrete instances for configuration information without us having to worry about maintaining any log4j-core backwards compatibility (other than implementing the interfaces). Thoughts? -- Matt Sicker <[email protected]>
