It would defeat the purpose of using OSGi. Plus, how would that work if you wanted to use log4j-to-slf4j?
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? > > Sent from my iPhone > > 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. > > > On 14 April 2014 17:40, Remko Popma <[email protected]> wrote: > >> To be honest, it all sounds pretty complex to me. What is the use case? >> You mention you want to dynamically add/remove logger context factories at >> runtime but I'm not clear on why this is desired/required. >> >> If there are class loader issues we should focus on that. If there is an >> issue that prevents OSGi from working we should work on that, but I here I >> don't see what problem you are trying to solve. Is this for OSGi? >> >> Instead if diving into the solution, could you provide a clear >> description of the problem? >> >> Remko >> >> Sent from my iPhone >> >> On 2014/04/15, at 8:09, Matt Sicker <[email protected]> wrote: >> >> Alright, here's what I'm thinking so far: >> >> Add a class named something like LoggerContextFactoryRegistry (yeah I >> hate that name already). Make it a singleton class. It should keep a >> SortedMap of int -> LoggerContextFactory (similar to how they're scanned in >> LogManager). This class should also keep a volatile LoggerContextFactory >> containing the current factory so it doesn't have to be recalculated every >> time. It can be updated instead when a new factory is registered. >> >> Method-wise, it should have a getFactory() and a register(int, >> LoggerContextFactory) (or call it registerFactory?) method. A lot of the >> static initialisation of LogManager can be moved to the constructor in this >> class. >> >> Being able to register the class instance itself (or the class?) works >> better than just scanning files due to class loader differences in other >> environments. We can't rely on the TCCL or anything like that for every >> factory. >> >> Any feedback? I may end up submitting this as a patch first to get more >> feedback, but this part of the implementation may be rather simple overall. >> >> >> On 14 April 2014 11:50, Matt Sicker <[email protected]> wrote: >> >>> 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]> >>> >> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
