You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2006/02/20 00:02:07 UTC
[logging] JCL2.0 design - Architecture
Hi,
I'd like to kick off discussions on what a Jakarta Commons Logging 2.x
release might look like. This thread is on the topic of the JCL general
architecture.
== Static Binding
In the 1.x series, there is an attempt to make one jarfile serve all
possible users. This makes life easier in some ways for development and
users. However it's becoming increasingly clear that the uses of JCL are
so diverse that this isn't feasable.
There appears to be consensus that a JCL 2.x series should instead
provide a number of separate jars each implementing the same interfaces,
and users should choose a jar that fits their needs. ?? Does anyone have
an objection or concern about this approach ??
Acknowledgements: The SLF4J project (founder: Ceki Gulcu) has pioneered
this separate-jar-per-libary approach, and coined the term "static
binding" for it. Many of the ideas suggested here are borrowed from that
project.
With a "static binding" approach, there is a jar for each supported
logging library. For example, "commons-logging-log4j.jar". Each jar
provides its own copy of the core classes LogFactory and Log. The
LogFactory provided by each jar is slightly different - the
implementation is modified to match the concrete logging implementation
[though the API of course remains binary-compatible with all others].
Other support classes (a Log implementation, a LogFactory subclass, etc)
would also be bundled. There would be no discovery process as the
bundled LogFactory only supports one particular library. There would be
no "TCCL" related code at all. This jar would therefore be perfect for
stand-alone applications that want to bridge to the supported library;
no unused code is present. It would also suit "web applications" within
a container as long as the user didn't want the kind of functionality
that TCCL-aware implementations provide. Alternatively, if the
underlying logging library is TCCL-aware, then this jar might be
appropriate even in container environments. Because of the reduction in
functionality the code should be much simpler and therefore more
reliable. It should also be simpler to support Java 1.1 etc without any
of the ugly reflection tricks currently in use.
There will still be a need for TCCL-enabled functionality, however. This
can be provided via another family of jarfiles (one per concrete logging
library), eg commons-logging-log4j-tccl.jar.
Do we want to keep the "auto-discover" functionality currently in
commons-logging? If so, this could be provided as yet another jarfile.
Regarding the way that this "family" of jarfiles is generated: clearly
it would not be desirable to have lots of copy-and-paste. The SLF4J
project uses various compile-time tricks to use .java files as
"templates" that are modified before compilation to bind to the various
logging library implementations. An alternative suggested by Robert
Donkin is to build some kind of bytecode modifier tool (using ASM or
BCEL presumably) to post-process .jar files so that common code links
directly to the relevant logging library. Neither approach has been
actually implemented for JCL at the current time.
Comments?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Dennis Lundberg <de...@apache.org>.
Boris Unckel wrote:
> Good Morning,
>
> Dennis Lundberg wrote:
>> I haven't used java.util.logging so I might be way off here. How about
>> having *both* JCL 1 and j.u.l APIs in JCL 2. I don't even know if this
>> is possible, but it could be a nice path forward if, as someone else
>> suggested, j.u.l will be *the* logging API 5 years down the road.
>
> this has been done for http://www.x4juli.org
> see
> http://svn.berlios.de/viewcvs/x4juli/trunk/src/java/org/x4juli/X4JuliLogger.java?view=markup
>
> http://svn.berlios.de/viewcvs/x4juli/trunk/src/java/org/x4juli/JCLFactory.java?view=markup
>
>
> Regards
> Boris
Oh I see, thanks Boris I'll have look then.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Boris Unckel <bo...@gmx.net>.
Good Morning,
Dennis Lundberg wrote:
> I haven't used java.util.logging so I might be way off here. How about
> having *both* JCL 1 and j.u.l APIs in JCL 2. I don't even know if this
> is possible, but it could be a nice path forward if, as someone else
> suggested, j.u.l will be *the* logging API 5 years down the road.
this has been done for http://www.x4juli.org
see
http://svn.berlios.de/viewcvs/x4juli/trunk/src/java/org/x4juli/X4JuliLogger.java?view=markup
http://svn.berlios.de/viewcvs/x4juli/trunk/src/java/org/x4juli/JCLFactory.java?view=markup
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Dennis Lundberg <de...@apache.org>.
Remy Maucherat wrote:
> I am not very enthusiastic (from the container perspective). Let's see:
> - Static discovery may look nice to some, but given the most likely
> class overloading rules, it means the whole container and its
> applications would use a single logging framework (which is ok in many
> cases, though). So IMO you need to keep a working dynamic discovery.
> - Please continue providing support for using the TCCL (as the TCCL -
> or similar - is used in most JNDI impls, doing otherwise is a bit
> redudant as far as I am concerned, and JNDI access is most likely
> slower).
> - If you're changing the API, I think you should consider using
> java.util.logging as the facade API to replace the commons-logging 1.0
> API. While the API exposed might be a bit sub optimal, this would be
> the most "standard" way from users' perspective.
I haven't used java.util.logging so I might be way off here. How about
having *both* JCL 1 and j.u.l APIs in JCL 2. I don't even know if this
is possible, but it could be a nice path forward if, as someone else
suggested, j.u.l will be *the* logging API 5 years down the road.
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Torsten Curdt <tc...@apache.org>.
> For an application, whichever logging lib you want to bundle with the
> app.
>
> For a library, any one of them will do. The commons-logging-
> noop.jar is
> the simplest one so probably the most convenient. A user of the
> library
> can then substitute any other jar they want instead.
>
> Does that work for you?
Yepp ...sounds fine
cheers
--
Torsten
Re: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
On Thu, 2006-02-23 at 17:11 +1100, Torsten Curdt wrote:
> On 23.02.2006, at 16:43, Simon Kitching wrote:
>
> > On Thu, 2006-02-23 at 13:10 +1100, Torsten Curdt wrote:
> >>> Agreed. How I see it working is:
> >>>
> >>> commons-logging-log4j.jar:
> >>> LogFactory tweaked to delegate to LogFactoryLog4j
> >>> LogFactoryLog4j - concrete subclass log LogFactory
> >>> Log -- standard Log interface
> >>> Log4JLogger -- implementation of Log interface for log4j
> >>>
> >>> commons-logging-jul.jar:
> >>> LogFactory tweaked to delegate to LogFactoryJUL
> >>> LogFactoryJUL - concrete subclass log LogFactory
> >>> Log -- standard Log interface
> >>> JULLogger -- implementation of Log interface for
> >>> java.util.logging
> >>>
> >>> commons-logging-dynamic.jar:
> >>> LogFactory tweaked to delegate to LogFactoryDynamic
> >>> LogFactoryDynamic : essentially the existing LogFactoryImpl
> >>> LogFactoryLog4j
> >>> Log4JLogger
> >>> LogFactoryJUL
> >>> JULLogger
> >>> ......
> >>>
> >>> Standalone applications, applets, embedded systems would use a
> >>> lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL
> >>> stuff,
> >>> no dynamic discovery stuff, only one logging adapter.
> >>
> >> And commons-logging-api.jar with the facade I assume
> >
> > No. Each of the jars above is stand-alone, because it includes
> > LogFactory and Log which are the public API to all JCL functionality
> > (the "facade"). They happen to include a slightly *different*
> > LogFactory.class file, but the binary interface is the same for each.
>
> Hm... so where would I declare a dependency against in my pom?
For an application, whichever logging lib you want to bundle with the
app.
For a library, any one of them will do. The commons-logging-noop.jar is
the simplest one so probably the most convenient. A user of the library
can then substitute any other jar they want instead.
Does that work for you?
> > Example:
> >
> > log.debugI18N(MsgKeys.KEYBOARD_ON_FIRE,
> > new Object[] {explosionDate, fireTemperature});
>
> sure ...although e.g. your english text could be the key
>
> So what I pointing to was the array vs parameter question
> ...or any other way around that. Actually something like
> that could work:
>
> log.parameter(value1).parameter(value2).debug(key)
>
> ...but we would need to create and return objects for that.
> Not sure if that's any better than the array approach. It's
> also the reverse order of what people are used to.
Yep. Need to think about that for a bit, but probably not going to fly
for both performance and usability. All options worth considering
though.
The main issue with this "array-of-params" stuff is that I'm not sure
about the performance of requiring an Object[] to be created in order to
invoke the log method (when the logging threshold may cause the contents
to be ignored anyway).
Another issue is the performance of the string interpolation required to
insert the params into the message.
And the final issue is that adding all this makes the Log API larger and
clumsier.
The final point is that this can be implemented at the user level
anyway, as long as i18n is not involved:
if (log.isDebugEnabled()) {
log.debug( MyUtils.createMessage("A {} occurred at {}", p1, p2) );
}
However it *is* convenient to have it in JCL core. And it's mandatory
*if* we support I18N logging in some manner.
> > The main problem with this is when JCL is used to bridge to an
> > underlying lib that doesn't support i18n. In this case, what do we do?
> > Implementing i18n inside JCL is not nice - JCL is supposed to be a
> > trivial adapter layer, not a logging implementation.
>
> agreed
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Torsten Curdt <tc...@apache.org>.
On 23.02.2006, at 16:43, Simon Kitching wrote:
> On Thu, 2006-02-23 at 13:10 +1100, Torsten Curdt wrote:
>>> Agreed. How I see it working is:
>>>
>>> commons-logging-log4j.jar:
>>> LogFactory tweaked to delegate to LogFactoryLog4j
>>> LogFactoryLog4j - concrete subclass log LogFactory
>>> Log -- standard Log interface
>>> Log4JLogger -- implementation of Log interface for log4j
>>>
>>> commons-logging-jul.jar:
>>> LogFactory tweaked to delegate to LogFactoryJUL
>>> LogFactoryJUL - concrete subclass log LogFactory
>>> Log -- standard Log interface
>>> JULLogger -- implementation of Log interface for
>>> java.util.logging
>>>
>>> commons-logging-dynamic.jar:
>>> LogFactory tweaked to delegate to LogFactoryDynamic
>>> LogFactoryDynamic : essentially the existing LogFactoryImpl
>>> LogFactoryLog4j
>>> Log4JLogger
>>> LogFactoryJUL
>>> JULLogger
>>> ......
>>>
>>> Standalone applications, applets, embedded systems would use a
>>> lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL
>>> stuff,
>>> no dynamic discovery stuff, only one logging adapter.
>>
>> And commons-logging-api.jar with the facade I assume
>
> No. Each of the jars above is stand-alone, because it includes
> LogFactory and Log which are the public API to all JCL functionality
> (the "facade"). They happen to include a slightly *different*
> LogFactory.class file, but the binary interface is the same for each.
Hm... so where would I declare a dependency against in my pom?
>>> I had made the assumption that JCL would be
>>> supporting java versions earlier than 1.4. I guess I should check,
>>> but I
>>> would think that the consensus is that we can't assume 1.4+ for
>>> JCL2.x
>>
>> *shrug* for simple things like this there are always backports ;-)
>
> I believe that JVMs don't allow classes in java.* packages to be
> loaded
> from anything but rt.jar.
Doh! ...of course not! ...was obviously too late last night ;)
> I also believe there would be legal issues with Apache issuing code
> that
> is in a java.* package. The Apache MyFaces does release javax.faces.*
> classes but it does have an explicit agreement with Sun.
>
> So AFAIK there's no way to "backport" java APIs.
>
>>> Some of the i18n ideas also need consideration.
>>
>> Like that?
>>
>> debug("my i18n text in {}", new Object[]{language});
>>
>> I don't see many options for i18n except having
>>
>> debug( final String pMessage, final Object pValue);
>> debug( final String pMessage, final Object pValue1, final Object
>> pValue2);
>> ...
>>
>> in an interface which is really ugly. Pragmatic - but ugly ;)
>
> No, not quite like that. The point of i18n support is *not* to encode
> any literal output in the code at all. Having parameterised
> messages as
> shown above is a prerequisite for this, but the "message" param has to
> become a key.
> Example:
>
> log.debugI18N(MsgKeys.KEYBOARD_ON_FIRE,
> new Object[] {explosionDate, fireTemperature});
sure ...although e.g. your english text could be the key
So what I pointing to was the array vs parameter question
...or any other way around that. Actually something like
that could work:
log.parameter(value1).parameter(value2).debug(key)
...but we would need to create and return objects for that.
Not sure if that's any better than the array approach. It's
also the reverse order of what people are used to.
> The main problem with this is when JCL is used to bridge to an
> underlying lib that doesn't support i18n. In this case, what do we do?
> Implementing i18n inside JCL is not nice - JCL is supposed to be a
> trivial adapter layer, not a logging implementation.
agreed
cheers
--
Torsten
Re: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
On Thu, 2006-02-23 at 13:10 +1100, Torsten Curdt wrote:
> > Agreed. How I see it working is:
> >
> > commons-logging-log4j.jar:
> > LogFactory tweaked to delegate to LogFactoryLog4j
> > LogFactoryLog4j - concrete subclass log LogFactory
> > Log -- standard Log interface
> > Log4JLogger -- implementation of Log interface for log4j
> >
> > commons-logging-jul.jar:
> > LogFactory tweaked to delegate to LogFactoryJUL
> > LogFactoryJUL - concrete subclass log LogFactory
> > Log -- standard Log interface
> > JULLogger -- implementation of Log interface for java.util.logging
> >
> > commons-logging-dynamic.jar:
> > LogFactory tweaked to delegate to LogFactoryDynamic
> > LogFactoryDynamic : essentially the existing LogFactoryImpl
> > LogFactoryLog4j
> > Log4JLogger
> > LogFactoryJUL
> > JULLogger
> > ......
> >
> > Standalone applications, applets, embedded systems would use a
> > lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL
> > stuff,
> > no dynamic discovery stuff, only one logging adapter.
>
> And commons-logging-api.jar with the facade I assume
No. Each of the jars above is stand-alone, because it includes
LogFactory and Log which are the public API to all JCL functionality
(the "facade"). They happen to include a slightly *different*
LogFactory.class file, but the binary interface is the same for each.
>
> > I had made the assumption that JCL would be
> > supporting java versions earlier than 1.4. I guess I should check,
> > but I
> > would think that the consensus is that we can't assume 1.4+ for JCL2.x
>
> *shrug* for simple things like this there are always backports ;-)
I believe that JVMs don't allow classes in java.* packages to be loaded
from anything but rt.jar.
I also believe there would be legal issues with Apache issuing code that
is in a java.* package. The Apache MyFaces does release javax.faces.*
classes but it does have an explicit agreement with Sun.
So AFAIK there's no way to "backport" java APIs.
> > Some of the i18n ideas also need consideration.
>
> Like that?
>
> debug("my i18n text in {}", new Object[]{language});
>
> I don't see many options for i18n except having
>
> debug( final String pMessage, final Object pValue);
> debug( final String pMessage, final Object pValue1, final Object
> pValue2);
> ...
>
> in an interface which is really ugly. Pragmatic - but ugly ;)
No, not quite like that. The point of i18n support is *not* to encode
any literal output in the code at all. Having parameterised messages as
shown above is a prerequisite for this, but the "message" param has to
become a key.
Example:
log.debugI18N(MsgKeys.KEYBOARD_ON_FIRE,
new Object[] {explosionDate, fireTemperature});
There MsgKeys.KEYBOARD_ON_FIRE is a *key* that is used to look up the
real message text into which the parameters are then inserted.
The main problem with this is when JCL is used to bridge to an
underlying lib that doesn't support i18n. In this case, what do we do?
Implementing i18n inside JCL is not nice - JCL is supposed to be a
trivial adapter layer, not a logging implementation.
It looks to me like j.u.l's logging methods (eg Logger.warning) try to
use the message parameter first as a key into the logger's resource
bundle (possibly inherited from its parent), and as a literal string if
that fails. Log4j, on the other hand, has different methods for i18n vs
literal messages. JCL would therefore *have* to support the log4j
approach, otherwise we would never know which log4j method to invoke.
All interesting issues to ponder...
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Torsten Curdt <tc...@apache.org>.
> Agreed. How I see it working is:
>
> commons-logging-log4j.jar:
> LogFactory tweaked to delegate to LogFactoryLog4j
> LogFactoryLog4j - concrete subclass log LogFactory
> Log -- standard Log interface
> Log4JLogger -- implementation of Log interface for log4j
>
> commons-logging-jul.jar:
> LogFactory tweaked to delegate to LogFactoryJUL
> LogFactoryJUL - concrete subclass log LogFactory
> Log -- standard Log interface
> JULLogger -- implementation of Log interface for java.util.logging
>
> commons-logging-dynamic.jar:
> LogFactory tweaked to delegate to LogFactoryDynamic
> LogFactoryDynamic : essentially the existing LogFactoryImpl
> LogFactoryLog4j
> Log4JLogger
> LogFactoryJUL
> JULLogger
> ......
>
> Standalone applications, applets, embedded systems would use a
> lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL
> stuff,
> no dynamic discovery stuff, only one logging adapter.
And commons-logging-api.jar with the facade I assume
> I had made the assumption that JCL would be
> supporting java versions earlier than 1.4. I guess I should check,
> but I
> would think that the consensus is that we can't assume 1.4+ for JCL2.x
*shrug* for simple things like this there are always backports ;-)
> There are a few ideas in j.u.l that we could think about borrowing.
> Maybe we could provide "entering" and "exiting" logging calls,
> which map
> to DEBUG level on libs that don't have equivalents?
What we ended up doing lately to distinguish between logging
and tracing. Logging describes describes the logical flow and
is no longer used to spit out variables ...and then we used
AOP to generate the tracing to see what's going on only when
we really need it.
But let me get back on this when we rolled out that aproach ;)
> Maybe
> fine/finer/finest could be added which map to DEBUG? Personally
> I've not
> seen any great demand for this functionality on the JCL user or dev
> lists but if anyone does want these.....
>
> Some of the i18n ideas also need consideration.
Like that?
debug("my i18n text in {}", new Object[]{language});
I don't see many options for i18n except having
debug( final String pMessage, final Object pValue);
debug( final String pMessage, final Object pValue1, final Object
pValue2);
...
in an interface which is really ugly. Pragmatic - but ugly ;)
cheers
--
Torsten
Re: [logging] JCL2.0 design - Architecture
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-02-26 at 17:26 +1300, Simon Kitching wrote:
> On Sat, 2006-02-25 at 17:56 +0000, robert burrell donkin wrote:
> > it should be much more reliable to allow per TCCL configuration whilst
> > loading implementations from the class classloader. IMHO we've encourage
> > too much use of automagic configuration. suggesting that users use
> > various arrangements of jars to achieve configurations has proved a poor
> > plan. limited automagic configuration to just the class classloader
> > would be a major simplification.
>
> I don't see how that could work.
>
> If the underlying log implementation uses the TCCL to locate config
> info, then things are fairly simple; the user just disables TCCL
> functionality for JCL and lets the underlying logging system do its
> thing.
>
> But if the underlying log implementation is not TCCL-aware, and uses the
> ClassLoader which loaded the logging library to locate its config info,
> then JCL *must* load that implementation via the TCCL in order to get
> the desired behaviour when JCL is deployed in a "shared" location.
>
> And if we want to allow a webapp to redirect logging from classes it
> calls which are in a "shared" classpath into a logging lib that is *not*
> in the classpath (eg when webapp deploys log4j, container has something
> else) then again the TCCL must be used.
>
> I do agree that "magic" configuration wasn't a good idea in hindsight.
> Perhaps a commons-logging.properties file should be mandatory?
i was thinking along the lines of mandatory for actively choosing a
logging system. JCL could still make a reasonable guess but using a
properties file would become the primary recommended mechanism for
configuration.
> > i've also been toying with the idea of a Log implementation that
> > discovers which implementation to use based on the calling TCCL. when
> > debug is called, the Log implementation would be looked up. this would
> > allow a library to share a static implementation. of course the
> > configuration for each TCCL would have to be stored centrally.
>
> You mean this?
> public boolean isDebugEnabled() {
> // get tccl
> // build a (tccl, categoryname) pair
> // do a hashmap lookup using the above pair to get the real Logger
> // return realLogger.isDebugEnabled()
> }
> That will work under all circumstances, but the crippled performance
> would seem to make this an unworkable solution IMO.
i've been wondering about how big the performance impact would actually
be. it's a way of achieving true isolation for those that really need it
at a price. might encourage users to think about the trade-offs involved
a bit more than they do now.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2006-02-25 at 17:56 +0000, robert burrell donkin wrote:
> it should be much more reliable to allow per TCCL configuration whilst
> loading implementations from the class classloader. IMHO we've encourage
> too much use of automagic configuration. suggesting that users use
> various arrangements of jars to achieve configurations has proved a poor
> plan. limited automagic configuration to just the class classloader
> would be a major simplification.
I don't see how that could work.
If the underlying log implementation uses the TCCL to locate config
info, then things are fairly simple; the user just disables TCCL
functionality for JCL and lets the underlying logging system do its
thing.
But if the underlying log implementation is not TCCL-aware, and uses the
ClassLoader which loaded the logging library to locate its config info,
then JCL *must* load that implementation via the TCCL in order to get
the desired behaviour when JCL is deployed in a "shared" location.
And if we want to allow a webapp to redirect logging from classes it
calls which are in a "shared" classpath into a logging lib that is *not*
in the classpath (eg when webapp deploys log4j, container has something
else) then again the TCCL must be used.
I do agree that "magic" configuration wasn't a good idea in hindsight.
Perhaps a commons-logging.properties file should be mandatory?
>
> i've also been toying with the idea of a Log implementation that
> discovers which implementation to use based on the calling TCCL. when
> debug is called, the Log implementation would be looked up. this would
> allow a library to share a static implementation. of course the
> configuration for each TCCL would have to be stored centrally.
You mean this?
public boolean isDebugEnabled() {
// get tccl
// build a (tccl, categoryname) pair
// do a hashmap lookup using the above pair to get the real Logger
// return realLogger.isDebugEnabled()
}
That will work under all circumstances, but the crippled performance
would seem to make this an unworkable solution IMO.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2006-02-20 at 13:31 +0100, Remy Maucherat wrote:
> On 2/20/06, Simon Kitching <sk...@apache.org> wrote:
<snip>
> > > - Please continue providing support for using the TCCL (as the TCCL -
> > > or similar - is used in most JNDI impls, doing otherwise is a bit
> > > redudant as far as I am concerned, and JNDI access is most likely
> > > slower).
> >
> > I'd be very interested in your opinion about the safety/stability of
> > TCCL-based solutions. I was looking at Sun's java bugtracker recently
> > and found an issue raised by JBoss stating that they wanted some
> > classloader synchronisation code changed as Marc Fleury has been
> > experimenting with "dependency-based classloaders that aren't tree
> > structured". From the comments it seems like a few other people are
> > experimenting with similar approaches. So is it still going to be safe
> > in the long run to assume every webapp has a distinct TCCL, and that it
> > is possible to walk up the classloader ancestry links to find all
> > possible implementations of a particular class?
>
> I was pointing out that TCCL was being used to track the logging
> environment. For classloading itself, it's up to you to figure it out
> :)
+1
it should be much more reliable to allow per TCCL configuration whilst
loading implementations from the class classloader. IMHO we've encourage
too much use of automagic configuration. suggesting that users use
various arrangements of jars to achieve configurations has proved a poor
plan. limited automagic configuration to just the class classloader
would be a major simplification.
i've also been toying with the idea of a Log implementation that
discovers which implementation to use based on the calling TCCL. when
debug is called, the Log implementation would be looked up. this would
allow a library to share a static implementation. of course the
configuration for each TCCL would have to be stored centrally.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Remy Maucherat <re...@gmail.com>.
On 2/20/06, Simon Kitching <sk...@apache.org> wrote:
> Standalone applications, applets, embedded systems would use a
> lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL stuff,
> no dynamic discovery stuff, only one logging adapter.
>
> Webapps that want to use a specific logging lib would bundle a
> lib-specific jar (of course that only works when child-first
> classloading is selected or the container doesn't provide JCL). [1]
>
> Containers would generally bundle commons-logging-dynamic.jar, and would
> end up with exactly the same functionality that exists now. They *could*
> (as you mention) use a lib-specific implementation if they are happy to
> have every webapp use one logging lib but commons-logging-dynamic would
> be the usual choice.
That's good. I think the ability to prevent webapps from using the
logging they want could be a good feature too.
> As a result, this wouldn't reduce any of the existing complexity for
> JCL-in-containers (except that we can discard code that tries to handle
> embedded systems & java1.1, as those systems can use the lib-specific
> ones). However I hope we've nailed many of the outstanding
> container-based issues in the 1.1 release anyway, which
> LogFactoryDynamic will effectively inherit. This *will* resolve issues
> in non-container environments as those can use the simpler jars.
>
> [1] Hmm..one thing we've discovered is that it's a bad idea to have two
> jars in the classpath providing the Log interface. JCL1.1 provides a
> "commons-logging-adapters.jar" for webapps to use when the container
> provides commons-logging.jar. But the proposed jars I've shown here
> include Log so aren't safe to use from a webapp when any other jcl jar
> is in a shared path. More thought needed :-(
Yes, usually, there are problems with multiple Log definitions.
> > - Please continue providing support for using the TCCL (as the TCCL -
> > or similar - is used in most JNDI impls, doing otherwise is a bit
> > redudant as far as I am concerned, and JNDI access is most likely
> > slower).
>
> I'd be very interested in your opinion about the safety/stability of
> TCCL-based solutions. I was looking at Sun's java bugtracker recently
> and found an issue raised by JBoss stating that they wanted some
> classloader synchronisation code changed as Marc Fleury has been
> experimenting with "dependency-based classloaders that aren't tree
> structured". From the comments it seems like a few other people are
> experimenting with similar approaches. So is it still going to be safe
> in the long run to assume every webapp has a distinct TCCL, and that it
> is possible to walk up the classloader ancestry links to find all
> possible implementations of a particular class?
I was pointing out that TCCL was being used to track the logging
environment. For classloading itself, it's up to you to figure it out
:)
> > - If you're changing the API, I think you should consider using
> > java.util.logging as the facade API to replace the commons-logging 1.0
> > API. While the API exposed might be a bit sub optimal, this would be
> > the most "standard" way from users' perspective. See JULI in Tomcat,
> > and www.x4juli.org for java.util.logging "implementations" (providers
> > may be more accurate), but both are done using the
> > full-logging-implementation way, so maybe not very good examples, as
> > you would want to only develop facades.
>
> I don't quite understand what you mean here.
>
> Are you suggesting that commons-logging-xxx.jar should include our
> implementations of "java.util.logging.*" classes? I don't think that's
> allowed/possible...
I think providing a LogManager and the appropriate facade Loggers, I
don't see why it wouldn't work, but I didn't look that deeply into the
feasability.
> Or are you suggesting that we write an implementation of
> j.u.l.LogManager so that the commons-logging-xxx.jar can be "plugged in"
> as a j.u.l implementation? I had made the assumption that JCL would be
> supporting java versions earlier than 1.4. I guess I should check, but I
> would think that the consensus is that we can't assume 1.4+ for JCL2.x
Well, that works too I guess, you could have one of the facades be a
facade for c-l.
> Or are you suggesting that we model the JCL api on j.u.l so that moving
> between the two is a minor search-and-replace? I agree that j.u.l is
> eventually going to be the standard logging interface (5-10 years away)
> by virtue of it being in the java standard libs. However there is
> significant benefit for the JCL project in keeping changes to the
> existing API small; the major users of JCL2.x will be existing JCL1.x
> users. In addition, much of the j.u.l API is about configuration which
> is something that JCL explicitly doesn't do; it wraps the *logging*
> parts only. JCL also has to be a "least common denominator" API, so
> deliberately leaves out things like a Level class. By the time all those
> things are left out, I don't think the remainder would look much like
> j.u.l anyway!
Personally, if I have to change the logging API, I would rather switch
to a standard now (if it's possible). As far as c-l goes, if
supporting old JDKs is necessary, this could be an issue ;)
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
Hi Remy,
Great to hear from you on this!
On Mon, 2006-02-20 at 01:56 +0100, Remy Maucherat wrote:
> I am not very enthusiastic (from the container perspective). Let's see:
> - Static discovery may look nice to some, but given the most likely
> class overloading rules, it means the whole container and its
> applications would use a single logging framework (which is ok in many
> cases, though). So IMO you need to keep a working dynamic discovery.
Agreed. How I see it working is:
commons-logging-log4j.jar:
LogFactory tweaked to delegate to LogFactoryLog4j
LogFactoryLog4j - concrete subclass log LogFactory
Log -- standard Log interface
Log4JLogger -- implementation of Log interface for log4j
commons-logging-jul.jar:
LogFactory tweaked to delegate to LogFactoryJUL
LogFactoryJUL - concrete subclass log LogFactory
Log -- standard Log interface
JULLogger -- implementation of Log interface for java.util.logging
commons-logging-dynamic.jar:
LogFactory tweaked to delegate to LogFactoryDynamic
LogFactoryDynamic : essentially the existing LogFactoryImpl
LogFactoryLog4j
Log4JLogger
LogFactoryJUL
JULLogger
......
Standalone applications, applets, embedded systems would use a
lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL stuff,
no dynamic discovery stuff, only one logging adapter.
Webapps that want to use a specific logging lib would bundle a
lib-specific jar (of course that only works when child-first
classloading is selected or the container doesn't provide JCL). [1]
Containers would generally bundle commons-logging-dynamic.jar, and would
end up with exactly the same functionality that exists now. They *could*
(as you mention) use a lib-specific implementation if they are happy to
have every webapp use one logging lib but commons-logging-dynamic would
be the usual choice.
As a result, this wouldn't reduce any of the existing complexity for
JCL-in-containers (except that we can discard code that tries to handle
embedded systems & java1.1, as those systems can use the lib-specific
ones). However I hope we've nailed many of the outstanding
container-based issues in the 1.1 release anyway, which
LogFactoryDynamic will effectively inherit. This *will* resolve issues
in non-container environments as those can use the simpler jars.
[1] Hmm..one thing we've discovered is that it's a bad idea to have two
jars in the classpath providing the Log interface. JCL1.1 provides a
"commons-logging-adapters.jar" for webapps to use when the container
provides commons-logging.jar. But the proposed jars I've shown here
include Log so aren't safe to use from a webapp when any other jcl jar
is in a shared path. More thought needed :-(
> - Please continue providing support for using the TCCL (as the TCCL -
> or similar - is used in most JNDI impls, doing otherwise is a bit
> redudant as far as I am concerned, and JNDI access is most likely
> slower).
I'd be very interested in your opinion about the safety/stability of
TCCL-based solutions. I was looking at Sun's java bugtracker recently
and found an issue raised by JBoss stating that they wanted some
classloader synchronisation code changed as Marc Fleury has been
experimenting with "dependency-based classloaders that aren't tree
structured". From the comments it seems like a few other people are
experimenting with similar approaches. So is it still going to be safe
in the long run to assume every webapp has a distinct TCCL, and that it
is possible to walk up the classloader ancestry links to find all
possible implementations of a particular class?
> - If you're changing the API, I think you should consider using
> java.util.logging as the facade API to replace the commons-logging 1.0
> API. While the API exposed might be a bit sub optimal, this would be
> the most "standard" way from users' perspective. See JULI in Tomcat,
> and www.x4juli.org for java.util.logging "implementations" (providers
> may be more accurate), but both are done using the
> full-logging-implementation way, so maybe not very good examples, as
> you would want to only develop facades.
I don't quite understand what you mean here.
Are you suggesting that commons-logging-xxx.jar should include our
implementations of "java.util.logging.*" classes? I don't think that's
allowed/possible...
Or are you suggesting that we write an implementation of
j.u.l.LogManager so that the commons-logging-xxx.jar can be "plugged in"
as a j.u.l implementation? I had made the assumption that JCL would be
supporting java versions earlier than 1.4. I guess I should check, but I
would think that the consensus is that we can't assume 1.4+ for JCL2.x
Or are you suggesting that we model the JCL api on j.u.l so that moving
between the two is a minor search-and-replace? I agree that j.u.l is
eventually going to be the standard logging interface (5-10 years away)
by virtue of it being in the java standard libs. However there is
significant benefit for the JCL project in keeping changes to the
existing API small; the major users of JCL2.x will be existing JCL1.x
users. In addition, much of the j.u.l API is about configuration which
is something that JCL explicitly doesn't do; it wraps the *logging*
parts only. JCL also has to be a "least common denominator" API, so
deliberately leaves out things like a Level class. By the time all those
things are left out, I don't think the remainder would look much like
j.u.l anyway!
There are a few ideas in j.u.l that we could think about borrowing.
Maybe we could provide "entering" and "exiting" logging calls, which map
to DEBUG level on libs that don't have equivalents? Maybe
fine/finer/finest could be added which map to DEBUG? Personally I've not
seen any great demand for this functionality on the JCL user or dev
lists but if anyone does want these.....
Some of the i18n ideas also need consideration.
> --
> xxxxxxxxxxxxxxxxxxxxxxxxx
> Rémy Maucherat
> Developer & Consultant
> JBoss Group (Europe) SàRL
> xxxxxxxxxxxxxxxxxxxxxxxxx
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Remy Maucherat <re...@gmail.com>.
I am not very enthusiastic (from the container perspective). Let's see:
- Static discovery may look nice to some, but given the most likely
class overloading rules, it means the whole container and its
applications would use a single logging framework (which is ok in many
cases, though). So IMO you need to keep a working dynamic discovery.
- Please continue providing support for using the TCCL (as the TCCL -
or similar - is used in most JNDI impls, doing otherwise is a bit
redudant as far as I am concerned, and JNDI access is most likely
slower).
- If you're changing the API, I think you should consider using
java.util.logging as the facade API to replace the commons-logging 1.0
API. While the API exposed might be a bit sub optimal, this would be
the most "standard" way from users' perspective. See JULI in Tomcat,
and www.x4juli.org for java.util.logging "implementations" (providers
may be more accurate), but both are done using the
full-logging-implementation way, so maybe not very good examples, as
you would want to only develop facades.
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2006-02-20 at 12:02 +1300, Simon Kitching wrote:
> Hi,
>
> I'd like to kick off discussions on what a Jakarta Commons Logging 2.x
> release might look like. This thread is on the topic of the JCL general
> architecture.
== Radical designs
I should note that it's a good time to toss around more radical designs.
For example, could we do away with the concrete Log objects completely?
Application/library code will have been compiled against a Log
interface. It would be nice to dynamically modify that code at runtime
to directly access the "log" object from the underlying library; not
really possible though.
The java.lang.reflect.Proxy class allows a class to be created at
runtime that implements the Log interface and redirects calls to an
InvocationHandler object. However there would still be a Proxy instance
created per underlying Log instance [and the method invocation penalty
would be much higher].
I know JBoss uses "interceptors" extensively; is there any concept there
that would be useful for logging?
== Static Log objects
One of the major issues with JCL at the moment is that this code works
great for apps, but is just wrong for libraries:
private static final Log log = LogFactory.getLog("foo");
The problem is that the Log object is created/configured when the
enclosing class is first loaded. If it uses a TCCL to find that
configuration then the Log object is forever bound to the config of the
first webapp that called the class (forced it to be initialised). The
current solution is simply to avoid static in library code. An
alternative would be for the Log object to check the TCCL on every call
to each of its methods but that isn't feasable for performance reasons.
== Do we need to use TCCLs?
Currently, the TCCL is used:
(a) as a key to separate different logging configurations
(b) as a classloader to locate concrete logging libs in a webapp
even when JCL is in a shared location.
(c) as a classloader to locate logging config files
The log4j site's documentation on their "RepositorySelector" proposes
using a unique string stored in JNDI to define (a), as J2EE specifies
that each webapp has its own JNDI namespace. This technique could also
be used for (c), ie store the config values or a filename in JNDI. It
won't solve (b).
Ref:
http://www.qos.ch/logging/sc.jsp
== Whose responsibility is logging anyway?
There are two views on this:
(a) the application administrator,
(b) the container administrator
If we look at things from the view of (a), then concrete logging libs
should always be deployed in a webapp, and the logging config file
should also be in the webapp. What happens if the webapp makes a call to
a class in a "shared" classpath which then makes a logging call? Well,
ideally the log info should have the webapp-specific thresholds applied,
and any output should go to the webapp's logfile.
If we look at things from the viewpoint of (b), then concrete logging
libs should always be deployed in a shared classpath and config files
should be there also. The webapp issues log messages, but doesn't
otherwise control thresholds or output destinations. In this case, any
TCCL-related behaviour by commons-logging is wrong. The container
administrator may well want to apply different logging config per webapp
but will select a logging library that can handle that.
I think we need to support both, but if (b) is needed only then that
would simplify things a bit.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Mark Womack <mw...@apache.org>.
Hi Boris,
It is a bit early for us to put any real details around log4j 2.0. I
think it is going to be some fundamental rethinking of the api, etc.
So, to say that log4j 2.0 will provide a native implementation of
o.a.c.l.Log, I am not sure. Maybe other committers have an opinion.
I suspect the issues will be similar to the issues with implementing a
native version of the slf4j api. Also, if jcl 2.0 is moving forward
now, we might want to consider something closer to the 1.3 timeframe.
I think we are more concerned about the confusing classloader issues
in the current jcl implementation.
But, I am all for dicussing this further and seeing where it goes.
Can we move the dicussion to a common discussion list that does not
have a lot of extraneous noise? I don't suscribe to the jakarta
commons-dev because 99% of its contents I do not need/want to
track/filter on a daily basis.
thanks,
-Mark
On 2/20/06, Boris Unckel <bo...@gmx.net> wrote:
> Hello,
>
> I know crossposting is not not wanted usually, but the case legitimates.
>
> The original thread on commons-dev discusses design of JCL2.0 for
> archticture and API,
> there were already some discussions about log4j 2.0 (i.E.
> http://marc.theaimsgroup.com/?l=log4j-dev&m=113625138015434&w=2).
>
> Maybe this is a good point to talk again about the possibility to
> combine both APIs.
> (Similiar discussion, but not completely matching:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34185)
>
> log4j 2.0 could implement o.a.c.l.Log and JCL2.0 could detect this
> native implementation and
> avoid the use of an wrapper class.
>
> What do you think?
>
> Regards
> Boris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Mark Womack <mw...@apache.org>.
Hi Boris,
It is a bit early for us to put any real details around log4j 2.0. I
think it is going to be some fundamental rethinking of the api, etc.
So, to say that log4j 2.0 will provide a native implementation of
o.a.c.l.Log, I am not sure. Maybe other committers have an opinion.
I suspect the issues will be similar to the issues with implementing a
native version of the slf4j api. Also, if jcl 2.0 is moving forward
now, we might want to consider something closer to the 1.3 timeframe.
I think we are more concerned about the confusing classloader issues
in the current jcl implementation.
But, I am all for dicussing this further and seeing where it goes.
Can we move the dicussion to a common discussion list that does not
have a lot of extraneous noise? I don't suscribe to the jakarta
commons-dev because 99% of its contents I do not need/want to
track/filter on a daily basis.
thanks,
-Mark
On 2/20/06, Boris Unckel <bo...@gmx.net> wrote:
> Hello,
>
> I know crossposting is not not wanted usually, but the case legitimates.
>
> The original thread on commons-dev discusses design of JCL2.0 for
> archticture and API,
> there were already some discussions about log4j 2.0 (i.E.
> http://marc.theaimsgroup.com/?l=log4j-dev&m=113625138015434&w=2).
>
> Maybe this is a good point to talk again about the possibility to
> combine both APIs.
> (Similiar discussion, but not completely matching:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34185)
>
> log4j 2.0 could implement o.a.c.l.Log and JCL2.0 could detect this
> native implementation and
> avoid the use of an wrapper class.
>
> What do you think?
>
> Regards
> Boris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Boris Unckel <bo...@gmx.net>.
Hello,
I know crossposting is not not wanted usually, but the case legitimates.
The original thread on commons-dev discusses design of JCL2.0 for
archticture and API,
there were already some discussions about log4j 2.0 (i.E.
http://marc.theaimsgroup.com/?l=log4j-dev&m=113625138015434&w=2).
Maybe this is a good point to talk again about the possibility to
combine both APIs.
(Similiar discussion, but not completely matching:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34185)
log4j 2.0 could implement o.a.c.l.Log and JCL2.0 could detect this
native implementation and
avoid the use of an wrapper class.
What do you think?
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL2.0 design - Architecture
Posted by Boris Unckel <bo...@gmx.net>.
Hello,
I know crossposting is not not wanted usually, but the case legitimates.
The original thread on commons-dev discusses design of JCL2.0 for
archticture and API,
there were already some discussions about log4j 2.0 (i.E.
http://marc.theaimsgroup.com/?l=log4j-dev&m=113625138015434&w=2).
Maybe this is a good point to talk again about the possibility to
combine both APIs.
(Similiar discussion, but not completely matching:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34185)
log4j 2.0 could implement o.a.c.l.Log and JCL2.0 could detect this
native implementation and
avoid the use of an wrapper class.
What do you think?
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-02-19 at 21:21 -0500, Noel J. Bergman wrote:
> Simon Kitching wrote:
>
> > My conclusion at the end of the last round of debate on that was that
> > their "enterprise logging" stuff did not belong in JCL at all.
>
> Such as? I think that we should support the functionality that has been
> added to Java, such as tracing levels. And we should support localization.
By tracing levels you mean fine/finer/finest? That's ok as long as there
is demand for it. But equally there's not much point implementing it if
no-one wants to use it. I've not seen evidence for demand so far....
> Remy has already commented that we need to properly support containers.
Remy mentioned that separation of logging based on TCCL is still useful
(which I think we all agree on). Was there anything else under the
category of "properly support containers"?
> Following on Remy's comments about JULI, what do we expect JCL 2 to offer
> that isn't now in standard Java logging (assuming the presence of JULI or
> similar under the API)?
Mainly the ability to run under java 1.1 or later. As I mentioned in my
reply to Remy, I see the j.u.l API becoming the standard logging API
eventually (with various LogManager implementations providing better
functionality than the default logging implementation behind the
scenes). However any library that wants to suport pre-1.4 JVMs must
avoid j.u.l (and hence JULI) - and that's a lot of libraries.
In addition, there are a lot of existing libraries that cannot be used
as "backing implementations" of j.u.l, ie for which no reasonable
j.u.l->lib adapters can be written. This is because JCL is a "minimal"
API while j.u.l is a vastly more complicated API. In some cases, writing
an adapter for j.u.l may be impossible because concepts in j.u.l don't
exist in the target lib.
And writing an adapter from JCL to proprietory.logging.kit is much
easier than writing a j.u.l adapter for exactly the same reason.
Hopefully proprietory logging kits are slowly on the way out now that
there are a number of good open source ones available but....
The point of JCL is for libraries to avoid imposing any particular
logging implementation on the using application. The ability to easily
write adapters for arbitrary logging libs is fundamental to that.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] JCL2.0 design - Architecture
Posted by "Noel J. Bergman" <no...@devtech.com>.
Simon Kitching wrote:
> My conclusion at the end of the last round of debate on that was that
> their "enterprise logging" stuff did not belong in JCL at all.
Such as? I think that we should support the functionality that has been
added to Java, such as tracing levels. And we should support localization.
Remy has already commented that we need to properly support containers.
IIRC, those were the highlights.
Following on Remy's comments about JULI, what do we expect JCL 2 to offer
that isn't now in standard Java logging (assuming the presence of JULI or
similar under the API)?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] JCL2.0 design - Architecture
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-02-19 at 19:29 -0500, Noel J. Bergman wrote:
> > Comments?
>
> Only to suggest since we're talking about JCL v2, with new architecture and
> API design, that we (re-)engage the folks from IBM who wanted to look at the
> needs for enterprise logging.
My conclusion at the end of the last round of debate on that was that
their "enterprise logging" stuff did not belong in JCL at all.
I'll have a look at the archives again, and summarise for the list
unless someone else wants to take that task on. However there's no point
in extending an invitation to debate it if the consensus here is that we
don't want to go in that direction....
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] JCL2.0 design - Architecture
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Comments?
Only to suggest since we're talking about JCL v2, with new architecture and
API design, that we (re-)engage the folks from IBM who wanted to look at the
needs for enterprise logging.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org