Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B2DB711F48 for ; Mon, 14 Apr 2014 23:09:59 +0000 (UTC) Received: (qmail 87809 invoked by uid 500); 14 Apr 2014 23:09:58 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 87713 invoked by uid 500); 14 Apr 2014 23:09:58 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 87704 invoked by uid 99); 14 Apr 2014 23:09:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Apr 2014 23:09:58 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of boards@gmail.com designates 209.85.214.179 as permitted sender) Received: from [209.85.214.179] (HELO mail-ob0-f179.google.com) (209.85.214.179) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Apr 2014 23:09:54 +0000 Received: by mail-ob0-f179.google.com with SMTP id va2so10007032obc.10 for ; Mon, 14 Apr 2014 16:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BrV9rCcldOvgVdMYqfnqjyj1wzeMGLvKO9D9n8gszKM=; b=JIc1VoSR/s5r5Kd2UjHGpyOmWmatJD9xTq87P2xbwfmrezboxGk1vKHP2U18mWQGH9 a4oao8izv9rvlF+vR4P/iAA0LwKAPiZSdPa8YO5YKEOf7s1mbZVRqP8RmH4erXMCp46I ua4EcqBd98MrcGZZTUsMrHOPdoV9O63B4/eUCniSROpta8NGefN5Q7sxVIgi9K0xpwiJ pHGbfq87+jwFCTxZsIR7dF+tCV+8rUTvxYRO2FOyIu2w9DtKr+epR08IPEZYykjAKjgB gT0B7vDphzqE9vxG2yAji8qnUJ2N4cumTkJ57dK6kfZ505PT4U3LUgnE9FY/z48NgsoT Ks+g== MIME-Version: 1.0 X-Received: by 10.182.181.105 with SMTP id dv9mr4066662obc.59.1397516973217; Mon, 14 Apr 2014 16:09:33 -0700 (PDT) Received: by 10.76.72.68 with HTTP; Mon, 14 Apr 2014 16:09:33 -0700 (PDT) In-Reply-To: References: <2F29DAAF-C5B3-4DC0-87C4-FA0321137AC5@dslextreme.com> Date: Mon, 14 Apr 2014 18:09:33 -0500 Message-ID: Subject: Re: Intention to modify API From: Matt Sicker To: Log4J Developers List Content-Type: multipart/alternative; boundary=089e0115f41ac3967404f708c6ff X-Virus-Checked: Checked by ClamAV on apache.org --089e0115f41ac3967404f708c6ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 late= r > 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 factorie= s > 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 par= t > shouldn't be hard to make backwards compatible. > > > On 14 April 2014 10:25, Ralph Goers wrote: > >> Hopefully the changes won=E2=80=99t 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 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 wa= y, >> 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 a= nd >> 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 syste= m >> is more of a technical issue. Scanning for a default provider at >> initialization still makes sense to pre-load the registry, but imagine t= he >> 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 >> >> >> > > > -- > Matt Sicker > --=20 Matt Sicker --089e0115f41ac3967404f708c6ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alright, here's what I'm thinking so far:

=
Add a class named something like LoggerContextFactoryRegistry (y= eah I hate that name already). Make it a singleton class. It should keep a = SortedMap of int -> LoggerContextFactory (similar to how they're sca= nned in LogManager). This class should also keep a volatile LoggerContextFa= ctory containing the current factory so it doesn't have to be recalcula= ted every time. It can be updated instead when a new factory is registered.=

Method-wise, it should have a getFactory() and a regist= er(int, LoggerContextFactory) (or call it registerFactory?) method. A lot o= f the static initialisation of LogManager can be moved to the constructor i= n this class.

Being able to register the class instance itself (or th= e class?) works better than just scanning files due to class loader differe= nces 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 f= irst to get more feedback, but this part of the implementation may be rathe= r 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 LogM= anager initialisation. I'd prefer that to keep a registry of LoggerCont= extFactories so that a different factory can be registered later on (for in= stance, in OSGi, you could install log4j-api, then log4j-core, and core wou= ld register itself and take over as the default factory).

Anything more complex than that (like being able to use mult= iple factories concurrently like you can with contexts), while not necessar= ily requiring API changes, will require some thought as to how and if it= 9;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). Basic= ally, that part shouldn't be hard to make backwards compatible.


On 14 April 2014 10:25, Ralph Goers <= ralph.goers= @dslextreme.com> wrote:
Hopefull= y the changes won=E2=80=99t be too significant. =C2=A0Can you please post w= hat you intend to do before commit?

Ralph
=

On Apr 14, 2014, at 7:55 AM, Matt Sicker <<= a href=3D"mailto:boards@gmail.com" target=3D"_blank">boards@gmail.com&g= t; wrote:

I was thinking about how to best support stra= nge class loader environments (like OSGi or Servlets), and in order to supp= ort 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, w= e'd fall back to the SimpleLogger implementation when none are register= ed. 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 ini= tialization=C2=A0still makes sense to pre-load the registry, but imagine th= e 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 ch= anges 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 framew= ork (core or as a regular bundle). This will certainly help adoption by the= container projects.=C2=A0



--
Matt Sicker <boards@gmail.com>



--
Matt Sicker <boards@gmail.com>



--
Matt Sicker = <boards@gmail.com<= /a>>
--089e0115f41ac3967404f708c6ff--