logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Intention to modify API
Date Mon, 14 Apr 2014 23:09:33 GMT
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 <boards@gmail.com> 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 <ralph.goers@dslextreme.com> 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 <boards@gmail.com> 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 <boards@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>
>



-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message