Will do. The main thing I'd like to change is the LogManager initialisation. I'd prefer that to keep a registry of LoggerContextFactories so that a different factory can be registered later on (for instance, in OSGi, you could install log4j-api, then log4j-core, and core would register itself and take over as the default factory).
Anything more complex than that (like being able to use multiple factories concurrently like you can with contexts), while not necessarily requiring API changes, will require some thought as to how and if it's feasible. Of course, it would be more of an API addition for that (e.g., selecting the non-default provider chooser or something like that). Basically, that part shouldn't be hard to make backwards compatible. On 14 April 2014 10:25, Ralph Goers <[email protected]> wrote: > Hopefully the changes won’t be too significant. Can you please post what > you intend to do before commit? > > Ralph > > On Apr 14, 2014, at 7:55 AM, Matt Sicker <[email protected]> wrote: > > I was thinking about how to best support strange class loader environments > (like OSGi or Servlets), and in order to support a LoggerContextFactory, we > should have a registry of sorts for it. This way, a new LCF can dynamically > add or remove itself at runtime. Ideally, we'd fall back to the > SimpleLogger implementation when none are registered. There may be an added > issue with Loggers being tied to their factories and such. > > Anyway, the main thing to address is the ability to change (or add) > providers at runtime. Whether or not we can support a more dynamic system > is more of a technical issue. Scanning for a default provider at > initialization still makes sense to pre-load the registry, but imagine the > scenario where a server like Tomcat uses Log4j but allows individual web > apps to provide custom providers. > > I'd like to at least implement the necessary API changes before 2.0 so > that this may be possible down the line. Even if we don't use OSGi, it > should still be possible to use log4j in an OSGi framework (core or as a > regular bundle). This will certainly help adoption by the container > projects. > > > > -- > Matt Sicker <[email protected]> > > > -- Matt Sicker <[email protected]>
