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. > On 14 April 2014 19:06, Remko Popma <[email protected]> wrote: > If the separation between log4j-api and log4j-core causes issues for OSGi, > then would it be an option to combine these two into a single bundle for > OSGi? Would that avoid the need for registry complexity? Separation between core and api is good. People who wants to use loggers just depend on log4j-api and Logger class, which is great because changes of logging implementation will not cause any changes to users. Issue I currently see is how the logger is obtained. Logger.getLogger calls private/concrete class which makes hard to configure things at the runtime without classpath/class overriding. Now log4j allows to put log levels over JMX, but it’s self contained in library. Not sure if this direct class calls will not complicate possibility to manage log4j externaly. > On 2014/04/15, at 9:45, Matt Sicker <[email protected]> wrote: > >> It's mainly to add OSGi support. Since log4j-core (or any of the providers) >> might not be available at the same time as log4j-api, there needs to be a >> way to add a LoggerContextFactory afterward to take over. This is due to how >> OSGi works where you can dynamically add or remove bundles at runtime. >> Basically, you can't depend on what's available at initialisation to be >> everything that's there. Plus, you can remove bundles, so you can't rely on >> classes being there forever (although OSGi won't take them away from you, so >> it's not that big a deal in that case). >> >> Another example use case would be something like Tomcat or Karaf using >> Log4j2 internally, but allowing for installed applications (webapps or >> bundles in these cases) to add more plugins, a different >> LoggerContextFactory to override, etc. 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. Kind regards, Łukasz Dywicki -- [email protected] Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org
