RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Ceki Gülcü wrote:

> Seriously, aren't you sick of JCL exploding with an
> LogConfigurationException at the most inappropriate times?

Actually, a few of us working on the eyebrowse migration kind of feel that
way about Log4J today.  log4j-1.1.3 and current don't have the same
behavior.  For details you'd have to talk with DLR.

FWIW, I notice that Craig and other participated in a thread on
"commons-logging & classloading" way back in '03:

http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-dev/200309.mbox/
[EMAIL PROTECTED]

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On Mon, 2005-02-07 at 18:57, Ceki Gülcü wrote:
> Robert, Richard,
> 
> Thank you both.

i think richard's explanation wins, though :) 

> On 2005-02-07 18:27:31, Richard Sitze wrote:
> 
>   >  System ClassLoader
>   >  |
>   >   +--+-+
>   >   ||
>   >  Host --- creates --> Sub
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

Robert, Richard,
Thank you both.
On 2005-02-07 18:27:31, Richard Sitze wrote:
 >  System ClassLoader
 >  |
 >   +--+-+
 >   ||
 >  Host --- creates --> Sub

--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Vic]

Richard Sitze wrote:
Can we bring these two together? 
Ceki, would your team be willing to make some concessions in the UGLI 
implementation, in the interest of supporting a common abstraction? 
Thoughts include:

- Leaving JCL 1.0.x alone... and retiring it altogether in favor of an 
UGLI based approach.
- Adopting the UGLI "style" interface as the base interface.
 

Hey, that sounds good to me as a user.  Even cross merging teams?
.V
--
Forums, Boards, Blogs and News in RiA 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Well I've had a few days to cool off, and my head feels better too.

I acknowledge that there are problems with the discovery process in JCL. 
We aim to fix that, it is one of the tenants of what is being proposed for 
JCL version 'next'.

I wish it were as simple to resolve these issues in the more difficult 
environments [of which J2EE is a prime example], so the bottom line is 
that the UGLI solution doesn't *solve* the problems, it just doesn't 
complain as much... which admittedly might be considered a step forward 
depending on your point of view [silently operate in an unexpected manner 
vs. loudly proclaiming that a problem exists].  For JCL 'next' I'm looking 
for something of a middle ground that really solves the problems... all of 
them [alternate notes have/will discuss this].

I'm thrilled that Log4J mapped their interface to an independent 
interface.  I'm sorry we couldn't coordinate that better between Log4J and 
JCL "way back" before JCL 1.0.  What concerns me is that we have competing 
"abstractions" that are intended to be layered above interfaces.

I also recognize the value of an interface not "tied" to Log4J, that we 
can grow forward and continue to layer above the implementations.

So... let me toss out a not-so-random thought, and let's see how we all 
feel about this after some discussion:  Can we bring these two together? 
Ceki, would your team be willing to make some concessions in the UGLI 
implementation, in the interest of supporting a common abstraction? 
Thoughts include:

- Leaving JCL 1.0.x alone... and retiring it altogether in favor of an 
UGLI based approach.
- Adopting the UGLI "style" interface as the base interface.
- Layering in the JCL Log methods [support backwards compatibility] as 
"deprecated" methods where they differ from the UGLI interface?
- We proposed a "separate jar file per impl" approach, in line with yours, 
to help minimize the JCL problems for JCL 'next'... so we're in sync with 
the fundamental advantages that offers
- Adopting a more sophisticated discovery that allows the "separate jar 
file per impl" approach to work in a defined way for class hierarchies 
[such as J2EE] that might include multiple/different UGLI jar files [and 
yes, I'm talking about a *FIXED* process, not the current broken process].
- Log4J MUST be willing to accept extentions to UGLI [via interfaces that 
extend] that might go over and beyond the Log4J native supported methods 
[i.e., open to the types of discussions that are occuring now with JCL]. 
If I'm out of line here, set me straight.. but Ceki I still see Log4J as 
being under your thumb, and there are others in the community with valid 
differences of opinions that are looking for a voice.  I'd like to point 
out that the JCL interface has been rigid, we've resisted change, and are 
only recently proposing any new change as extensions... I don't see this 
being a common occurance.


In short, can we merge these two in one fashion or another, and still 
accomplish our goals?




news <[EMAIL PROTECTED]> wrote on 01/25/2005 03:43:54 PM:

> I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if 
> anyone took offense.  I was just asking :)
> 
> Ceki, thanks for that link.  You have many excellent points, and I may 
> migrate my projects away from commons-logging.
> 
> Matt
> 
> Vic wrote:
> > Matt Sgarlata wrote:
> > 
> >> You've spent a lot of time discussing commons-logging on this list, 
> >> while at the same time supporting development of UGLI. Which 
component 
> >> is your favorite? How come you're working on 2?
> >>
> > Simmer down now. Lets act intelligent. Many people work on many things 

> > and share code across projectsâ itâs a friendly license.
> > 
> > Look at Struts, it has JSF subprojects under it, or lets play how many 

> > duplicate projects we can name under ASF. Itâs all good. Much 
> > duplication in Apache, all of it good.
> > 
> > Choice = = good. What was that platform where they have the ONE true 
way?
> > 
> > ..V
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Gary Gregory]

Richard:

You might find the attached GIF handy ;-)

Gary

-Original Message-
From: Richard Sitze [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 25, 2005 11:41 AM
To: Jakarta Commons Developers List
Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?

Well now... that IS interesting.


How in the WORLD did this happen?  I approached Ceki about aligning JCL 
with Log4J...  and was turned down, he simply wasn't interested and 
wouldn't acknowledge the value of the abstraction [at that time].

This feels like 'not-invented-here' and some backstabbing.  How can we 
POSSIBLY accomplish our goals if we simply refuse to acknowledge that 
other projects have value?!  What can we achieve with competing 
abstractions at this level?

Frankly, I expected better of the Apache Logging Services community.

Excuse me while I go find a wall and beat my head against it for a 
while...





news <[EMAIL PROTECTED]> wrote on 01/25/2005 01:21:24 PM:

> I kind of think that maybe commons-logging should be deprecated in

> favor of:
> http://logging.apache.org/log4j/docs/ugli.html
> 
> See UGLI does same thing. But competitions is a good thing; my
projects 
> will ship w/ Log4j instead and ugli. One less jar is good.
> .V
> 
> 
> Matt Sgarlata wrote:
> 
> > Richard Sitze wrote:
> >
> >> news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
> >>
> >>> +1, I agree with you and Ceki.  TRACE is debatable (I personally 
> >>> like it), more than TRACE is silly.
> >>
> >>
> >>
> >> Well... call them what you will, I want em'!! lol
> >>
> >> And yes, I'm leaning towards EXPLICITLY naming methods to encourage

> >> best practices.  To use the distinction made by Curt, I'm pushing
the 

> >> trace level methods towards diagnostic logger function, and
stepping 
> >> away from other uses entirely.  I'm going to refrain from doing a 
> >> full brain dump on all the fun thoughts now running through my 
> >> head... [separating trace level methods and messaging/admin level 
> >> methods into seperate interfaces.. ok I lied].
> >
> >
> > I think we can pretty much lay to rest the argument that including 
> > ENTER/EXIT is a "best practice".  There have been so many arguments
on 

> > both sides of the issue that it's pretty clear we're not going to 
> > reach a concensus.  A best practice is something like database 
> > connection pooling, which everyone agrees is a good idea.
ENTER/EXIT 
> > is a highly contentious issue, given that this debate has been
raging 
> > for weeks.
> >
> > I still don't understand why if you want enter/exit methods you
can't 
> > just do it in your own static method somewhere like shown below.
> >
> > MyLoggingUtils.enter(MyClass.class, "myMethodName", new Object[] { 
> > arg1, arg2, arg3 }).
> >
> > Does JDK 1.4 logging do something really fancy with ENTER/EXIT
methods 

> > that makes you argue so strongly for them?  Or is there something in

> > that IBM alphaworks project that depends on the enter/exit methods? 
> > Couldn't it be rewritten to filter TRACE level logging that began
with 

> > the text "Entering" or "Exiting"?
> >
> > Matt
> 
> 
> 
> -- 
> Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if 
anyone took offense.  I was just asking :)

Ceki, thanks for that link.  You have many excellent points, and I may 
migrate my projects away from commons-logging.

Matt
Vic wrote:
Matt Sgarlata wrote:
You've spent a lot of time discussing commons-logging on this list, 
while at the same time supporting development of UGLI. Which component 
is your favorite? How come you're working on 2?

Simmer down now. Lets act intelligent. Many people work on many things 
and share code across projects… it’s a friendly license.

Look at Struts, it has JSF subprojects under it, or lets play how many 
duplicate projects we can name under ASF. It’s all good. Much 
duplication in Apache, all of it good.

Choice = = good. What was that platform where they have the ONE true way?
..V

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Vic]

Matt Sgarlata wrote:
You've spent a lot of time discussing commons-logging on this list, 
while at the same time supporting development of UGLI. Which component 
is your favorite? How come you're working on 2?

Simmer down now. Lets act intelligent. Many people work on many things 
and share code across projects… it’s a friendly license.

Look at Struts, it has JSF subprojects under it, or lets play how many 
duplicate projects we can name under ASF. It’s all good. Much 
duplication in Apache, all of it good.

Choice = = good. What was that platform where they have the ONE true way?
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

On 2005-01-25 20:45:34,  Matt Sgarlata wrote:
>I'm confused Ceki.  You've spent a lot of time discussing
>commons-logging on this list, while at the same time supporting
>development of UGLI.  Which component is your favorite?  How come you're
>working on 2?
As far as I knew, swearing allegiance to commons-logging was not a
prerequisite for participation in this list. Moreover, my position on
JCL was always publicly known [1].
[1] http://www.qos.ch/logging/thinkAgain.jsp
>Matt
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

I'm confused Ceki.  You've spent a lot of time discussing 
commons-logging on this list, while at the same time supporting 
development of UGLI.  Which component is your favorite?  How come you're 
working on 2?

Matt
Ceki Gülcü wrote:
On  2005-01-25 19:40:35, Richard Sitze wrote:
 > How in the WORLD did this happen?
UGLI did not happen overnight. The idea was discussed on this list
among others over 6 months ago.
  http://marc.theaimsgroup.com/?t=10865459724&r=1&w=2
 > This feels like 'not-invented-here' and some backstabbing.  How can we
 > POSSIBLY accomplish our goals if we simply refuse to acknowledge that
 > other projects have value?!  What can we achieve with competing
 > abstractions at this level?
The answer can be summarized in a few words: look Ma, no class loaders!
 > Frankly, I expected better of the Apache Logging Services community.
Agreed. How dare Apache Logging Services write a logging interface?
Moreover, they never complained about JCL before.
Seriously, aren't you sick of JCL exploding with an
LogConfigurationException at the most inappropriate times?
 > Excuse me while I go find a wall and beat my head against it for a
 > while...
No problem. You'll thank us later. :-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

On  2005-01-25 19:40:35, Richard Sitze wrote:
> How in the WORLD did this happen?
UGLI did not happen overnight. The idea was discussed on this list
among others over 6 months ago.
  http://marc.theaimsgroup.com/?t=10865459724&r=1&w=2
> This feels like 'not-invented-here' and some backstabbing.  How can we
> POSSIBLY accomplish our goals if we simply refuse to acknowledge that
> other projects have value?!  What can we achieve with competing
> abstractions at this level?
The answer can be summarized in a few words: look Ma, no class loaders!
> Frankly, I expected better of the Apache Logging Services community.
Agreed. How dare Apache Logging Services write a logging interface?
Moreover, they never complained about JCL before.
Seriously, aren't you sick of JCL exploding with an
LogConfigurationException at the most inappropriate times?
> Excuse me while I go find a wall and beat my head against it for a
> while...
No problem. You'll thank us later. :-)
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Well now... that IS interesting.


How in the WORLD did this happen?  I approached Ceki about aligning JCL 
with Log4J...  and was turned down, he simply wasn't interested and 
wouldn't acknowledge the value of the abstraction [at that time].

This feels like 'not-invented-here' and some backstabbing.  How can we 
POSSIBLY accomplish our goals if we simply refuse to acknowledge that 
other projects have value?!  What can we achieve with competing 
abstractions at this level?

Frankly, I expected better of the Apache Logging Services community.

Excuse me while I go find a wall and beat my head against it for a 
while...





news <[EMAIL PROTECTED]> wrote on 01/25/2005 01:21:24 PM:

> I kind of think that maybe commons-logging should be deprecated in 
> favor of:
> http://logging.apache.org/log4j/docs/ugli.html
> 
> See UGLI does same thing. But competitions is a good thing; my projects 
> will ship w/ Log4j instead and ugli. One less jar is good.
> .V
> 
> 
> Matt Sgarlata wrote:
> 
> > Richard Sitze wrote:
> >
> >> news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
> >>
> >>> +1, I agree with you and Ceki.  TRACE is debatable (I personally 
> >>> like it), more than TRACE is silly.
> >>
> >>
> >>
> >> Well... call them what you will, I want em'!! lol
> >>
> >> And yes, I'm leaning towards EXPLICITLY naming methods to encourage 
> >> best practices.  To use the distinction made by Curt, I'm pushing the 

> >> trace level methods towards diagnostic logger function, and stepping 
> >> away from other uses entirely.  I'm going to refrain from doing a 
> >> full brain dump on all the fun thoughts now running through my 
> >> head... [separating trace level methods and messaging/admin level 
> >> methods into seperate interfaces.. ok I lied].
> >
> >
> > I think we can pretty much lay to rest the argument that including 
> > ENTER/EXIT is a "best practice".  There have been so many arguments on 

> > both sides of the issue that it's pretty clear we're not going to 
> > reach a concensus.  A best practice is something like database 
> > connection pooling, which everyone agrees is a good idea.  ENTER/EXIT 
> > is a highly contentious issue, given that this debate has been raging 
> > for weeks.
> >
> > I still don't understand why if you want enter/exit methods you can't 
> > just do it in your own static method somewhere like shown below.
> >
> > MyLoggingUtils.enter(MyClass.class, "myMethodName", new Object[] { 
> > arg1, arg2, arg3 }).
> >
> > Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods 

> > that makes you argue so strongly for them?  Or is there something in 
> > that IBM alphaworks project that depends on the enter/exit methods? 
> > Couldn't it be rewritten to filter TRACE level logging that began with 

> > the text "Entering" or "Exiting"?
> >
> > Matt
> 
> 
> 
> -- 
> Forums, Boards, Blogs and News in RiA 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Vic]

I kind of think that maybe commons-logging should be deprecated in 
favor of:
http://logging.apache.org/log4j/docs/ugli.html

See UGLI does same thing. But competitions is a good thing; my projects 
will ship w/ Log4j instead and ugli. One less jar is good.
.V

Matt Sgarlata wrote:
Richard Sitze wrote:
news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki.  TRACE is debatable (I personally 
like it), more than TRACE is silly.

Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage 
best practices.  To use the distinction made by Curt, I'm pushing the 
trace level methods towards diagnostic logger function, and stepping 
away from other uses entirely.  I'm going to refrain from doing a 
full brain dump on all the fun thoughts now running through my 
head... [separating trace level methods and messaging/admin level 
methods into seperate interfaces.. ok I lied].

I think we can pretty much lay to rest the argument that including 
ENTER/EXIT is a "best practice".  There have been so many arguments on 
both sides of the issue that it's pretty clear we're not going to 
reach a concensus.  A best practice is something like database 
connection pooling, which everyone agrees is a good idea.  ENTER/EXIT 
is a highly contentious issue, given that this debate has been raging 
for weeks.

I still don't understand why if you want enter/exit methods you can't 
just do it in your own static method somewhere like shown below.

MyLoggingUtils.enter(MyClass.class, "myMethodName", new Object[] { 
arg1, arg2, arg3 }).

Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods 
that makes you argue so strongly for them?  Or is there something in 
that IBM alphaworks project that depends on the enter/exit methods? 
Couldn't it be rewritten to filter TRACE level logging that began with 
the text "Entering" or "Exiting"?

Matt

--
Forums, Boards, Blogs and News in RiA 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Richard Sitze wrote:
news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki.  TRACE is debatable (I personally like 
it), more than TRACE is silly.

Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage best 
practices.  To use the distinction made by Curt, I'm pushing the trace 
level methods towards diagnostic logger function, and stepping away from 
other uses entirely.  I'm going to refrain from doing a full brain dump on 
all the fun thoughts now running through my head... [separating trace 
level methods and messaging/admin level methods into seperate interfaces.. 
ok I lied].
I think we can pretty much lay to rest the argument that including 
ENTER/EXIT is a "best practice".  There have been so many arguments on 
both sides of the issue that it's pretty clear we're not going to reach 
a concensus.  A best practice is something like database connection 
pooling, which everyone agrees is a good idea.  ENTER/EXIT is a highly 
contentious issue, given that this debate has been raging for weeks.

I still don't understand why if you want enter/exit methods you can't 
just do it in your own static method somewhere like shown below.

MyLoggingUtils.enter(MyClass.class, "myMethodName", new Object[] { arg1, 
arg2, arg3 }).

Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods 
that makes you argue so strongly for them?  Or is there something in 
that IBM alphaworks project that depends on the enter/exit methods? 
Couldn't it be rewritten to filter TRACE level logging that began with 
the text "Entering" or "Exiting"?

Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 3 Jan 2005, at 17:03, Ceki Gülcü wrote:
At 05:53 PM 1/3/2005, robert burrell donkin wrote:
nope (but don't ask me to find the references). distributing an api 
jar which requires runtime dependencies was a mistake. this issue 
hasn't arisen for quite a while since we try to keep quiet about the 
existing of the api jar.
I do not understand. How can JCL *not* require runtime dependencies 
given that it is a wrapper around various logging APIs? In other 
words, how can JCL wrap API x without runtime dependencies on API x?
a minimal core should have robust behaviour when deployed without any 
support (rather than die horribly). for example, IIRC log4j prints up a 
message to System.err and then silently swallows all messages when it 
cannot configure itself.

JCL core should do something similar (though i'd advocate logging fatal 
- and possibly error level messages - to System.err for the reasons 
explained well in james strachan's blog 
http://radio.weblogs.com/0112098/2004/10/06.html).

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 05:53 PM 1/3/2005, robert burrell donkin wrote:
nope (but don't ask me to find the references). distributing an api jar 
which requires runtime dependencies was a mistake. this issue hasn't 
arisen for quite a while since we try to keep quiet about the existing of 
the api jar.
I do not understand. How can JCL *not* require runtime dependencies given 
that it is a wrapper around various logging APIs? In other words, how can 
JCL wrap API x without runtime dependencies on API x?


- robert
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 3 Jan 2005, at 16:25, Ceki Gülcü wrote:
At 09:23 PM 1/2/2005, robert burrell donkin wrote:
i'm in definitely agreement with craig's assessment (a long while 
ago) that one of the fundamental flaws with the current JCL is that 
we ship an unusable API distribution with runtime dependencies.
Robert,
Are you by any chance referring to Craig's comments [1] on the
"commons-logging & classloading" thread [2]?
nope (but don't ask me to find the references). distributing an api jar 
which requires runtime dependencies was a mistake. this issue hasn't 
arisen for quite a while since we try to keep quiet about the existing 
of the api jar.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 09:23 PM 1/2/2005, robert burrell donkin wrote:
i'm in definitely agreement with craig's assessment (a long while ago) 
that one of the fundamental flaws with the current JCL is that we ship an 
unusable API distribution with runtime dependencies.
Robert,
Are you by any chance referring to Craig's comments [1] on the
"commons-logging & classloading" thread [2]?
[1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=106608349829350&w=2
[2] http://marc.theaimsgroup.com/?t=10632904081&r=1&w=2

- robert
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 27 Dec 2004, at 23:52, Ceki Gülcü wrote:
On 2004-12-16 18:09:36, Richard Sitze wrote:
> ok, without going back to review exactly what I said in an earlier 
note, I
> had in mind something like:
>
>   commons-logging-core.jar   - core interface & factory class, NO 
config
>   commons-logging.jar- core + all helpers, NO config
>   commons-logging-.jar - core + ONE helper, ONE config
>
> With this scheme, I believe we can scrub the code from LogFactory 
that
> looks for an attempts to load specific logger impls [Log4J, Avalon, 
?],
> and instead depend entirely on the config.

In commons-logging-.jar, I suppose by "ONE helper, ONE config"
you mean the necessary wiring to let commons-logging know that it
should use  and skip automatic discovery. This simple and robust
approach would probably alleviate many of the classloader problems
users have been hitting.
i'm in definitely agreement with craig's assessment (a long while ago) 
that one of the fundamental flaws with the current JCL is that we ship 
an unusable API distribution with runtime dependencies.

as far as i'm concerned the only solution is to create a useable core 
API distribution with minimal portable configuration (system property 
only) and no discovery (except as required for backward compatibility 
in a combined distribution ie no classloader magic). upon configuration 
failure rather than throwing an exception, it should default to logging 
fatal and error messages to system.err.

IIUC the helper performs discovery and only one discovery helper can be 
picked by the fundamental configuration mechanism. this would indeed 
allow solutions to be provided for most of the most common troublesome 
use cases.

(apologies for prolonging the military metaphor.) i suspect that we 
might all be marching in the same direction now.  am i correct?

if so, then i do think it would work and i am confident that it can be 
done without breaking backwards compatibility.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

Richard,
The commons-logging-.jar approach you suggested earlier will throw an 
exception if  is not available which should be perfectly fine because 
if the user explicitly puts commons-logging-.jar in her classpath, 
then it means that she wants  around.

I quite like it.
It lends it's self well to this, but it's not sufficient.  The requirement
is for this behavior to be exhibited by JCL, for example when Log4j is
configuted, but not available on the classpath.
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:31:23 PM:

> 
> At 2004-12-16 16:51:31, Richard Sitze wrote:
> 
>  > I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
>  >
>  > I advocate a *warn* or *error* on either, using the simple default 
logger.
>  > The warning will be visible on the console, which suffices for my
>  > immediate concerns.  How that warning/error (in general) is managed 
is up
>  > to the application environment.
> 
> Log4j 1.3 can use itself for its own logging. So, when appender A
> fails, it can report errors using appender B. Appender B could alert the
> system admin if that is the desired behavior.
> 
> The same goes for configuration errors which are also accessible
> programmatically. For example,
> 
> 
>Configurator c = new SomeLog4jConfigurator();
>c.configure("some file");
>List el = c.getErrorList();
>if(el.size > 0) {
>  if(analyzeErrors(el)) {
>// errors during logging configuration
>throw new IllegalStateException("Can't proceed withour logging");
>  }
>}
> 
>boolean analyzeErrors(List el) {
>  // custom analysis of the errors go here
>  return true/false;
>}
> 
> It seems to me that log4j already fulfills Richard's requirements wrt
> logging errors and logging configuration.

It lends it's self well to this, but it's not sufficient.  The requirement 
is for this behavior to be exhibited by JCL, for example when Log4j is 
configuted, but not available on the classpath.

> 
> 
> -- 
> Ceki Gülcü
> 
>The complete log4j manual: http://www.qos.ch/log4j/

***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

On 2004-12-16 18:09:36, Richard Sitze wrote:
> ok, without going back to review exactly what I said in an earlier note, I
> had in mind something like:
>
>   commons-logging-core.jar   - core interface & factory class, NO config
>   commons-logging.jar- core + all helpers, NO config
>   commons-logging-.jar - core + ONE helper, ONE config
>
> With this scheme, I believe we can scrub the code from LogFactory that
> looks for an attempts to load specific logger impls [Log4J, Avalon, ?],
> and instead depend entirely on the config.
In commons-logging-.jar, I suppose by "ONE helper, ONE config"
you mean the necessary wiring to let commons-logging know that it
should use  and skip automatic discovery. This simple and robust
approach would probably alleviate many of the classloader problems
users have been hitting.
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 2004-12-16 16:51:31, Richard Sitze wrote:
> I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
>
> I advocate a *warn* or *error* on either, using the simple default logger.
> The warning will be visible on the console, which suffices for my
> immediate concerns.  How that warning/error (in general) is managed is up
> to the application environment.
Log4j 1.3 can use itself for its own logging. So, when appender A
fails, it can report errors using appender B. Appender B could alert the
system admin if that is the desired behavior.
The same goes for configuration errors which are also accessible
programmatically. For example,
  Configurator c = new SomeLog4jConfigurator();
  c.configure("some file");
  List el = c.getErrorList();
  if(el.size > 0) {
if(analyzeErrors(el)) {
  // errors during logging configuration
  throw new IllegalStateException("Can't proceed withour logging");
}
  }
  boolean analyzeErrors(List el) {
// custom analysis of the errors go here
return true/false;
  }
It seems to me that log4j already fulfills Richard's requirements wrt
logging errors and logging configuration.
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT][logging] politics [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/22/2004 04:53:49 AM:



> JCL shows indications of mission creep. I believe this to be a factual
> observation independent of ASF representation.

Just to help clarify your concern, would you please define "mission 
creep".


> >(conversely, if you do think that JCL is out of scope for the commons 
or 
> >is at danger of becoming so - and that it's a big enough issue to 
consider 
> >things such as appealing to the members, then please tell me and i'd be 

> >glad to nominate you - and any other logging services pmc members who 
are 
> >interested - as committers for the commons and give you a free hand to 
> >sort out the problem as you best see fit. at least that way, myself and 

> >the rest of the JCL community will have a voice and some sort of vote. 
> >that would seem to me to be much more in the old apache spirit, at 
least 
> >as far as i can remember it...)
> 
> Thank you for this offer. We need to consider it carefully and check
> whether we can participate in a meaningful manner. I am forwarding it
> to the LS PMC.

Interesting indeed, not a bad idea.  IMHO, any LS PMC member granted 
committer status on JCL needs a firm & rational grasp on the distinctly 
different goals between JCL and Log4J.  Ceki, I believe, understands this 
distinction well.  I trust anyone else nominated for this role would 
understand and respect these differences as well.

> >- robert
> 
> -- 
> Ceki Gülcü


***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT][logging] politics [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]

[Ceki Gülcü]

At 11:56 PM 12/21/2004, robert burrell donkin wrote:
FWIW AFAIK the committers who feel victimized are outside jakarta. IMHO 
committers who are vocally critical of the ASF (as an organization) are 
something about which the membership should be concerned. some of them 
simply have an obvious axe to grind but for others, a few humble and kind 
words were all would have been required. certainly, threats by members to 
communities (especially without adequate ASF representation) at a time 
such as this seems to play a little too much into their hands. i hope and 
trust that this wasn't the intent of your previous post.
JCL shows indications of mission creep. I believe this to be a factual
observation independent of ASF representation.
(conversely, if you do think that JCL is out of scope for the commons or 
is at danger of becoming so - and that it's a big enough issue to consider 
things such as appealing to the members, then please tell me and i'd be 
glad to nominate you - and any other logging services pmc members who are 
interested - as committers for the commons and give you a free hand to 
sort out the problem as you best see fit. at least that way, myself and 
the rest of the JCL community will have a voice and some sort of vote. 
that would seem to me to be much more in the old apache spirit, at least 
as far as i can remember it...)
Thank you for this offer. We need to consider it carefully and check
whether we can participate in a meaningful manner. I am forwarding it
to the LS PMC.
- robert
--
Ceki Gülcü

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT][logging] politics [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]

[robert burrell donkin]

On 21 Dec 2004, at 20:24, Ceki Gülcü wrote:
At 07:51 PM 12/21/2004, robert burrell donkin wrote:
now it's getting political :(
Your comments about the "optionality" of consultations elicited my
political response.
i've given up politics.
(feel free to reply to my missive but please spend some time creating 
some worthwhile since i have no intention of posting any more replies 
to this thread. the only reason i've created a reply is that i suspect 
there may have been some misunderstanding of the points i wished to 
make early.)

Many  ASF  members   were  involved  with  Apache  at   one  point  or
another. Moreover,  Jakarta has quite  a few influential, I  dare say,
very influential, members.  Thus, it is not easy to emphasize with the
sense  of  victimization  shared   by  some  Jakarta  committers.
i wasn't trying to suggest that jakarta committers are victims, just 
that it's another symptom of the problems which the ASF has with 
jakarta.

FWIW AFAIK the committers who feel victimized are outside jakarta. IMHO 
committers who are vocally critical of the ASF (as an organization) are 
something about which the membership should be concerned. some of them 
simply have an obvious axe to grind but for others, a few humble and 
kind words were all would have been required. certainly, threats by 
members to communities (especially without adequate ASF representation) 
at a time such as this seems to play a little too much into their 
hands. i hope and trust that this wasn't the intent of your previous 
post.

(conversely, if you do think that JCL is out of scope for the commons 
or is at danger of becoming so - and that it's a big enough issue to 
consider things such as appealing to the members, then please tell me 
and i'd be glad to nominate you - and any other logging services pmc 
members who are interested - as committers for the commons and give you 
a free hand to sort out the problem as you best see fit. at least that 
way, myself and the rest of the JCL community will have a voice and 
some sort of vote. that would seem to me to be much more in the old 
apache spirit, at least as far as i can remember it...)

If proportionally  too few Jakarta  committers are  ASF members,  
which I
honestly  doubt to  be  the  case,
this one came up a while ago (IIRC greg stein raised the demography 
problem as one of the issues with jakarta). proportionally, there 
are/were too many committers, not enough pmc members and too few 
members. jakarta is addressing the first (sub-projects moving to TLP 
status) and the second. the third can be addressed by the members only. 
i can appreciate why the membership has grown in the way though i had 
hoped for a little more understanding that this situation is of the 
member's own making.

what  is  keeping existing  Jakarta
members from increasing their own representation?
we both know that the majority of jakarta members (yourself, for 
example) are actually now primarily involved with top level projects 
outside jakarta. even our chair isn't a member. the membership grows 
organically.

FWIW i'm actually happy that there isn't a jakarta faction amongst the 
membership pushing jakarta committers forward: it's healthy. it's good 
that the membership cares more for the ASF than any particular project. 
what isn't so good is that they've done a bad job over the last few 
months in appearing to care about the committers and communities which 
create the code. i am quite sure that this isn't true but i do think 
there's a danger that this perceived gap may become a destructive gulf 
in the future. so please let's not start that particular war here...

matters of scope are less important than matters of community. if 
strong community backing emerges  then the scope issues can easily be 
solved. if no community emerges then matters of scope will become 
irrelevant.
It all depends  on how you define community. By  community do you mean
Jakarta Commons,  Jakarta or the rest of  the ASF?
community in the usual apache sense of the word. (or possibly: in the 
old apache sense of the word).

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

news <[EMAIL PROTECTED]> wrote on 12/21/2004 02:01:07 PM:



> > And yes, I'm leaning towards EXPLICITLY naming methods to encourage 
best 
> > practices.  To use the distinction made by Curt, I'm pushing the trace 

> > level methods towards diagnostic logger function, and stepping away 
from 
> > other uses entirely.  I'm going to refrain from doing a full brain 
dump on 
> > all the fun thoughts now running through my head... [separating trace 
> > level methods and messaging/admin level methods into seperate 
interfaces.. 
> > ok I lied].
> 
> OK, I'm being serious again.  I think there are two problems with "best 
> practices": (1) they change and (2) they are in the eye of the beholder. 

>Nothing can be deemed "best" without making a value judgement, which 
> means that reasonable people can disagreee as to what is the "best" 
> practice.

Agreed.  Looking for balance, there are some things that are more clear 
than others.

> Bringing this back to the situation at hand, you think enter/exit are 
> best practices, I think they're as useful as the SUPERTINY log level. 
> But let's not take my word for it.  Consider that Log4J doesn't include 
> enter/exit and it is the pioneer logging framework that's still going 
> strong despite an attempt to hijack its charter by including logging in 
> the Java language itself.  This leads me to believe your argument that 
> enter/exit is a best practice is debatable at best :)
> 
> > 3 levels stand out clearly to me:
> > 
> > component level tracing [flow] - particularly useful in a larger 
system

I want to turn on logging that tracks component boundries.  When I enter 
my component [or robert's brick], and when I leave it.  Perhaps log data 
exchanged across the boundry.

> > class level tracing [flow]

Ok, now that I'm IN my component, I want to track the flow between objects 
/ methods.  Again, data exchanged on method invocation / return.  This 
corresponds to the proposed enter/exit.

I'm agreeing with comments by others, in that [generally] I don't want to 
log just any old thing here, but I for loggers that do support multiple 
log levels, would be useful to have this without the next level down..

> > additional detail

Capture details on internal data, track low level flow if desired... 
everything else.

> I still don't understand this distinction, but I am comfortable taking 
> your word for it that this is very important.  It would probably be a 
> great feature for Log4J instead of JCL :)
> 
> >>>richard's proposal to add symantic methods (rather than severities) 
is 
> > 
> > 
> >>>therefore interesting. exit and entry tracing is common. at the 
> > 
> > moment, 
> > 
> >>>this works rather poorly when JCP is used with log4j: most people log 

> >>>these at trace which is mapped to debug by the bridge. unfortunately, 

> >>>this has the effect of making debug level almost unusable. separate, 
> >>>symantically meaningful methods would have the advantage that the 
> > 
> > bridge 
> > 
> >>>will know enough to make better choices.
> >>
> >>-0.  This is moving JCL out of the realm of bridging logging APIs and 
> >>into the realm of providing logging implementations.  For Log4J, 
> >>enter/exit methods will end up being mapped to Log4J's DEBUG level. 
> >>This means that JCL will have to provide the implementation that 
> >>converts the enter/exit calls into DEBUG calls with a specific format.
> > 
> > 
> > This is what the thin wrapper DOES.  Not sure I understand your issue.
> > 
> > 
> >>What format should be used?  Are we going to force one on users of 
Log4J
> > 
> > 
> > We should adopt a helper method to do such formatting, and use it 
[common] 
> > across all components to standardize this as much as possible.  Where 
> > logger impls support such, we pass as much as makes sense straight 
> > through.
> > 
> > Let's not get hung up on formatting issues, the POINT is to capture 
> > information, enable the developers, etc.
> > 
> > 
> >>or make it configurable?  And if it's configurable, that stinks of JCL 

> >>becoming a logging *implementation* rather than *bridge*.  Yuck!  If I 

> >>was a committer (you're probably glad I'm not!) I would probably -1 
the 
> >>enter/exit methods.
> > 
> > 
> > No problem, I'd just keep beating at your arguments until my last 
dying 
> > breath. ;-)
> 
> Hehe that worked on me last time :)  I think it won't this time though!

I'm not done yet :)


***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 07:51 PM 12/21/2004, robert burrell donkin wrote:
now it's getting political :(
Your comments about the "optionality" of consultations elicited my
political response.
Many  ASF  members   were  involved  with  Apache  at   one  point  or
another. Moreover,  Jakarta has quite  a few influential, I  dare say,
very influential, members.  Thus, it is not easy to emphasize with the
sense  of  victimization  shared   by  some  Jakarta  committers.   If
proportionally  too few Jakarta  committers are  ASF members,  which I
honestly  doubt to  be  the  case, what  is  keeping existing  Jakarta
members from increasing their own representation?
matters of scope are less important than matters of community. if strong 
community backing emerges  then the scope issues can easily be solved. if 
no community emerges then matters of scope will become irrelevant.
It all depends  on how you define community. By  community do you mean
Jakarta Commons,  Jakarta or the rest of  the ASF?
- robert
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Richard Sitze wrote:
news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki.  TRACE is debatable (I personally like 
it), more than TRACE is silly.

Well... call them what you will, I want em'!! lol
Does this mean you want all 42 logging levels I described in my previous 
post, including the TINY, SUPERTINY, VERYTINY, EXTREMLYTINY, TINIEST, 
and SPLITTINGHAIRS logging levels I mentioned in a previous post?

Just kidding!  That was a joke, please don't flame me because of it :)
And yes, I'm leaning towards EXPLICITLY naming methods to encourage best 
practices.  To use the distinction made by Curt, I'm pushing the trace 
level methods towards diagnostic logger function, and stepping away from 
other uses entirely.  I'm going to refrain from doing a full brain dump on 
all the fun thoughts now running through my head... [separating trace 
level methods and messaging/admin level methods into seperate interfaces.. 
ok I lied].
OK, I'm being serious again.  I think there are two problems with "best 
practices": (1) they change and (2) they are in the eye of the beholder. 
  Nothing can be deemed "best" without making a value judgement, which 
means that reasonable people can disagreee as to what is the "best" 
practice.

Bringing this back to the situation at hand, you think enter/exit are 
best practices, I think they're as useful as the SUPERTINY log level. 
But let's not take my word for it.  Consider that Log4J doesn't include 
enter/exit and it is the pioneer logging framework that's still going 
strong despite an attempt to hijack its charter by including logging in 
the Java language itself.  This leads me to believe your argument that 
enter/exit is a best practice is debatable at best :)

3 levels stand out clearly to me:
component level tracing [flow] - particularly useful in a larger system
class level tracing [flow]
additional detail
I still don't understand this distinction, but I am comfortable taking 
your word for it that this is very important.  It would probably be a 
great feature for Log4J instead of JCL :)

richard's proposal to add symantic methods (rather than severities) is 

therefore interesting. exit and entry tracing is common. at the 
moment, 

this works rather poorly when JCP is used with log4j: most people log 
these at trace which is mapped to debug by the bridge. unfortunately, 
this has the effect of making debug level almost unusable. separate, 
symantically meaningful methods would have the advantage that the 
bridge 

will know enough to make better choices.
-0.  This is moving JCL out of the realm of bridging logging APIs and 
into the realm of providing logging implementations.  For Log4J, 
enter/exit methods will end up being mapped to Log4J's DEBUG level. 
This means that JCL will have to provide the implementation that 
converts the enter/exit calls into DEBUG calls with a specific format.

This is what the thin wrapper DOES.  Not sure I understand your issue.

What format should be used?  Are we going to force one on users of Log4J

We should adopt a helper method to do such formatting, and use it [common] 
across all components to standardize this as much as possible.  Where 
logger impls support such, we pass as much as makes sense straight 
through.

Let's not get hung up on formatting issues, the POINT is to capture 
information, enable the developers, etc.
 

or make it configurable?  And if it's configurable, that stinks of JCL 
becoming a logging *implementation* rather than *bridge*.  Yuck!  If I 
was a committer (you're probably glad I'm not!) I would probably -1 the 
enter/exit methods.

No problem, I'd just keep beating at your arguments until my last dying 
breath. ;-)
Hehe that worked on me last time :)  I think it won't this time though!
(so, i'm a little unsure about this issue at the moment.)
- robert
Matt

***
Richard A. Sitze
IBM WebSphere WebServices Development

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Comments below...
robert burrell donkin wrote:
On 21 Dec 2004, at 14:04, Matt Sgarlata wrote:
robert burrell donkin wrote:


richard's proposal to add symantic methods (rather than severities) 
is therefore interesting. exit and entry tracing is common. at the 
moment, this works rather poorly when JCP is used with log4j: most 
people log these at trace which is mapped to debug by the bridge. 
unfortunately, this has the effect of making debug level almost 
unusable. separate, symantically meaningful methods would have the 
advantage that the bridge will know enough to make better choices.

-0.  This is moving JCL out of the realm of bridging logging APIs and 
into the realm of providing logging implementations.  For Log4J, 
enter/exit methods will end up being mapped to Log4J's DEBUG level. 
This means that JCL will have to provide the implementation that 
converts the enter/exit calls into DEBUG calls with a specific format. 
What format should be used?  Are we going to force one on users of 
Log4J or make it configurable?  And if it's configurable, that stinks 
of JCL becoming a logging *implementation* rather than *bridge*.  
Yuck!  If I was a committer (you're probably glad I'm not!) I would 
probably -1 the enter/exit methods.

this one is an interesting dilemma.
it's pretty obvious to me that some standard implementations beyond a 
simple bridge are going to be required for the proposal.
It's not obvious to me though... what implementations would JCL need to 
provide?  Even if we introduce our own MessageSource interface similar 
to Spring's (which I've seen some other people in recent posts seem to 
be in favor of), that is only defining an interface, not an 
implementation.  If we choose to fall back to java.util.ResourceBundle 
functionality when there is no MessageSource implementation to be found, 
we are once again simply bridging functionality that is already written. 
 That is, the default MessageSource is implemented by 
java.util.ResourceBundle and we've kept JCL free of implementations.

If you're talking about the discovery stuff, well, that's over my head. 
 But assuming for a moment that this did require JCL to do some 
"implementation"-type things for discovery, that doesn't mean that JCL 
should be given a free ticket to move away from being a bridge for all 
of the JCL, including functionality like enter/exit methods that are 
completely orthogonal to the discovery process!

for the moment, i'm more interested in the technical issues rather than 
the issue of scope. many (most?) of the extensions to commons logging 
under consideration extend the scope of JCL. where this (hypothetical) 
code ends up packaged is another matter: if JCL becomes a compact API 
plus extensions (some optional, some standard; some libraries, some 
byte-code manipulators) then that's the stage when the commons (probably 
collectively) will need to think about organization and scope.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 21 Dec 2004, at 14:04, Matt Sgarlata wrote:
robert burrell donkin wrote:

richard's proposal to add symantic methods (rather than severities) 
is therefore interesting. exit and entry tracing is common. at the 
moment, this works rather poorly when JCP is used with log4j: most 
people log these at trace which is mapped to debug by the bridge. 
unfortunately, this has the effect of making debug level almost 
unusable. separate, symantically meaningful methods would have the 
advantage that the bridge will know enough to make better choices.
-0.  This is moving JCL out of the realm of bridging logging APIs and 
into the realm of providing logging implementations.  For Log4J, 
enter/exit methods will end up being mapped to Log4J's DEBUG level. 
This means that JCL will have to provide the implementation that 
converts the enter/exit calls into DEBUG calls with a specific format. 
What format should be used?  Are we going to force one on users of 
Log4J or make it configurable?  And if it's configurable, that stinks 
of JCL becoming a logging *implementation* rather than *bridge*.  
Yuck!  If I was a committer (you're probably glad I'm not!) I would 
probably -1 the enter/exit methods.
this one is an interesting dilemma.
it's pretty obvious to me that some standard implementations beyond a 
simple bridge are going to be required for the proposal.

for the moment, i'm more interested in the technical issues rather than 
the issue of scope. many (most?) of the extensions to commons logging 
under consideration extend the scope of JCL. where this (hypothetical) 
code ends up packaged is another matter: if JCL becomes a compact API 
plus extensions (some optional, some standard; some libraries, some 
byte-code manipulators) then that's the stage when the commons 
(probably collectively) will need to think about organization and 
scope.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] roadmap? [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]

[robert burrell donkin]

(shifting towards a more appropriate subject)
On 21 Dec 2004, at 14:19, Henning P. Schmiedehausen wrote:
robert burrell donkin <[EMAIL PROTECTED]> writes:
On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote:

robert burrell donkin <[EMAIL PROTECTED]> writes:
the question i pose is: are we trying for a JCL 2.0 which in my mind
would be a compatible evolution of JCL 1.0 aiming to solve all the
major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover
and factoring) plus additional pluggable modules...?
Personally, I'd like to aim for 1.1. These goals are already a good
step on the way to 2.0 and also address most of the PITAs (PsITA?)
that we currently have.

IMHO addressing all of richard's goals properly at once on a single
track would mean aiming for a 2.0 release. i wouldn't be happy 
shipping
a 1.1 based on the 1.0 code with the extras tacked on since many of 
the
existing issues will simply be magnified. JCL has numerous users and
critics so it's important that what we release is right.

by aiming for a 1.1 release i mean evolution and modularity as opposed
to a big bang. as soon as the repository has been converted, we would
start a release process for 1.0.5 (the work done to plug memory leaks
with Brian Stansberry is important) and then implement the discovery
revisions. JCL 1.1 should feature just the improved, modular discovery
and it should be possible quickly to start a release process for that
release. we may wish to consider adopting a release process more
similar to struts and tomcat.

more modular discovery would allow the various parts of the proposal 
to
be progressed either separately or as a unit (as appears best) without
effecting the core. i suspect that the method tracing is more
controversial in design terms but easy to implement whereas there are 
a
lot of details about the i18n support which may need some work and
thought.

opinions?
Sounds good, I like it. Especially with a "brick" like JCL, which is 
used
under the hood in many places, it is important that we get this right.
i can pull some stuff together on the wiki if people are in agreement 
with this general approach.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 21 Dec 2004, at 15:05, Ceki Gülcü wrote:
At 10:31 PM 12/20/2004, robert burrell donkin wrote:
IIRC we're never really gone for official consultations here at 
apache (or at least the bits i've been involved with): too much 
committee, too little community. i alerted ceki (who i've know and 
respected for too many years even though we don't always agree) soon 
after i discovered this thread and hoped that other interested folks 
from the logging project.

jakarta commons has a slightly different focus and expertise. we're 
more interested in bricks (small, compact reusable components with 
minimal dependencies) than logging systems. the extensions proposed 
by richard would allow components with enhanced logging requirements 
(such as i18nable messages) to be added to the commons.

so, in many ways it doesn't matter whether existing logging systems 
offer these capabilities or not: what matters is whether there is a 
need for this kind of enhanced logging for the kind of bricks built 
by the jakarta commons. it's good people that logging experts have 
shown up to the party but (so long as a need for this exists), the 
party would have happened anyway.
Official consultations at Apache might be a drag, but the last time I
checked, Jakarta Commons was part of the Apache Software Foundation. It
might not be a concern to this group, but keep in mind that the ASF
frowns upon mission-creep.
now it's getting political :(
in many ways, i'd prefer to take your original advice and keep things 
technical: scope can be considered later. not a single line of code has 
been committed and no binding decisions have been taken. i agree with 
noel that we should address the technical issues first.

(i'm now probably going to start preaching to the gallery since you're 
probably already well aware of my views. those who are uninterested in 
politics should stop reading now.)

i'm very aware (maybe more than most) that the ASF has been frowning 
very strongly at jakarta (in general) and commons (in particular) for 
several years. we are very vunerable (both jakarta and commons) because 
we have (proportionally) very few members and so very few advocates at 
the ASF level but this awareness has also produced some strengths: we 
are very aware of issues of scope and aware that we are under scrutiny 
from the board and members. we have no voice and so the only way we can 
demonstrate that the commons is worthwhile is by our actions. we take 
scope seriously (many would argue: too seriously). we take our legal 
duties very seriously. so far, we've managed this whilst retaining a 
sense of community. i feel this is an achievement.

though at some times it feels like we committers are becoming second 
class citizens in the ASF community, the board (whatever some people 
say) has proved time and again that it still believes in communities 
and committers. here in the commons, we have a healthy community and 
that matters. so, all things being equal, having the disapproval of the 
logging project really isn't something that worries me at all providing 
that the decisions taken are right ones for the community.

community is the primary measure against which scope should be judged. 
JCL deals with the particular logging needs of bricks. it is therefore 
in scope for both the jakarta commons (which deals with bricks) and the 
logging project (which deals with logging). the community is here which 
is why JCL elected to stay. IIRC there were no questions raise by 
members or the board about the decision of the community on this 
matter.

No doubt that your party would have happened without the participation
of LS. Unfortunately, LS often gets stuck cleaning up after your party
ends.
matters of scope are less important than matters of community. if 
strong community backing emerges  then the scope issues can easily be 
solved. if no community emerges then matters of scope will become 
irrelevant.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Regarding coding, I do have someone here who is champing at the bit to 
start submitting code to me, for checkin.  Not to say others cannot, just 
that before you put any of your own time into this, know that there are 
other resources being made available.

I do think we can start teasing some elements of this apart, and dropping 
prototype code in the near future.  If nothing else, it would be good to 
have something to poke at.  When we do get to that point, would suggest a 
seperate directory in the CVS repository.

Finally, regarding version numbers.  I'm willing to not make that call 
yet, see where we end up, and call it what it is in the end.



***
Richard A. Sitze
IBM WebSphere WebServices Development

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
12/20/2004 04:13:56 PM:

> On 18 Dec 2004, at 20:52, Curt Arnold wrote:
> > On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
> 
> 
> 
> >> We ARE assuming that maintaining SOME SIGNIFICANT compatibility with 
> >> the
> >> existing JCL is of paramount importance.  We are NOT trying to 
> >> standardize
> >> on some "other" API within the industry, but rather to evolve an 
> >> existing
> >> standard with new function.  The API's are based *functionally* on 
> >> JSR-47
> >> and other logging implementations.  It's fair to say that there is 
> >> more
> >> than a little experience being brought to bear on this effort within 
> >> the
> >> Jakarta community.
> >>
> >
> > Again, I'm coming into this late.   Is there a requirements doc of 
> > some sort other than what was in this thread, have there been any 
> > votes, anything in CVS, any timeline?
> 
> there was a vote but i think it was a little premature. certainly, 
> there's been no pressure to conclude it and it seems to me that the 
> present consensus is that more talk and thought is needed.
> 
> commons appears to be in the process of migrating to subversion. i feel 
> an urge to code but it'd be better to take a branch or three to further 
> the discussion in code. so for the moment, i don't think we'll see any 
> commits for a while yet. certainly, i wouldn't feel comfortable with 
> any as yet.
> 
> personally speaking, i think that refactoring the discovery process is 
> a pre-requisite to firming up the design. i have seen too much 
> discussion on that yet so maybe we're still a little way off...
> 
> - robert
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:

> robert burrell donkin wrote:
> > On 18 Dec 2004, at 23:07, Scott Deboy wrote:
> > 
> >> Enter and exit should not be defined as severities.  This is useful 
> >> information, but orthogonal to a logging event's severity attribute.
> 
> Good point.  I think this would be an excellent distinction for a 
> logging implementation (e.g. Log4J to make).  Until such a distinction 
> is already implemented in an existing logging framework, I don't think 
> JCL has any business doing work (i.e. - implementations! bad!) in this 
area.

This distinction IS made in some frameworks.  It's made in the JSR-47 f/w 
implicitly by it's description of the "finer" level.  There are others I'm 
familiar with that support these types of methods explicitly, though in 
different forms that what the proposal contains.

> >> One way to provide entry/exit information is to overload the logger 
> >> methods to take a map, and require the user to adhere to use-case 
> >> specific conventions for keys and values.
> >>
> >> For example, to track entry and exit as we cross component 
boundaries, 
> >> these entries might be sufficient to identify an event:
> >>
> >> Key Name Value
> >> -
> >> boundary.type component
> >> boundary.stateentry
> >>
> >> Similarly, to track entry and exit as we cross class boundaries:
> >>
> >> Key Name Value
> >> -
> >> boundary.type class
> >> boundary.stateexit
> >>
> >> This provides a general mechanism for extending what information an 
> >> event provides - without codifying use-case specific attributes as 
> >> methods in commons-logging.
> >>
> >> Again, the user would be responsible for conforming to naming 
> >> conventions for the map entries (possibly with the aid of helper 
> >> methods to build the map) in order to discover these use-case 
specific 
> >> events.
> 
> Again, something a logging implementation may decide is appropriate, but 

> something I don't think sould be in JCL.

Absolutely agree.  It is interesting, but WAY to fat.

> > interesting :)
> > 
> > this is a classic component design dilemma: more specific, strongly 
> > contracted methods or fewer, more generic ones. i'm not really 
convinced 
> > either way as yet. JCL has benefitted from a compact, strongly 
> > contracted API and it would be good to keep it that way.
> > 
> > IIRC ceki (in the past) convinced me (and probably a lot of others 
too) 
> > that there really isn't very much use in a plethura of logging levels. 

> > applications shouldn't really need anything much lower than debug. 
even 
> > for components, trace is more than a little debatable (though we went 
> > for it). a load of severities may look good in a policy document but 
are 
> > much less useful in practice and their usage patterns do not really 
> > generalize well. so, i don't really see the need for any more 
severities 
> > in JCL.
> 
> +1, I agree with you and Ceki.  TRACE is debatable (I personally like 
> it), more than TRACE is silly.

Well... call them what you will, I want em'!! lol

And yes, I'm leaning towards EXPLICITLY naming methods to encourage best 
practices.  To use the distinction made by Curt, I'm pushing the trace 
level methods towards diagnostic logger function, and stepping away from 
other uses entirely.  I'm going to refrain from doing a full brain dump on 
all the fun thoughts now running through my head... [separating trace 
level methods and messaging/admin level methods into seperate interfaces.. 
ok I lied].

3 levels stand out clearly to me:

component level tracing [flow] - particularly useful in a larger system

class level tracing [flow]

additional detail


> > richard's proposal to add symantic methods (rather than severities) is 

> > therefore interesting. exit and entry tracing is common. at the 
moment, 
> > this works rather poorly when JCP is used with log4j: most people log 
> > these at trace which is mapped to debug by the bridge. unfortunately, 
> > this has the effect of making debug level almost unusable. separate, 
> > symantically meaningful methods would have the advantage that the 
bridge 
> > will know enough to make better choices.
> 
> -0.  This is moving JCL out of the realm of bridging logging APIs and 
> into the realm of providing logging implementations.  For Log4J, 
> enter/exit methods will end up being mapped to Log4J's DEBUG level. 
> This means that JCL will have to provide the implementation that 
> converts the enter/exit calls into DEBUG calls with a specific format.

This is what the thin wrapper DOES.  Not sure I understand your issue.

> What format should be used?  Are we going to force one on users of Log4J

We should adopt a helper method to do such formatting, and use it [common] 
across all components to standardize this as much as possible.  Where 
logger impls support such, we pass as much as makes sense straight 
through.

Let's n

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

[mutters something about keeping OUR troups in line..]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
12/20/2004 04:03:28 PM:

> On 18 Dec 2004, at 20:52, Curt Arnold wrote:
> > On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
> 
> 
> 
> >>> That a single log request can be rendered for more than one locale
> >>> would either require having a localizable object passing through the
> >>> logging dispatch system, being able to translate the log request at 
> >>> the
> >>> appender or some other approach internal to the logging system.
> >>> Constructing a message using resource bundles and passing a rendered
> >>> message on to log4j logging would not accomplish that goal.
> >>
> >> We do not desire to pass on the rendered message, unless the 
> >> underlying
> >> logger offers us no alternative.  We desire to pass the messageID and
> >> parameters directly to the Logger, to be handled as it would.
> >>
> >> Again, I'm not sure what changes/problems you are arguing for?
> >>
> >
> > That is effectively issuing an architectural ultimatum to the logging 
> > implementations: be able to pass resource bundles and parameters 
> > through your processing pipeline or appear to be a second class 
> > implementation of Jakarta Commons Logging.
> 
> (ceki - can't you keep your troops in line! ;)
> 
> LOL! how the story has been rewritten in the last two years...
> 
> we here in the commons are humble implementors of a simple (but yet too 
> complex) thin (but too fat) bridging API. we are second class (we don't 
> really provide any logging worth a damn): the logging system architects 
> are the first class citizens.
> 
> 
> FWIW i have an idea that logging systems capable of supporting native 
> thin wrapper implementations will actually be mostly used through the 
> Log compatibility layer.
> 
> > If this is making architectural demands, it would be right to have the 

> > implementors feedback.
> 
> though we are hoping not to make architectural demands, i think 
> everyone here is glad to have your feedback.

Absolutely.


> your points about the distinction between administrative and diagnostic 
> logging interest me. it seems to me that diagnostic logging is less 
> about the language that the log is written in and more about being able 
> to correlate the message with the code that created the message. this 
> suggests that knowledge of the key is much more critical than the 
> message itself for diagnostic output. given a good key creation 
> convention ("org.apache.commons.bizarro[100]", say). it might therefore 
> be useful to be able to be able to render the key as part of the 
> message (or even as the message).

Can EASILY be managed by making the key part of your message text, in your 
resource.  Documented as a best practice..  and yes, I can see all sorts 
of holes in this.

TWO thoughts:

1. Configuration.  We are NOT a logger, we don't want to be a logger, 
minimize configuration, etc.
2. Again, you are PRESUMING pre-translation of text before we hand off to 
the logger.
3. How the message is rended MUST be managed by the underlying logger 
implementation.

4. I'm coming around to the idea that for loggers that do NOT support 
translation, we could allow one to be plugged in.  The scope must be 
across ALL components.  The components must not presume, or be written to 
presume, any function/feature of these pluggable translators.  Therefore I 
would maintain that the we should still focus on a resource bundle 
approach [properties file or class], so that we maintain portability 
across loggers/translators.

A "simple" translator would be provided, but just as we do NOT want to get 
into the logging game, I maintain that we don't want to become the defacto 
clearing house for translation mechanisms.  Those belong somewhere else.

> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Scott Deboy]

Semantic methods (other than severity) belong somewhere other than Log.

Entry and exit (and other to-be-determined semantic methods) can be supported 
right now without changing commons-logging at all, by passing in a POJO or Map 
in as the event's message and relying on the enterprise logging framework to 
provide extension points in the event processing and mechanism for adding 
user-defined attributes to the logging event.

Log4j can provide this support now.  See MapFilter and ReflectionFilter:

http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/varia/

I'm sure this is the exact opposite of what others had in mind - they'd like a 
stronger contract - but at least this gives folks something to look at and 
think about.

Scott

-Original Message-
From:   robert burrell donkin [mailto:[EMAIL PROTECTED]
Sent:   Tue 12/21/2004 5:39 AM
To: Jakarta Commons Developers List
Cc: 
Subject:    Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 23:07, Scott Deboy wrote:

> Enter and exit should not be defined as severities.  This is useful 
> information, but orthogonal to a logging event's severity attribute.
>
> One way to provide entry/exit information is to overload the logger 
> methods to take a map, and require the user to adhere to use-case 
> specific conventions for keys and values.
>
> For example, to track entry and exit as we cross component boundaries, 
> these entries might be sufficient to identify an event:
>
> Key Name Value
> -
> boundary.type component
> boundary.stateentry
>
> Similarly, to track entry and exit as we cross class boundaries:
>
> Key Name Value
> -
> boundary.type class
> boundary.stateexit
>
> This provides a general mechanism for extending what information an 
> event provides - without codifying use-case specific attributes as 
> methods in commons-logging.
>
> Again, the user would be responsible for conforming to naming 
> conventions for the map entries (possibly with the aid of helper 
> methods to build the map) in order to discover these use-case specific 
> events.

interesting :)

this is a classic component design dilemma: more specific, strongly 
contracted methods or fewer, more generic ones. i'm not really 
convinced either way as yet. JCL has benefitted from a compact, 
strongly contracted API and it would be good to keep it that way.

IIRC ceki (in the past) convinced me (and probably a lot of others too) 
that there really isn't very much use in a plethura of logging levels. 
applications shouldn't really need anything much lower than debug. even 
for components, trace is more than a little debatable (though we went 
for it). a load of severities may look good in a policy document but 
are much less useful in practice and their usage patterns do not really 
generalize well. so, i don't really see the need for any more 
severities in JCL.

richard's proposal to add symantic methods (rather than severities) is 
therefore interesting. exit and entry tracing is common. at the moment, 
this works rather poorly when JCP is used with log4j: most people log 
these at trace which is mapped to debug by the bridge. unfortunately, 
this has the effect of making debug level almost unusable. separate, 
symantically meaningful methods would have the advantage that the 
bridge will know enough to make better choices.

(so, i'm a little unsure about this issue at the moment.)

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 10:31 PM 12/20/2004, robert burrell donkin wrote:
IIRC we're never really gone for official consultations here at apache (or 
at least the bits i've been involved with): too much committee, too little 
community. i alerted ceki (who i've know and respected for too many years 
even though we don't always agree) soon after i discovered this thread and 
hoped that other interested folks from the logging project.

jakarta commons has a slightly different focus and expertise. we're more 
interested in bricks (small, compact reusable components with minimal 
dependencies) than logging systems. the extensions proposed by richard 
would allow components with enhanced logging requirements (such as 
i18nable messages) to be added to the commons.

so, in many ways it doesn't matter whether existing logging systems offer 
these capabilities or not: what matters is whether there is a need for 
this kind of enhanced logging for the kind of bricks built by the jakarta 
commons. it's good people that logging experts have shown up to the party 
but (so long as a need for this exists), the party would have happened anyway.
Official consultations at Apache might be a drag, but the last time I
checked, Jakarta Commons was part of the Apache Software Foundation. It
might not be a concern to this group, but keep in mind that the ASF
frowns upon mission-creep.
No doubt that your party would have happened without the participation
of LS. Unfortunately, LS often gets stuck cleaning up after your party
ends.
- robert
--
Ceki Gülcü, Chairman of Apache Logging Services 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

robert burrell donkin <[EMAIL PROTECTED]> writes:

>On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote:

>> robert burrell donkin <[EMAIL PROTECTED]> writes:
>>
>>> the question i pose is: are we trying for a JCL 2.0 which in my mind
>>> would be a compatible evolution of JCL 1.0 aiming to solve all the
>>> major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover
>>> and factoring) plus additional pluggable modules...?
>>
>> Personally, I'd like to aim for 1.1. These goals are already a good
>> step on the way to 2.0 and also address most of the PITAs (PsITA?)
>> that we currently have.

>IMHO addressing all of richard's goals properly at once on a single 
>track would mean aiming for a 2.0 release. i wouldn't be happy shipping 
>a 1.1 based on the 1.0 code with the extras tacked on since many of the 
>existing issues will simply be magnified. JCL has numerous users and 
>critics so it's important that what we release is right.

>by aiming for a 1.1 release i mean evolution and modularity as opposed 
>to a big bang. as soon as the repository has been converted, we would 
>start a release process for 1.0.5 (the work done to plug memory leaks 
>with Brian Stansberry is important) and then implement the discovery 
>revisions. JCL 1.1 should feature just the improved, modular discovery 
>and it should be possible quickly to start a release process for that 
>release. we may wish to consider adopting a release process more 
>similar to struts and tomcat.

>more modular discovery would allow the various parts of the proposal to 
>be progressed either separately or as a unit (as appears best) without 
>effecting the core. i suspect that the method tracing is more 
>controversial in design terms but easy to implement whereas there are a 
>lot of details about the i18n support which may need some work and 
>thought.

>opinions?

Sounds good, I like it. Especially with a "brick" like JCL, which is used
under the hood in many places, it is important that we get this right.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

robert burrell donkin wrote:
On 18 Dec 2004, at 23:07, Scott Deboy wrote:
Enter and exit should not be defined as severities.  This is useful 
information, but orthogonal to a logging event's severity attribute.
Good point.  I think this would be an excellent distinction for a 
logging implementation (e.g. Log4J to make).  Until such a distinction 
is already implemented in an existing logging framework, I don't think 
JCL has any business doing work (i.e. - implementations! bad!) in this area.

One way to provide entry/exit information is to overload the logger 
methods to take a map, and require the user to adhere to use-case 
specific conventions for keys and values.

For example, to track entry and exit as we cross component boundaries, 
these entries might be sufficient to identify an event:

Key Name Value
-
boundary.type component
boundary.stateentry
Similarly, to track entry and exit as we cross class boundaries:
Key Name Value
-
boundary.type class
boundary.stateexit
This provides a general mechanism for extending what information an 
event provides - without codifying use-case specific attributes as 
methods in commons-logging.

Again, the user would be responsible for conforming to naming 
conventions for the map entries (possibly with the aid of helper 
methods to build the map) in order to discover these use-case specific 
events.
Again, something a logging implementation may decide is appropriate, but 
something I don't think sould be in JCL.

interesting :)
this is a classic component design dilemma: more specific, strongly 
contracted methods or fewer, more generic ones. i'm not really convinced 
either way as yet. JCL has benefitted from a compact, strongly 
contracted API and it would be good to keep it that way.

IIRC ceki (in the past) convinced me (and probably a lot of others too) 
that there really isn't very much use in a plethura of logging levels. 
applications shouldn't really need anything much lower than debug. even 
for components, trace is more than a little debatable (though we went 
for it). a load of severities may look good in a policy document but are 
much less useful in practice and their usage patterns do not really 
generalize well. so, i don't really see the need for any more severities 
in JCL.
+1, I agree with you and Ceki.  TRACE is debatable (I personally like 
it), more than TRACE is silly.

richard's proposal to add symantic methods (rather than severities) is 
therefore interesting. exit and entry tracing is common. at the moment, 
this works rather poorly when JCP is used with log4j: most people log 
these at trace which is mapped to debug by the bridge. unfortunately, 
this has the effect of making debug level almost unusable. separate, 
symantically meaningful methods would have the advantage that the bridge 
will know enough to make better choices.
-0.  This is moving JCL out of the realm of bridging logging APIs and 
into the realm of providing logging implementations.  For Log4J, 
enter/exit methods will end up being mapped to Log4J's DEBUG level. 
This means that JCL will have to provide the implementation that 
converts the enter/exit calls into DEBUG calls with a specific format. 
What format should be used?  Are we going to force one on users of Log4J 
or make it configurable?  And if it's configurable, that stinks of JCL 
becoming a logging *implementation* rather than *bridge*.  Yuck!  If I 
was a committer (you're probably glad I'm not!) I would probably -1 the 
enter/exit methods.

(so, i'm a little unsure about this issue at the moment.)
- robert
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 18 Dec 2004, at 23:07, Scott Deboy wrote:
Enter and exit should not be defined as severities.  This is useful 
information, but orthogonal to a logging event's severity attribute.

One way to provide entry/exit information is to overload the logger 
methods to take a map, and require the user to adhere to use-case 
specific conventions for keys and values.

For example, to track entry and exit as we cross component boundaries, 
these entries might be sufficient to identify an event:

Key Name Value
-
boundary.type component
boundary.stateentry
Similarly, to track entry and exit as we cross class boundaries:
Key Name Value
-
boundary.type class
boundary.stateexit
This provides a general mechanism for extending what information an 
event provides - without codifying use-case specific attributes as 
methods in commons-logging.

Again, the user would be responsible for conforming to naming 
conventions for the map entries (possibly with the aid of helper 
methods to build the map) in order to discover these use-case specific 
events.
interesting :)
this is a classic component design dilemma: more specific, strongly 
contracted methods or fewer, more generic ones. i'm not really 
convinced either way as yet. JCL has benefitted from a compact, 
strongly contracted API and it would be good to keep it that way.

IIRC ceki (in the past) convinced me (and probably a lot of others too) 
that there really isn't very much use in a plethura of logging levels. 
applications shouldn't really need anything much lower than debug. even 
for components, trace is more than a little debatable (though we went 
for it). a load of severities may look good in a policy document but 
are much less useful in practice and their usage patterns do not really 
generalize well. so, i don't really see the need for any more 
severities in JCL.

richard's proposal to add symantic methods (rather than severities) is 
therefore interesting. exit and entry tracing is common. at the moment, 
this works rather poorly when JCP is used with log4j: most people log 
these at trace which is mapped to debug by the bridge. unfortunately, 
this has the effect of making debug level almost unusable. separate, 
symantically meaningful methods would have the advantage that the 
bridge will know enough to make better choices.

(so, i'm a little unsure about this issue at the moment.)
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote:
robert burrell donkin <[EMAIL PROTECTED]> writes:
the question i pose is: are we trying for a JCL 2.0 which in my mind
would be a compatible evolution of JCL 1.0 aiming to solve all the
major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover
and factoring) plus additional pluggable modules...?
Personally, I'd like to aim for 1.1. These goals are already a good
step on the way to 2.0 and also address most of the PITAs (PsITA?)
that we currently have.
IMHO addressing all of richard's goals properly at once on a single 
track would mean aiming for a 2.0 release. i wouldn't be happy shipping 
a 1.1 based on the 1.0 code with the extras tacked on since many of the 
existing issues will simply be magnified. JCL has numerous users and 
critics so it's important that what we release is right.

by aiming for a 1.1 release i mean evolution and modularity as opposed 
to a big bang. as soon as the repository has been converted, we would 
start a release process for 1.0.5 (the work done to plug memory leaks 
with Brian Stansberry is important) and then implement the discovery 
revisions. JCL 1.1 should feature just the improved, modular discovery 
and it should be possible quickly to start a release process for that 
release. we may wish to consider adopting a release process more 
similar to struts and tomcat.

more modular discovery would allow the various parts of the proposal to 
be progressed either separately or as a unit (as appears best) without 
effecting the core. i suspect that the method tracing is more 
controversial in design terms but easy to implement whereas there are a 
lot of details about the i18n support which may need some work and 
thought.

opinions?
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 12:01 AM 12/21/2004, robert burrell donkin wrote:
exactly (and that was the intended joke)
I know. My response was intended  for the rest of the group.
ISTM it hasn't really started out so political this time (or did i miss it...)
My comment about political vs. technical considerations was quite off
topic. Please ignore it.
- robert
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 20 Dec 2004, at 23:13, Tim O'Brien wrote:
Robert, we've got some issues to work through and infrastructure wants 
to wait until at least next week.  Don't delay anything on account of 
the svn migration.  From what I see, the transition should be seemless 
- just a few hours downtime.  So, commit away.
might have to set up branchs and stuff. there's no real rush so 
probably wiser to wait till after the migration.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

robert burrell donkin <[EMAIL PROTECTED]> writes:

>the question i pose is: are we trying for a JCL 2.0 which in my mind 
>would be a compatible evolution of JCL 1.0 aiming to solve all the 
>major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover 
>and factoring) plus additional pluggable modules...?

Personally, I'd like to aim for 1.1. These goals are already a good
step on the way to 2.0 and also address most of the PITAs (PsITA?)
that we currently have.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Tim O'Brien]

Robert, we've got some issues to work through and infrastructure wants to wait 
until at least next week.  Don't delay anything on account of the svn 
migration.  From what I see, the transition should be seemless - just a few 
hours downtime.  So, commit away.
Tim

From: robert burrell donkin
commons appears to be in the process of migrating to subversion. i feel 
an urge to code but it'd be better to take a branch or three to further 
the discussion in code. so for the moment, i don't think we'll see any 
commits for a while yet. certainly, i wouldn't feel comfortable with 
any as yet.

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 20 Dec 2004, at 22:21, Ceki Gülcü wrote:
At 11:03 PM 12/20/2004, robert burrell donkin wrote:
(ceki - can't you keep your troops in line! ;)
I really don't have any troops marching at my orders. Those who are
affiliated with Logging Services do not necessarily listen to me
anyhow, let alone take any orders.  They are all independently minded
people who express their minds freely. We are extremely lucky to
have them. (It doesn't always work out so well in other projects.)
exactly (and that was the intended joke)
LOL! how the story has been rewritten in the last two years...
What I find fascinating is the extent to which political
considerations seem to outweigh technical considerations.
ISTM it hasn't really started out so political this time (or did i miss 
it...)

we certainly have a different agenda here in the commons but IMO that 
has more to do with technical matters such as how to make bricks that 
can fit...

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 11:03 PM 12/20/2004, robert burrell donkin wrote:
(ceki - can't you keep your troops in line! ;)
I really don't have any troops marching at my orders. Those who are
affiliated with Logging Services do not necessarily listen to me
anyhow, let alone take any orders.  They are all independently minded
people who express their minds freely. We are extremely lucky to
have them. (It doesn't always work out so well in other projects.)
LOL! how the story has been rewritten in the last two years...
What I find fascinating is the extent to which political
considerations seem to outweigh technical considerations.
- robert
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 18 Dec 2004, at 20:52, Curt Arnold wrote:
On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:

We ARE assuming that maintaining SOME SIGNIFICANT compatibility with 
the
existing JCL is of paramount importance.  We are NOT trying to 
standardize
on some "other" API within the industry, but rather to evolve an 
existing
standard with new function.  The API's are based *functionally* on 
JSR-47
and other logging implementations.  It's fair to say that there is 
more
than a little experience being brought to bear on this effort within 
the
Jakarta community.

Again, I'm coming into this late.   Is there a requirements doc of 
some sort other than what was in this thread, have there been any 
votes, anything in CVS, any timeline?
there was a vote but i think it was a little premature. certainly, 
there's been no pressure to conclude it and it seems to me that the 
present consensus is that more talk and thought is needed.

commons appears to be in the process of migrating to subversion. i feel 
an urge to code but it'd be better to take a branch or three to further 
the discussion in code. so for the moment, i don't think we'll see any 
commits for a while yet. certainly, i wouldn't feel comfortable with 
any as yet.

personally speaking, i think that refactoring the discovery process is 
a pre-requisite to firming up the design. i have seen too much 
discussion on that yet so maybe we're still a little way off...

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 18 Dec 2004, at 20:52, Curt Arnold wrote:
On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:

That a single log request can be rendered for more than one locale
would either require having a localizable object passing through the
logging dispatch system, being able to translate the log request at 
the
appender or some other approach internal to the logging system.
Constructing a message using resource bundles and passing a rendered
message on to log4j logging would not accomplish that goal.
We do not desire to pass on the rendered message, unless the 
underlying
logger offers us no alternative.  We desire to pass the messageID and
parameters directly to the Logger, to be handled as it would.

Again, I'm not sure what changes/problems you are arguing for?
That is effectively issuing an architectural ultimatum to the logging 
implementations: be able to pass resource bundles and parameters 
through your processing pipeline or appear to be a second class 
implementation of Jakarta Commons Logging.
(ceki - can't you keep your troops in line! ;)
LOL! how the story has been rewritten in the last two years...
we here in the commons are humble implementors of a simple (but yet too 
complex) thin (but too fat) bridging API. we are second class (we don't 
really provide any logging worth a damn): the logging system architects 
are the first class citizens.

FWIW i have an idea that logging systems capable of supporting native 
thin wrapper implementations will actually be mostly used through the 
Log compatibility layer.

If this is making architectural demands, it would be right to have the 
implementors feedback.
though we are hoping not to make architectural demands, i think 
everyone here is glad to have your feedback.

your points about the distinction between administrative and diagnostic 
logging interest me. it seems to me that diagnostic logging is less 
about the language that the log is written in and more about being able 
to correlate the message with the code that created the message. this 
suggests that knowledge of the key is much more critical than the 
message itself for diagnostic output. given a good key creation 
convention ("org.apache.commons.bizarro[100]", say). it might therefore 
be useful to be able to be able to render the key as part of the 
message (or even as the message).

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 18 Dec 2004, at 18:24, Richard Sitze wrote:
Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 11:13:25 PM:
On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:

Some of advantages of this approach: no API change is necessary,
diagnostic messages are still trivial to add and fast to process,
each
appender may have a different locale, localization has no cost for
discarded messages, generic language (typically english) messages 
are
available for messages that have not been translated (and likely 
most
diagnostic messages would not be), does not require customized
readers.
It is reasonable to attempt to "standardize" a general "enablement"
for
I18N on the API level.  Sure, you can roll your own.  Sure, each
component
could roll it's own...  Sure, we can duplicate this endlessly.  Let's
standardize this now.
As long as this effort is only trying to define an abstraction layer 
to
unify existing practice and implementations, I'm okay with it.  If it
is trying to "standardize" an API before implementations are available
and without consultation with major implementations like the Logging
Services Project, then I would be concerned.
IIRC we're never really gone for official consultations here at apache 
(or at least the bits i've been involved with): too much committee, too 
little community. i alerted ceki (who i've know and respected for too 
many years even though we don't always agree) soon after i discovered 
this thread and hoped that other interested folks from the logging 
project.

jakarta commons has a slightly different focus and expertise. we're 
more interested in bricks (small, compact reusable components with 
minimal dependencies) than logging systems. the extensions proposed by 
richard would allow components with enhanced logging requirements (such 
as i18nable messages) to be added to the commons.

so, in many ways it doesn't matter whether existing logging systems 
offer these capabilities or not: what matters is whether there is a 
need for this kind of enhanced logging for the kind of bricks built by 
the jakarta commons. it's good people that logging experts have shown 
up to the party but (so long as a need for this exists), the party 
would have happened anyway.

From reading the thread, I'm not sure what the effort is trying to do.
We ARE assuming that maintaining SOME SIGNIFICANT compatibility with 
the
existing JCL is of paramount importance.  We are NOT trying to 
standardize
on some "other" API within the industry, but rather to evolve an 
existing
standard with new function.  The API's are based *functionally* on 
JSR-47
and other logging implementations.  It's fair to say that there is more
than a little experience being brought to bear on this effort within 
the
Jakarta community.
i think that this is one of the crucial matters which hasn't really 
been totally bottomed out.

IMHO enterprise commons logging it is technically feasible to added as 
a compatible extension to JCL. however, the proposal breaks down a 
little into a number of independent requests: i18nable logs; improved 
support for JSR-47; better discover and so on. in addition, there are a 
few other issues which are related which have been itches for quite a 
period (including improved support for frameworks, support for more 
varied environments and better packaging for distributables).

the question i pose is: are we trying for a JCL 2.0 which in my mind 
would be a compatible evolution of JCL 1.0 aiming to solve all the 
major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover 
and factoring) plus additional pluggable modules...?

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Curt Arnold <[EMAIL PROTECTED]> wrote on 12/18/2004 03:19:41 PM:

> 
> On Dec 18, 2004, at 2:18 PM, Richard Sitze wrote:
> 
> >>
> >> +1.  Just because the JDK 1.4 log does this, doesn't mean that we 
have
> >> to enforce this behavior on all logging implementations.  Why not 
just
> >> leave it generic?  If someone wants enter/exit methods, they can 
> >> define
> >> their own:
> >>
> >> public static void enter(Log log, Class clazz, String method);
> >> public static void exit(Log log, Class clazz, String method);
> >
> > The proposal is for more than a the simple helper methods, it is for 
> > the
> > [potential] underlying implementation below.  Where possible, these 
> > SHOULD
> > be mapped to a finer level than 'debug', but not as fine as 'trace'.
> >
> > By naming them 'enter/exit' instead of 'finer', we encourage their use 

> > in
> > a particular fashion...  if you feel that such strong "best-practice"
> > enforcement is inappropriate, then let's not throw the dog [and I know
> > it's a dog ;)] out with the bath water.
> >
> > We'd like at least one more trace level, see below.
> >
> 
> 
> Maybe the tension is a manifestation of the problem of trying to assign 
> one common severity to entering and exiting messages.  Some entries 
> have to be more significant than others, the only mechanism to 
> distinguish them in the JSR-47 is to not instrument the less 
> significant entry points.
> 
> 
> Maybe adding a
> 
> entering(Level level, String...)
> 
> The JSR-47 adapter could map this the JSR's entering if level was the 
> equivalent of FINER or lower and fabricate a similar message if the 
> level were higher than finer.

Interesting point.  We're trying to NOT expose parameterized levels in 
JCL.

Not to say that we can't, just that I expect heated discussion within the 
community ;)




***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Curt Arnold <[EMAIL PROTECTED]> wrote on 12/18/2004 02:52:02 PM:

> 
> On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
> >
> > As you pointed out earlier, much of this depends on how the logger is
> > used.  Class category names for code logging, other "application 
> > category"
> > logger names for the other would be a reasonable approach.
> >
> > However, for our stated *GOAL*, JCL's primary purpose is for 
> > instrumenting
> > components that are expected to plug into larger 
> > applications/frameworks.
> > It's not clear to me what it means to start instrumenting such 
> > components
> > for "administrative" or "application" level logging events.  Not to 
> > say it
> > couldn't be done.  This is a "best-practice" issue for the most 
part...
> > something for the users guide.
> >
> > If there are specific issues to be addressed by the API's, please 
raise
> > them?  Examples?  It's not clear to me what course of action you 
> > advocate.
> >
> 
> I was trying to give examples that the localized messages are not 
> needed because the system is "enterprise" level or because the message 
> is significant, but due to the audience and nature of the message. 

Agreed

> Enterprise level systems may have more messages that need to be 
> localized, but that doesn't mean that non-enterprise level systems 
> would not benefit.

Agreed

> log4j and JSR-47 was designed and optimized for diagnostic logging, 
> however they can be applied effectively for administrative logging. 
> However when they do, there are some aspects (like localization) that 
> may be lacking.  However if I was designed a system that needed 
> configurable routing of administrative messages, then I could do worse 
> than using log4j or JSR-47 and working within their constraints or 
> evolving them.

Fair enough, but always remember to keep our primary goals in mind.

> 
>  There are a couple of issues with the resource bundle proposals 
that
> > I
>  have seen previously.  I haven't had time to review those presented
>  here so they may or may not apply.
> 
>  Resource bundle approaches are sufficiently demanding of developers
>  that they will likely substantially reduce the density of 
diagnostic
>  messages if only a resource bundle approach is available.
> >
> > What are our (simple) options.  Again remember that we expect to be a
> > thin-wrapper over existing log implementations.
> >
> 
> Depends on the requirements.  All I have to go on is what was in the 
> thread and there didn't seem to be a huge amount of elaboration.

The requirements are all on the thread [archive], original post.  There is 
probably a lot of historical discussion that establishes context, in the 
JCL community.

Elaboration is coming through discussion, thank you for your comments.


> If the requirement is to support localization of logging messages, then 
> there are multiple ways of attacking that problem.  If the requirement 
> is to provide a facade to mimic JSR-47's resource bundle approach, then 
> that is very achievable, however I think it is likely to not be a 
> deeply satisfactory solution to localizing logging messages without 
> some accomodation in the implementations.

The requirement is to enable localization of logging messages via a facade 
that maps to JSR-47 or other loggers that support localization underneath. 
 Ideally to pass the localization info straight through to underlying 
implementations that support.

> 
> > You seem to be arguing against [pervious statements in your original
> > post], and against [your new statements.  What is your point?
> >
> 
> I am trying to say that the severity of the message is independent of 
> the intended audience of the message and the need for localization. 
> You can have an ERROR message targeted to a diagnostician that should 
> be locale-neutral and a DEBUG message targeted to an administrator that 
> needs to be localized.

Ok, I can understand this...  but would counter that
a) you design to what the API's support.
b) remember the target use: components.  The primary purpose of trace 
level info is going to be diagnostic, and the intended audience would be 
the developer(s).  Balance is key, there is no one right answer.

> 
> >
> >> If I was using a logging system to report, say
> >> employee status to a store manager, an employee arriving or leaving
> >> might be assigned an INFO status, i. e. lowest severity that is
> >> typically reported.  If I was trying to diagnose a drop in
> >> productivity, I might want to be able to configure that I should get
> >> DEBUG severity events, like door swipes or cash register logins and I
> >> would still want these in my preferred language.
> >
> > Then the designer must be aware of the distinction between trace level
> > logging, as intended for application debugging, and for message level
> > logging.  Everything you describe is message level logging.
> >
> > I think I'm starting to see where you are going with this

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Scott Deboy]

Enter and exit should not be defined as severities.  This is useful 
information, but orthogonal to a logging event's severity attribute.

One way to provide entry/exit information is to overload the logger methods to 
take a map, and require the user to adhere to use-case specific conventions for 
keys and values.

For example, to track entry and exit as we cross component boundaries, these 
entries might be sufficient to identify an event:

Key Name Value
-
boundary.type component
boundary.stateentry

Similarly, to track entry and exit as we cross class boundaries:

Key Name Value
-
boundary.type class
boundary.stateexit

This provides a general mechanism for extending what information an event 
provides - without codifying use-case specific attributes as methods in 
commons-logging.

Again, the user would be responsible for conforming to naming conventions for 
the map entries (possibly with the aid of helper methods to build the map) in 
order to discover these use-case specific events.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Developers of open source components that are expected to be plugged into 
different projects simply cannot and should not assume that Log4J, JSR-47, 
Avalon, or any other logger IS present.  This may severely limit the 
logging capabilities that may be used by such components.  This is the 
price we pay to be able to go into a customers shop, install an open 
source solution, and map the logger to their own internal infrastructure 
with minimal code overhead AND minimal impact on their deployment and 
administrative processes.

It's good to know Log4J is growing so strongly, it is an excellent 
project.  I've enjoyed using it myself a few times.


Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/18/2004 11:34:14 AM:

> At 05:44 PM 12/18/2004, Matt Sgarlata wrote:
> >Noel J. Bergman wrote:
> >>
> >>Actually, I agree.  I'd prefer to see that semantic state encoded in 
the log
> >>message, which I feel is much cleaner.
> >> --- Noel
> >
> >+1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
to 
> >enforce this behavior on all logging implementations.  Why not just 
leave 
> >it generic?  If someone wants enter/exit methods, they can define their 
own:
> >
> >public static void enter(Log log, Class clazz, String method);
> >public static void exit(Log log, Class clazz, String method);
> >
> >Personally, I am against introducing logging that is more specific than 

> >TRACE.  In practice, I think it's hard to explain even the distinction 
> >between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
or 
> >the other almost exclusively if they're not using INFO or higher for 
the 
> >message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
mean 
> >JCL has to.  What happens when the next implementation comes along that 

> >offers 42 different logging levels, including TINY, VERYTINY, 
> >EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?
> 
> Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
> domains for categorizing logging statements. When that happens, the
> notion of logging levels will be looked at very differently.
> 
> Commons-logging promises to abstract different logging APIs such as
> log4j, Avalon logkit and java.util.logging API. However, such a task
> is near impossible to fulfill, while Avalon Logkit is nowhere to be
> seen. In the history of software, no one has ever managed to abstract
> competing and divergent APIs without their active cooperation. Chances
> are it won't happen this time around either.
> 
> User who currently use commons-logging are likely to go through a
> lengthy and painful conversion process when they realize that log4j
> offers must-have features.
> 
> 
> >Matt
> 
> -- 
> Ceki Gülcü
> 
>The complete log4j manual: http://qos.ch/log4j/
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Curt Arnold]

On Dec 18, 2004, at 2:18 PM, Richard Sitze wrote:
+1.  Just because the JDK 1.4 log does this, doesn't mean that we have
to enforce this behavior on all logging implementations.  Why not just
leave it generic?  If someone wants enter/exit methods, they can 
define
their own:

public static void enter(Log log, Class clazz, String method);
public static void exit(Log log, Class clazz, String method);
The proposal is for more than a the simple helper methods, it is for 
the
[potential] underlying implementation below.  Where possible, these 
SHOULD
be mapped to a finer level than 'debug', but not as fine as 'trace'.

By naming them 'enter/exit' instead of 'finer', we encourage their use 
in
a particular fashion...  if you feel that such strong "best-practice"
enforcement is inappropriate, then let's not throw the dog [and I know
it's a dog ;)] out with the bath water.

We'd like at least one more trace level, see below.

Maybe the tension is a manifestation of the problem of trying to assign 
one common severity to entering and exiting messages.  Some entries 
have to be more significant than others, the only mechanism to 
distinguish them in the JSR-47 is to not instrument the less 
significant entry points.

Maybe adding a
entering(Level level, String...)
The JSR-47 adapter could map this the JSR's entering if level was the 
equivalent of FINER or lower and fabricate a similar message if the 
level were higher than finer.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Curt Arnold]

On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
As you pointed out earlier, much of this depends on how the logger is
used.  Class category names for code logging, other "application 
category"
logger names for the other would be a reasonable approach.

However, for our stated *GOAL*, JCL's primary purpose is for 
instrumenting
components that are expected to plug into larger 
applications/frameworks.
It's not clear to me what it means to start instrumenting such 
components
for "administrative" or "application" level logging events.  Not to 
say it
couldn't be done.  This is a "best-practice" issue for the most part...
something for the users guide.

If there are specific issues to be addressed by the API's, please raise
them?  Examples?  It's not clear to me what course of action you 
advocate.

I was trying to give examples that the localized messages are not 
needed because the system is "enterprise" level or because the message 
is significant, but due to the audience and nature of the message.  
Enterprise level systems may have more messages that need to be 
localized, but that doesn't mean that non-enterprise level systems 
would not benefit.

log4j and JSR-47 was designed and optimized for diagnostic logging, 
however they can be applied effectively for administrative logging.  
However when they do, there are some aspects (like localization) that 
may be lacking.  However if I was designed a system that needed 
configurable routing of administrative messages, then I could do worse 
than using log4j or JSR-47 and working within their constraints or 
evolving them.

There are a couple of issues with the resource bundle proposals that
I
have seen previously.  I haven't had time to review those presented
here so they may or may not apply.
Resource bundle approaches are sufficiently demanding of developers
that they will likely substantially reduce the density of diagnostic
messages if only a resource bundle approach is available.
What are our (simple) options.  Again remember that we expect to be a
thin-wrapper over existing log implementations.
Depends on the requirements.  All I have to go on is what was in the 
thread and there didn't seem to be a huge amount of elaboration.

If the requirement is to support localization of logging messages, then 
there are multiple ways of attacking that problem.  If the requirement 
is to provide a facade to mimic JSR-47's resource bundle approach, then 
that is very achievable, however I think it is likely to not be a 
deeply satisfactory solution to localizing logging messages without 
some accomodation in the implementations.

You seem to be arguing against [pervious statements in your original
post], and against [your new statements.  What is your point?
I am trying to say that the severity of the message is independent of 
the intended audience of the message and the need for localization.  
You can have an ERROR message targeted to a diagnostician that should 
be locale-neutral and a DEBUG message targeted to an administrator that 
needs to be localized.



If I was using a logging system to report, say
employee status to a store manager, an employee arriving or leaving
might be assigned an INFO status, i. e. lowest severity that is
typically reported.  If I was trying to diagnose a drop in
productivity, I might want to be able to configure that I should get
DEBUG severity events, like door swipes or cash register logins and I
would still want these in my preferred language.
Then the designer must be aware of the distinction between trace level
logging, as intended for application debugging, and for message level
logging.  Everything you describe is message level logging.
I think I'm starting to see where you are going with this... and would
start by arguing that "independent pluggable components" are not
necessarily the right place to start making assumptions of this sort, 
or
even the right place to be logging this level of information.
I was trying to provide reasonable use case sub-INFO severity message 
would need localization.

The primary requirements that drove log4j were diagnostic logging 
requirements and localization was not a significant design concern.  
Developers have applied in many uses, like administrative logging, that 
weren't in the initial set of requirements.  The questions is if these 
two types of "logging" are incompatible and need two distinct API's or 
if one API can acceptably handle both.

If you are saying that log4j and JCL should ignore requirements from 
people who are using it for administrative logging, then were are the 
requirements for localization coming.


That a single log request can be rendered for more than one locale
would either require having a localizable object passing through the
logging dispatch system, being able to translate the log request at 
the
appender or some other approach internal to the logging system.
Constructing a message using resource bundles and passing a rendered
message on to log4j 

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

While acknowledging that while we all orbit the same sun, we also stand in 
different time zones and see it differently... :-)


news <[EMAIL PROTECTED]> wrote on 12/18/2004 10:44:11 AM:

> Noel J. Bergman wrote:
> > Simon Kitching wrote:
> >>I've been convinced by the arguments put forward in this thread that
> >>explicit enter/exit methods taking class+method strings should not
> >>be encouraged
> > 
> > 
> > Actually, I agree.  I'd prefer to see that semantic state encoded in 
the log
> > message, which I feel is much cleaner.
> > 
> >--- Noel
> 
> +1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
> to enforce this behavior on all logging implementations.  Why not just 
> leave it generic?  If someone wants enter/exit methods, they can define 
> their own:
> 
> public static void enter(Log log, Class clazz, String method);
> public static void exit(Log log, Class clazz, String method);

The proposal is for more than a the simple helper methods, it is for the 
[potential] underlying implementation below.  Where possible, these SHOULD 
be mapped to a finer level than 'debug', but not as fine as 'trace'.

By naming them 'enter/exit' instead of 'finer', we encourage their use in 
a particular fashion...  if you feel that such strong "best-practice" 
enforcement is inappropriate, then let's not throw the dog [and I know 
it's a dog ;)] out with the bath water.

We'd like at least one more trace level, see below.

 
> Personally, I am against introducing logging that is more specific than 
> TRACE.  In practice, I think it's hard to explain even the distinction 
> between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
> or the other almost exclusively if they're not using INFO or higher for 
> the message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
> mean JCL has to.  What happens when the next implementation comes along 
> that offers 42 different logging levels, including TINY, VERYTINY, 
> EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?

There are many uses for different levels of trace logging [general term, 
not JCL trace].  One such for which I advocate better support is:

1.  Tracing as we cross component boundries [currently this would be JCL 
debug on classes representing component API's].  I want to log information 
that helps me understand what's coming in, and what's going out, at a 
COMPONENT level [component TBD as you like].

2.  Tracing as we cross class/method boundries [currently we propose this 
with enter/exit].

3.  Tracing of additional low level information [currently this would be 
JCL trace].

Two trace levels is simply not enough.  Granted we can play games with 
loggerNames, but feel this unnecessarily imposes multiple "logger name" 
schemes where the "class name" is more than sufficient for most uses.  IN 
PARTICULAR, if we want to document this as a "best-practice" in the users 
guide, then we need also to ensure that there is a consistent "logger 
name" scheme being used across components, that there are no [or minimal] 
collisions...  class name really simplifies this.


***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Excellent!

Chris Lambrou <[EMAIL PROTECTED]> wrote on 12/17/2004 04:32:28 PM:

> 
> >Someone suggested that for Log, it would be appropriate to make it an 
> >abstract class rather than an interface, so we can make these kinds of 
> >changes easier in the future.  I think the risks for this are low, and 
> >probably better [less problems for the majority of users] than just 
adding 
> >new methods to the existing interface.  Other thoughts on this 
direction?
> > 
> >
> I think the risk of annoying quite a number of users by changing Log 
> from an interface to an abstract class is actually quite high. For sure, 

> one of the default logging implementations provided by JCL would 
> probably suffice for the majority. However, there are groups who will 
> have chosen, for whatever reason, to provide their own logging 
> implementations. I've certainly worked on a couple of projects where 
> this has been the case. One of them could probably cope with the change 
> relatively easiliy, but such a change could be a real pain for the 
> other. Whilst the proportion of JCL users in this situation is probably 
> quite small, in terms of actual numbers, such a change could cause quite 

> a lot of grief.

IF we went down this road [no such proposal has yet been made], you would 
be required to make SOME code change.

a. Change the 'implements' to an 'extends', pick up default impls for the 
new methods.
b. Supply new methods all your existing code that implements Log.

You advocate that (a) is a bigger hit to you.  I would have thought (b) 
would be more difficult, UNLESS your current Log implementations extend 
some other class.  I would have thought Log classes extending other [non 
Log] classes would be very unlikely.


***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 17 Dec 2004, at 01:56, Richard Sitze wrote:
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/16/2004 04:38:34 PM:

the solution i've been considering is to separate the base
application-environmental configuration from the sophisticated
discovery process required to ensure proper isolation in complex
managed server environments. (i'm not going to describe this in detail
right now: i should post a code example but i'm tired so that'll have
to wait.)
I will eagerly await, and will compare your thoughts to what is 
described
in the original proposal.  For reference, please note that the proposal
can be found here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32618
i've added some thoughts onto some new wiki pages linked from 
http://wiki.apache.org/jakarta-commons/Logging.

where does byte-code engineering come in? well, there are certain
things that users want that are just not going to be feasible no 
matter
how sophisticated a discovery process is employed. too much complexity
leads to fragility in the discovery code: providing rewiring at the
byte-code level would allow users great control and relieve the
commons-logging development team of the burden of creating every more
complex discovery code.
And other teams... this *must* be addressed independently from Logging.
+1
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 18 Dec 2004, at 16:25, Matt Sgarlata wrote:

robert burrell donkin wrote:
> does anyone think that there is any real need for implementations to
> belong to a second type hierarchy?
I don't think it's a good idea to *preclude* logs from participating 
in two different type hierarchies because it's hard to anticipate new 
use cases.
it's a tradeoff :)
it's hard to anticipate new use cases. this means that it's hard to 
future-proof any interface. Log isn't too bad but (had it been an 
abstract class) i think that it would have had at least one more method 
added (to improve support for IoC frameworks). it's important to keep 
in mind that these interfaces are likely to have to maintain 
compatibility for several years.

But to answer your question, remember how Richard proposed that the 
generation of exception messages be possible with Logs?  Well I think 
the community struck that idea down, but what if someone *did* decide 
they wanted to combine that functionality with their logger.  In that 
case they would probably want to extend some type of message 
resolution base class rather than being forced to extend a Log 
abstract class.
(i wasn't the first to note this but) inheritance is often overused in 
java. an equally good design could use delegation (to the message 
resolution class) or a nested implementation. i don't mind forcing 
users to choose a particular design provided that this design is as 
good or better than the original.

the only use case (where alternative, equitable designs do not exist) i 
can think of would be a Log proxy. i'm not sure how useful that would 
be.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 11:13:25 PM:

> 
> On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:
> 
> > Good comments, thanks.
> >
> >
> > Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM:
> >
> >> Sorry to come in on this late.  I just read the archives after Ceki
> >> posted a link on log4j-dev.
> >>
> >> First, I agree Enterprise is a poor name.  I tend to think in terms 
of
> >
> > Back to the issue of names, assuming we don't play some of the other 
> > games
> > mentioned above, other name suggestions are welcome.
> >
> 
> I wasn't terribly concerned about the eventual class names.  More try 
> to make the observation that the major tension is between the intended 
> audience for the message not the scope of the system.  A debug or trace 
> level message in a handheld app has more in common with a trace level 
> message in a enterprise system than either has with a "out of stock" 
> warning in either system.
> 
> >
> >> diagnostic versus administrative logging.  Diagnostic logging 
intended
> >> to diagnose an issue where log requests are generally discarded 
> >> (unless
> >> actively researching a problem) and fluency with internal program
> >> structure and with the human language used in the implementation is
> >> assumed.  Logger names based on class names would be appropriate here
> >> since the audience is likely familiar with the code base.
> >
> > Agreed.
> >
> > JCL [as well as Log4J and JSR-47 logging] supports "trace level" [JCL
> > debug, trace] logging which I believe equates to what you term 
> > "diagnostic
> > logging".  We do *not* propose to 'internationalize' these... I would
> > resist such efforts.
> >
> >>
> >> Administrative logging (in lack of a better term, but at least it is
> >> better than Enterprise) are messages intended for a difference 
> >> audience
> >> where knowledge of internal program structure and the human language 
> >> of
> >> the implementation is not given.  These difference audiences have
> >> resulted in different API on some platforms, for example, Windows has
> >> OutputDebugString (for diagnostic messages) and the Event log methods
> >> for administrative messages.  Logger names here would likely be
> >> business process related.
> >
> > Reasonable, not sure if your intention is to relate this type of 
> > logging
> > to the "message level" logging of JCL [fatal, error, warn, info].
> 
> I don't think that was my intention.  Platform provided diagnostic 
> logging, like Win32 OutputDebugString, may be very simplistic and 
> provide no support for prioritization, persistence, or 
> internationalization.  Platform provided administrative logging, like 
> the NT event log, would likely support some of those.  Both a 
> diagnostic and a administrative system may have a concept of a WARN 
> severity, however the business significance of a WARN severity may be 
> orders of magnitude different depending on the context.   I would not 
> think it common that, for example, inventory messages would switch from 
> using a diagnostic to an administrative type API based on message 
> severity.

As you pointed out earlier, much of this depends on how the logger is 
used.  Class category names for code logging, other "application category" 
logger names for the other would be a reasonable approach.

However, for our stated *GOAL*, JCL's primary purpose is for instrumenting 
components that are expected to plug into larger applications/frameworks. 
It's not clear to me what it means to start instrumenting such components 
for "administrative" or "application" level logging events.  Not to say it 
couldn't be done.  This is a "best-practice" issue for the most part... 
something for the users guide.

If there are specific issues to be addressed by the API's, please raise 
them?  Examples?  It's not clear to me what course of action you advocate.

> >
> >> There are a couple of issues with the resource bundle proposals that 
I
> >> have seen previously.  I haven't had time to review those presented
> >> here so they may or may not apply.
> >>
> >> Resource bundle approaches are sufficiently demanding of developers
> >> that they will likely substantially reduce the density of diagnostic
> >> messages if only a resource bundle approach is available.

What are our (simple) options.  Again remember that we expect to be a 
thin-wrapper over existing log implementations.


> >>
> >> Using the locale settings of the user or system is likely 
> >> inappropriate
> >> for diagnostic messages.  A diagnostician reviewing log files or
> >> receiving networked log messages should not be forced to read log
> >> messages in the user's native language.  A worse case scenario would 
> >> be
> >> a internationalized web site log where the language in the log file 
> >> was
> >> constantly changing.
> >
> > Agreed.  Again, the current proposal does not provide I18N enabled 
> > logging
> > for JCL debug or trace methods.
> 
> If I was a diagnostician

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 05:44 PM 12/18/2004, Matt Sgarlata wrote:
Noel J. Bergman wrote:
Actually, I agree.  I'd prefer to see that semantic state encoded in the log
message, which I feel is much cleaner.
--- Noel
+1.  Just because the JDK 1.4 log does this, doesn't mean that we have to 
enforce this behavior on all logging implementations.  Why not just leave 
it generic?  If someone wants enter/exit methods, they can define their own:

public static void enter(Log log, Class clazz, String method);
public static void exit(Log log, Class clazz, String method);
Personally, I am against introducing logging that is more specific than 
TRACE.  In practice, I think it's hard to explain even the distinction 
between TRACE and DEBUG (i.e. - the projects I've seen tend to use one or 
the other almost exclusively if they're not using INFO or higher for the 
message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't mean 
JCL has to.  What happens when the next implementation comes along that 
offers 42 different logging levels, including TINY, VERYTINY, 
EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?
Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
domains for categorizing logging statements. When that happens, the
notion of logging levels will be looked at very differently.
Commons-logging promises to abstract different logging APIs such as
log4j, Avalon logkit and java.util.logging API. However, such a task
is near impossible to fulfill, while Avalon Logkit is nowhere to be
seen. In the history of software, no one has ever managed to abstract
competing and divergent APIs without their active cooperation. Chances
are it won't happen this time around either.
User who currently use commons-logging are likely to go through a
lengthy and painful conversion process when they realize that log4j
offers must-have features.

Matt
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Noel J. Bergman wrote:
Simon Kitching wrote:
I've been convinced by the arguments put forward in this thread that
explicit enter/exit methods taking class+method strings should not
be encouraged

Actually, I agree.  I'd prefer to see that semantic state encoded in the log
message, which I feel is much cleaner.
	--- Noel
+1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
to enforce this behavior on all logging implementations.  Why not just 
leave it generic?  If someone wants enter/exit methods, they can define 
their own:

public static void enter(Log log, Class clazz, String method);
public static void exit(Log log, Class clazz, String method);
Personally, I am against introducing logging that is more specific than 
TRACE.  In practice, I think it's hard to explain even the distinction 
between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
or the other almost exclusively if they're not using INFO or higher for 
the message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
mean JCL has to.  What happens when the next implementation comes along 
that offers 42 different logging levels, including TINY, VERYTINY, 
EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?

Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Simon Kitching wrote:
Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what "real pain" would be incurred by having
custom logging adapters be declared as:
The pain (as Robert pointed out) is that you preclude FooLog from 
extending any other class.  (More below)

  public class FooLog extends Logger {...}
instead of the existing
  public class FooLog implements Log {...}
Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface?
Ideally instead of changing the existing Log interface, any new methods 
you want to add you introduce in a new interface (e.g. - EnterpriseLog).
If it's possible for EnterpriseLog to be implemented in terms of Log, 
all the better: existing implementations can have an EnterpriseLog 
exposed by using the Decorator pattern.

I really like this approach because it allows you to keep programming to 
interfaces rather than classes.  For example, let's say that I had my 
own legacy CustomLogger that had some nice features I would like to keep 
when I migrate to JCL.  CustomLogger participates in its own type 
hierarchy.  All I have to do to integrate it with JCL is make it 
implement the Log interface.  If Log is an abstract class, I have to 
take a sledgehammer to my CustomLogger to make it extend from Log and 
delegate calls to a SledgeHammeredCustomLogger.

I took this approach in Morph and I think it works quite well.  Users 
only implement a simple Converter interface (similar to the one in 
BeanUtils).  I have a separate interface called DecoratedConverter that 
exposes lots of extra methods that can all be implemented in terms of 
the basic Converter interface.  If someone wants to expose their 
plain-old Converter as a DecoratedConverter, all they have to do is 
DecoratedConverter decorated = new ConverterDecorator(converter).  This 
way, if I have an old Converter that participates in a type hierarchy 
already (say one that I wrote for BeanUtils), I can easily plug it into 
Morph by just implementing a new interface.

More below...

robert burrell donkin wrote:
> does anyone think that there is any real need for implementations to
> belong to a second type hierarchy?
I don't think it's a good idea to *preclude* logs from participating in 
two different type hierarchies because it's hard to anticipate new use 
cases.

But to answer your question, remember how Richard proposed that the 
generation of exception messages be possible with Logs?  Well I think 
the community struck that idea down, but what if someone *did* decide 
they wanted to combine that functionality with their logger.  In that 
case they would probably want to extend some type of message resolution 
base class rather than being forced to extend a Log abstract class.

> - robert
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 17 Dec 2004, at 22:32, Chris Lambrou wrote:
Someone suggested that for Log, it would be appropriate to make it an 
abstract class rather than an interface, so we can make these kinds 
of changes easier in the future.  I think the risks for this are low, 
and probably better [less problems for the majority of users] than 
just adding new methods to the existing interface.  Other thoughts on 
this direction?

I think the risk of annoying quite a number of users by changing Log 
from an interface to an abstract class is actually quite high. For 
sure, one of the default logging implementations provided by JCL would 
probably suffice for the majority. However, there are groups who will 
have chosen, for whatever reason, to provide their own logging 
implementations. I've certainly worked on a couple of projects where 
this has been the case. One of them could probably cope with the 
change relatively easiliy, but such a change could be a real pain for 
the other. Whilst the proportion of JCL users in this situation is 
probably quite small, in terms of actual numbers, such a change could 
cause quite a lot of grief.
i think that simon was suggesting the new logical interface proposed is 
implemented (in java) as an empty abstract class as opposed to a 
interface. this would allow new methods to be added without breaking 
compatibility but at the cost of preventing implementations belonging 
to another type hierarchy.

does anyone think that there is any real need for implementations to 
belong to a second type hierarchy?

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Simon Kitching]

Hi Chris,

On Sat, 2004-12-18 at 11:32, Chris Lambrou wrote:
> >Someone suggested that for Log, it would be appropriate to make it an 
> >abstract class rather than an interface, so we can make these kinds of 
> >changes easier in the future.  

That was me (inspired by Robert Donkin's enthusiasm for using abstract
classes rather than interfaces in digester).

> >I think the risks for this are low, and 
> >probably better [less problems for the majority of users] than just adding 
> >new methods to the existing interface.  Other thoughts on this direction?
> >  
> >
> I think the risk of annoying quite a number of users by changing Log 
> from an interface to an abstract class is actually quite high. For sure, 
> one of the default logging implementations provided by JCL would 
> probably suffice for the majority. However, there are groups who will 
> have chosen, for whatever reason, to provide their own logging 
> implementations. I've certainly worked on a couple of projects where 
> this has been the case. One of them could probably cope with the change 
> relatively easiliy, but such a change could be a real pain for the 
> other. Whilst the proportion of JCL users in this situation is probably 
> quite small, in terms of actual numbers, such a change could cause quite 
> a lot of grief.

First, I was suggesting that instead of introducing a *new* *interface*
(Richard's proposal) to provide an extended API that a *new* *abstract
class* be introduced. Neither of us were proposing changing the existing
Log interface.

But if the Log interface were to be changed, then adding methods to it
would break binary compatibility. The most obvious way is that classes
that were previously valid implementations of the interface become
incomplete.

Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what "real pain" would be incurred by having
custom logging adapters be declared as:
  public class FooLog extends Logger {...}
instead of the existing
  public class FooLog implements Log {...}

Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface? Making this sort of change
would indeed "annoy" users as they couldn't used their existing
log-specific adapters with the new JCL release without modifying them.
But that would be the case even if the Log class remained an interface.

And once a move to using abstract classes has been made, we *can* extend
the API later without breaking binary compatibility as long as a
reasonable default implementation can be provided.

The only problem would be if someone had an adapter class that for some
reason needed to extend some other existing class. But I don't see why
that would happen for a logging adapter, and there are reasonable
workarounds for this anyway (eg using a trivial inner class).


Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Paulo Gaspar wrote:

> I don't think we are discounting the value of the original proposal but
> simply questioning if it should be implemented exactly as proposed - a
> process you should be familiar with since it is quite common about
> proposals presented at Apache projects.

David Graham wrote:

> What you're seeing is the natural result of design conversations held
> outside of the mailing list.  No one here had the benefit of participating
> in the localized logging design so naturally we're asking questions and
> making suggestions.

robert burrell donkin wrote:


> i'd much rather that people speak up and voice their concerns now when
> we can actually acknowledge them and (at the very least) document
> reasons for rejecting.

As I said to Simon, I have no issue with any of the constructive debate
surrounding the proposal.  I firmly believe that the best solutions come
from constructive pushing within the solution space to satisfy competing
interests, and are a synthesis derived from the creative input of multiple
people.

However, I also saw some comments that came across to me as unnecessarily
negative, and I don't want to discourage people from trying to innovate
here.

Putting this another way: let's have the debates, but at the same time, make
sure that we encourage participation in the process while we do so.  Not
everyone will have what appears to be Richard's excellent attitude.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Simon Kitching wrote:

> Noel J. Bergman wrote:
> > It disturbs me that what seems to me to be a reasonable and small set of
> > requirements --- along with what appears to have been considerable
> > forethought based upon real world issues, and experiences supporting
many
> > developers --- appears to be discounted a bit too out of hand.  I hope
my
> > perception is wrong.

> The question is whether the implementation of those requirements is a
> good fit for commons-logging or not. Commons-logging is used in many
> environments that the Websphere team may *not* be interested in.

Agreed.  And I have absolutely no issue with any of the constructive debate
that has occured.  But I also saw some comments that came across to me as
dismissive, and I don't want to discourage people from trying to innovate
here.

> I will dispute localisation of log messages if this:

My thought is to have this new layer use a factory pattern to manufacture
the logging string from the parameters.  That would introduce capability and
flexibility without mandating any particular mechanism or overhead, and
would remove the need to impose an i18n requirement on the underlying
logging implementation.

> I've been convinced by the arguments put forward in this thread that
> explicit enter/exit methods taking class+method strings should not
> be encouraged

Actually, I agree.  I'd prefer to see that semantic state encoded in the log
message, which I feel is much cleaner.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

> Aspect oriented tools obsolete the need for this kind of logging method.

We've been able to implement this sort of thing for years using "OpenJava".
You're all using the OpenJava pre-processor, right?  ;-)

Translation: I'll accept this reasoning when AOP tools are part of every
JDK.  Which should be 3-5 years after it is released by Sun.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Richard Sitze wrote:

> As a real example, the axis community uses globalized messages.

A lot of products do, as I see on a regular basis, so I definitely support
your interest in this feature.

However, I view logging as separate from content generation.  I'd like to
see the mechanism pluggable.  That could be done by providing a message
factory to the logging layer, so that it does the lookup rather than your
example:

> log.error(Message.getMessage("MSGID", new String { arg1, ..., argN }));

Doing so would still permit your facade:

  log.error(this.getClass(), "thisMethodName", "MSGID", new String {...});

but the factory that the logger uses to construct the message would be
pluggable and distinct from the role of bridging to an underlying log
mechanism.

And I'd like to see a Java 5 versiion of this interface that takes advantage
of variable argument lists, rather than the String[].

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Chris Lambrou]

Someone suggested that for Log, it would be appropriate to make it an 
abstract class rather than an interface, so we can make these kinds of 
changes easier in the future.  I think the risks for this are low, and 
probably better [less problems for the majority of users] than just adding 
new methods to the existing interface.  Other thoughts on this direction?
 

I think the risk of annoying quite a number of users by changing Log 
from an interface to an abstract class is actually quite high. For sure, 
one of the default logging implementations provided by JCL would 
probably suffice for the majority. However, there are groups who will 
have chosen, for whatever reason, to provide their own logging 
implementations. I've certainly worked on a couple of projects where 
this has been the case. One of them could probably cope with the change 
relatively easiliy, but such a change could be a real pain for the 
other. Whilst the proportion of JCL users in this situation is probably 
quite small, in terms of actual numbers, such a change could cause quite 
a lot of grief.

Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Emmanuel Bourg]

I don't think this alternative has been proposed, the additional 
features could also be provided by a decorator, something like :

ExtendedLog log = new ExtendedLog(LogFactory.getLog(Foo.class));
or
ExtendedLog log = LogFactory.getExtendedLog(Foo.class));
For localization, ExtendedLog would create a LogMessage and pass it to 
the log implementation. It could also add a code guard to reduce object 
creations:

public void debug(String key, Object[] params) {
if (log.isDebugEnabled()) {
log.debug(new LogMessage(key, params));
}
}
For log implementations supporting i18n, the key is extracted from the 
LogMessage and searched in a resource bundle. For other implementations, 
LogMessage.toString() returns the key and the parameters concatenated.

Just some thoughts :) For i18n I think I like Curt's solution of parsing 
the message in the implementation.

Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Curt Arnold]

On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:
Good comments, thanks.
Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM:
Sorry to come in on this late.  I just read the archives after Ceki
posted a link on log4j-dev.
First, I agree Enterprise is a poor name.  I tend to think in terms of
Back to the issue of names, assuming we don't play some of the other 
games
mentioned above, other name suggestions are welcome.

I wasn't terribly concerned about the eventual class names.  More try 
to make the observation that the major tension is between the intended 
audience for the message not the scope of the system.  A debug or trace 
level message in a handheld app has more in common with a trace level 
message in a enterprise system than either has with a "out of stock" 
warning in either system.



diagnostic versus administrative logging.  Diagnostic logging intended
to diagnose an issue where log requests are generally discarded 
(unless
actively researching a problem) and fluency with internal program
structure and with the human language used in the implementation is
assumed.  Logger names based on class names would be appropriate here
since the audience is likely familiar with the code base.
Agreed.
JCL [as well as Log4J and JSR-47 logging] supports "trace level" [JCL
debug, trace] logging which I believe equates to what you term 
"diagnostic
logging".  We do *not* propose to 'internationalize' these... I would
resist such efforts.

Administrative logging (in lack of a better term, but at least it is
better than Enterprise) are messages intended for a difference 
audience
where knowledge of internal program structure and the human language 
of
the implementation is not given.  These difference audiences have
resulted in different API on some platforms, for example, Windows has
OutputDebugString (for diagnostic messages) and the Event log methods
for administrative messages.  Logger names here would likely be
business process related.
Reasonable, not sure if your intention is to relate this type of 
logging
to the "message level" logging of JCL [fatal, error, warn, info].
I don't think that was my intention.  Platform provided diagnostic 
logging, like Win32 OutputDebugString, may be very simplistic and 
provide no support for prioritization, persistence, or 
internationalization.  Platform provided administrative logging, like 
the NT event log, would likely support some of those.  Both a 
diagnostic and a administrative system may have a concept of a WARN 
severity, however the business significance of a WARN severity may be 
orders of magnitude different depending on the context.   I would not 
think it common that, for example, inventory messages would switch from 
using a diagnostic to an administrative type API based on message 
severity.



There are a couple of issues with the resource bundle proposals that I
have seen previously.  I haven't had time to review those presented
here so they may or may not apply.
Resource bundle approaches are sufficiently demanding of developers
that they will likely substantially reduce the density of diagnostic
messages if only a resource bundle approach is available.
Using the locale settings of the user or system is likely 
inappropriate
for diagnostic messages.  A diagnostician reviewing log files or
receiving networked log messages should not be forced to read log
messages in the user's native language.  A worse case scenario would 
be
a internationalized web site log where the language in the log file 
was
constantly changing.
Agreed.  Again, the current proposal does not provide I18N enabled 
logging
for JCL debug or trace methods.
If I was a diagnostician looking at a log, I would want all the 
diagnostic messages, whether they be ERROR or TRACE to be in my 
preferred language not that of a user or web site visitor.  Turning on 
debug or trace messages would likely only occur after I narrow the 
problem down by looking at higher level.

By not having I18N debug or trace messages, you are basically saying 
that those levels don't exist for messages that need to be 
internationalized.  If I was using a logging system to report, say 
employee status to a store manager, an employee arriving or leaving 
might be assigned an INFO status, i. e. lowest severity that is 
typically reported.  If I was trying to diagnose a drop in 
productivity, I might want to be able to configure that I should get 
DEBUG severity events, like door swipes or cash register logins and I 
would still want these in my preferred language.


A log request may need to be rendered for more than one locale.  For
example, a log request may result in email messages send to multiple
recipients each in an appropriate language.
A diagnostic log may be transmitted to a location where the resource
bundles are not available.  If it still is resource based at that
point, you would require a specialized reader which would need to be
kept in sync as new messages were added.
Discarded diagn

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Good comments, thanks.


Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM:

> Sorry to come in on this late.  I just read the archives after Ceki 
> posted a link on log4j-dev.
> 
> First, I agree Enterprise is a poor name.  I tend to think in terms of

Ok.. let me make a few points:

- LocalizedLog, GlobalizeLog, i18nLog, nlsLog, nlvLog, or any of 100 other 
variants along that theme are not strictly appropriate.  I will resist 
these names.  The addition APIs include more than [admittedly not a lot 
more] i18n support.  enter/exit are new trace level [diagnostic level, 
as-per your terms] API's.

- We could consider a staged approach:
  - MoreLog extends Log  [name tbd]: for the enter/exit methods
  - nlsLog extends MoreLog: for i18n API's

Not sure I like the implications of this, but am still reluctant to add 
new methods to Log itself.

Someone suggested that for Log, it would be appropriate to make it an 
abstract class rather than an interface, so we can make these kinds of 
changes easier in the future.  I think the risks for this are low, and 
probably better [less problems for the majority of users] than just adding 
new methods to the existing interface.  Other thoughts on this direction?


Back to the issue of names, assuming we don't play some of the other games 
mentioned above, other name suggestions are welcome.


> diagnostic versus administrative logging.  Diagnostic logging intended 
> to diagnose an issue where log requests are generally discarded (unless 
> actively researching a problem) and fluency with internal program 
> structure and with the human language used in the implementation is 
> assumed.  Logger names based on class names would be appropriate here 
> since the audience is likely familiar with the code base.

Agreed.

JCL [as well as Log4J and JSR-47 logging] supports "trace level" [JCL 
debug, trace] logging which I believe equates to what you term "diagnostic 
logging".  We do *not* propose to 'internationalize' these... I would 
resist such efforts.

> 
> Administrative logging (in lack of a better term, but at least it is 
> better than Enterprise) are messages intended for a difference audience 
> where knowledge of internal program structure and the human language of 
> the implementation is not given.  These difference audiences have 
> resulted in different API on some platforms, for example, Windows has 
> OutputDebugString (for diagnostic messages) and the Event log methods 
> for administrative messages.  Logger names here would likely be 
> business process related.

Reasonable, not sure if your intention is to relate this type of logging 
to the "message level" logging of JCL [fatal, error, warn, info].

> There are a couple of issues with the resource bundle proposals that I 
> have seen previously.  I haven't had time to review those presented 
> here so they may or may not apply.
> 
> Resource bundle approaches are sufficiently demanding of developers 
> that they will likely substantially reduce the density of diagnostic 
> messages if only a resource bundle approach is available.
> 
> Using the locale settings of the user or system is likely inappropriate 
> for diagnostic messages.  A diagnostician reviewing log files or 
> receiving networked log messages should not be forced to read log 
> messages in the user's native language.  A worse case scenario would be 
> a internationalized web site log where the language in the log file was 
> constantly changing.

Agreed.  Again, the current proposal does not provide I18N enabled logging 
for JCL debug or trace methods.


> A log request may need to be rendered for more than one locale.  For 
> example, a log request may result in email messages send to multiple 
> recipients each in an appropriate language.
> 
> A diagnostic log may be transmitted to a location where the resource 
> bundles are not available.  If it still is resource based at that 
> point, you would require a specialized reader which would need to be 
> kept in sync as new messages were added.
> 
> Discarded diagnostic messages need to be very low cost.  Administrative 
> messages are vastly less frequent, are rarely discarded and can be 
> fairly expensive.

Agreed.


> An approach that I've found to work fairly well without requiring API 
> modifications is the use of a localizing layout.
> http://www.mail-archive.com/log4j-user@logging.apache.org/ 
> msg00479.html) describe the use of such a layout in a project using 
> log4net.  If you were careful on how you constructed your messages (for 
> example, start with fixed content instead of variable content, did not 
> allow your conversions to be affected by the default locale), you could 
> create a fairly efficient localization mechanism by having a layout 
> that would match the "generic" message and transform it into an 
> appropriate localized content based on an external document containing 
> regex patterns and substitutions.

This is much to complex for the casual

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
12/16/2004 04:38:34 PM:



> >
> > I think this demonstrates a major issue.
> >
> > When using logging in an "enterprise" situation, the logging can be
> > considered a critical part of the application. If you have heavy-duty
> > monitoring systems watching for alerts from the software, and have
> > sysadmins on call 24x7 to deal with issues, then for an application to
> > fail to locate the correct logging libs or config files is a *failure*
> > of the app. You don't want an app to start up, but then not be able to
> > generate alerts if problems occur.
> >
> > But when using logging in other situations, logging is *not* a 
critical
> > part, and should not cause an application to fail to start.
> >
> > The latter is the focus of commons-logging at the moment. And
> > unfortunately as commons-logging has no *mandatory* configuration, it 
> > is
> > not possible to add a "fail-on-no-config" option!
> 
> +1
> 
> it seems to me that there are actually two separate levels of 
> configuration: one for the total application environment and one for 
> components within that environment.

I don't entirely disagree, but we have adamantly maintained that for JCL 
in particular, there IS no configuration of the underlying logger by JCL. 
That should be left to the logger implementation.

So... what do you think the components should/could configure for logging?

> after a long time trying to work out how to satisfy everyone, i now 
> think that discovery processes can only work within a particular 
> application domain. for example, the current discovery process works 
> well on tomcat, less well on jboss, badly in applets and not at all for 
> J2ME. i believe that it would be possible to create satisfactory 
> discovery systems for limited domains but it would not be possible to 
> use an uber-discovery process to guess the environment.
> 
> the weakness in current design seems to be the bootstrap process. a 
> discovery process most suitable for only one domain is part of the code 
> that components compile against.

I've started to recognize this myself...

a. This is an argument for commons-discovery.. to break the discovery 
process completely OUT of the components that need to be discovered [JCL 
is one such].

b. Have asked myself the horrible question of how "discovery" might 
"discover" itself.  I get a headache quickly, and wish I drank.

c. Realize that the simple answer is that discovery does NOT discover, 
it's "hard coded" for a particular environment.  The [high level] API's 
are standardized, and a commons component [such as commons logging] MUST 
be able to assume that they are there.

> the solution i've been considering is to separate the base 
> application-environmental configuration from the sophisticated 
> discovery process required to ensure proper isolation in complex 
> managed server environments. (i'm not going to describe this in detail 
> right now: i should post a code example but i'm tired so that'll have 
> to wait.)

I will eagerly await, and will compare your thoughts to what is described 
in the original proposal.  For reference, please note that the proposal 
can be found here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32618


> where does byte-code engineering come in? well, there are certain 
> things that users want that are just not going to be feasible no matter 
> how sophisticated a discovery process is employed. too much complexity 
> leads to fragility in the discovery code: providing rewiring at the 
> byte-code level would allow users great control and relieve the 
> commons-logging development team of the burden of creating every more 
> complex discovery code.

And other teams... this *must* be addressed independently from Logging.

> - robert
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Curt Arnold]

Sorry to come in on this late.  I just read the archives after Ceki  
posted a link on log4j-dev.

First, I agree Enterprise is a poor name.  I tend to think in terms of  
diagnostic versus administrative logging.  Diagnostic logging intended  
to diagnose an issue where log requests are generally discarded (unless  
actively researching a problem) and fluency with internal program  
structure and with the human language used in the implementation is  
assumed.  Logger names based on class names would be appropriate here  
since the audience is likely familiar with the code base.

Administrative logging (in lack of a better term, but at least it is  
better than Enterprise) are messages intended for a difference audience  
where knowledge of internal program structure and the human language of  
the implementation is not given.  These difference audiences have  
resulted in different API on some platforms, for example, Windows has  
OutputDebugString (for diagnostic messages) and the Event log methods  
for administrative messages.  Logger names here would likely be  
business process related.

There are a couple of issues with the resource bundle proposals that I  
have seen previously.  I haven't had time to review those presented  
here so they may or may not apply.

Resource bundle approaches are sufficiently demanding of developers  
that they will likely substantially reduce the density of diagnostic  
messages if only a resource bundle approach is available.

Using the locale settings of the user or system is likely inappropriate  
for diagnostic messages.  A diagnostician reviewing log files or  
receiving networked log messages should not be forced to read log  
messages in the user's native language.  A worse case scenario would be  
a internationalized web site log where the language in the log file was  
constantly changing.

A log request may need to be rendered for more than one locale.  For  
example, a log request may result in email messages send to multiple  
recipients each in an appropriate language.

A diagnostic log may be transmitted to a location where the resource  
bundles are not available.  If it still is resource based at that  
point, you would require a specialized reader which would need to be  
kept in sync as new messages were added.

Discarded diagnostic messages need to be very low cost.  Administrative  
messages are vastly less frequent, are rarely discarded and can be  
fairly expensive.

An approach that I've found to work fairly well without requiring API  
modifications is the use of a localizing layout.
http://www.mail-archive.com/log4j-user@logging.apache.org/ 
msg00479.html) describe the use of such a layout in a project using  
log4net.  If you were careful on how you constructed your messages (for  
example, start with fixed content instead of variable content, did not  
allow your conversions to be affected by the default locale), you could  
create a fairly efficient localization mechanism by having a layout  
that would match the "generic" message and transform it into an  
appropriate localized content based on an external document containing  
regex patterns and substitutions.

Some of advantages of this approach: no API change is necessary,  
diagnostic messages are still trivial to add and fast to process, each  
appender may have a different locale, localization has no cost for  
discarded messages, generic language (typically english) messages are  
available for messages that have not been translated (and likely most  
diagnostic messages would not be), does not require customized readers.

The primary disadvantage is that is it not straightforward to ensure  
that all the messages of concern have translations and that messages  
that are to be localized should be designed so that they are easily  
matched and parsed.

FYI: log4cxx does have a resource bundle logging API, but I have no  
experience with it.


 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 16 Dec 2004, at 00:23, Simon Kitching wrote:
On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004

...byte-code engineering contradict each other. One of the really,
really strong things of c-l is, that it needs no additional jars. 
Just
drop commons-logging in, develop your app, deploy with the app,
commons-logging and a logger implementation, off you go.
This is a strong point from a "lazy" point of view [no offense, 
please].
But it's also one if it's greatest weaknesses.  You have no way of 
knowing
which logger impl. you are going to be using.  Yes, you can 
configure. No,
there is no assurance that what you configured will be used...   you 
can
check it once, but when you start deploying your applications in
production, you have to re-check.. and re-check... and you never know 
when
someone's going to change the classpath and change the behavior.  
It's a
nightmare.
I think this demonstrates a major issue.
When using logging in an "enterprise" situation, the logging can be
considered a critical part of the application. If you have heavy-duty
monitoring systems watching for alerts from the software, and have
sysadmins on call 24x7 to deal with issues, then for an application to
fail to locate the correct logging libs or config files is a *failure*
of the app. You don't want an app to start up, but then not be able to
generate alerts if problems occur.
But when using logging in other situations, logging is *not* a critical
part, and should not cause an application to fail to start.
The latter is the focus of commons-logging at the moment. And
unfortunately as commons-logging has no *mandatory* configuration, it 
is
not possible to add a "fail-on-no-config" option!
+1
it seems to me that there are actually two separate levels of 
configuration: one for the total application environment and one for 
components within that environment.

after a long time trying to work out how to satisfy everyone, i now 
think that discovery processes can only work within a particular 
application domain. for example, the current discovery process works 
well on tomcat, less well on jboss, badly in applets and not at all for 
J2ME. i believe that it would be possible to create satisfactory 
discovery systems for limited domains but it would not be possible to 
use an uber-discovery process to guess the environment.

the weakness in current design seems to be the bootstrap process. a 
discovery process most suitable for only one domain is part of the code 
that components compile against.

the solution i've been considering is to separate the base 
application-environmental configuration from the sophisticated 
discovery process required to ensure proper isolation in complex 
managed server environments. (i'm not going to describe this in detail 
right now: i should post a code example but i'm tired so that'll have 
to wait.)

where does byte-code engineering come in? well, there are certain 
things that users want that are just not going to be feasible no matter 
how sophisticated a discovery process is employed. too much complexity 
leads to fragility in the discovery code: providing rewiring at the 
byte-code level would allow users great control and relieve the 
commons-logging development team of the burden of creating every more 
complex discovery code.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 15 Dec 2004, at 20:10, Richard Sitze wrote:
Glad you made it Robert, was starting to feel that this was getting
snubbed by the core logging advocates ;-)!
good to hear from you again as well :)
BTW i'm not sure i'd describe myself as an advocate: commons-logging 
usually seems more like trench warfare ;)

(i don't seem to have been able to find too many cycles for apache 
recently - it's the traditional british Christmas: cold/flu, rushing 
around to see old friends and long, dark, wet and windy ale-filled 
nights -  so you'll have to forgive me if i get a little behind this 
thread.)

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 15 Dec 2004, at 20:10, Richard Sitze wrote:
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/15/2004 01:39:57 PM:
On 10 Dec 2004, at 01:42, Charles Daniels wrote:
8<
8<
Regardless of the performance, though, there is still the matter of
exactly where the messagekey+params gets converted to a
message string.
Having a user-provided Message object do it delegates the
responsibility
of locating the i18n resource bundle to the logging app, which may 
or
may not be appropriate. Having an underlying log adapter
class do it (a
kind of "i18n decorator" pattern?) raises the issue of how it would
locate the bundle. Log adaptor classes don't currently deal with
configuration in any way AFAIK; they just pass the message down.
Yes, I agree, the trick then becomes locating the resource bundle.
Perhaps one way to do this is to have the Message class locate it
based
upon a property in commons-logging.properties.  The Message.toString
method would then lookup the  resource and construct the message. 
This
way, neither the application nor the Log implementation would have to
deal with it.
i really think that this needs to be done through pluggable adapters
(since there isn't going to be any one correct solution).
in addition, i've come to the conclusion (after tussling with some
thorny i18n and customization problems elsewhere) that the formatting
conventionally available for parameterization rendering (stuff like
MessageFormat) just isn't good enough and a proper bean query language
is really needed. i've always wanted to mix resources and JEXL but
(as usual) i haven't found the cycles...
Ok.. this requires some thought here.  All that sounds good, but is 
out of
focus.

1.  Remember that our goal is to pass resourceBundleName and keyID's
straight through to underlying loggers that support I18N.  For those 
that
do NOT support, we want minimal help.

providing underlying layers that could (if they wished) provide better 
support pretty much addresses my concern.

2.  Recall that we are enabling LOGGING for COMPONENTS.  This is
substantially different, and can be [arguably should be] separated from
any I18N for other output related to the component development 
[including
GUI's, text output for console or printer user I/O].

3.  It is NOT our goal to develop a flexible, pluggable, etc.  I18N
framework for logging.
4.  It is my hope and belief that we can fall back to a lowest common
denominator that is "sufficient" for logging in *component* 
development.
+1
those goals seem reasonable (and probably achievable).
i'm not sure that lowest common denominator is the right description: a 
minimal sufficient implementation sounds better to me. in other words, 
rather than starting with what's provided in other frameworks, we start 
from nothing and add only what's necessary. once a sufficient 
implementation has been provided, development stops.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[David Graham]

--- Richard Sitze <[EMAIL PROTECTED]> wrote:

> David Graham <[EMAIL PROTECTED]> wrote on 12/16/2004 11:47:46
> AM:
> 
>  
> 
> > > 
> > > The current proposal is:
> > > 
> > > - configuration is always manditory.
> > 
> > Doesn't mandatory configuration relieve us from needing to split
> > commons-logging.jar into several pieces?  I like the fact that I don't
> > have to manage multiple commons-logging jar files and will be rather
> > dissapointed if that is required in the future.  I wouldn't mind
> having 
> a
> > simple properties file or a system property like
> > -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to 
> use
> > log4j.
> 
> ok, without going back to review exactly what I said in an earlier note,
> I 
> had in mind something like:
> 
>   commons-logging-core.jar   - core interface & factory class, NO config
>   commons-logging.jar- core + all helpers, NO config
>   commons-logging-.jar - core + ONE helper, ONE config
> 
> With this scheme, I believe we can scrub the code from LogFactory that 
> looks for an attempts to load specific logger impls [Log4J, Avalon, ?], 
> and instead depend entirely on the config.

So the configuration file is inside each impl. jar?  What are you
picturing the configuration will look like?  I figured it would just be a
simple declaration that you're using Log4J, java.util.logging, etc.  If it
is indeed that simple then I don't understand why we would need separate
jars.  We could keep the single commons-logging.jar but just use the
application supplied configuration instead of relying on the LogFactory
lookup code.

David



__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

Richard Sitze <[EMAIL PROTECTED]> writes:

>Just for the record, the primary issue is NOT inability to locate a 
>logger.  It's not finding the "expected" logger [from the developer/users 
>perspective], and silently falling back to an "alternate" logger.

Yep. I fully agree with you here.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[David Graham]

--- Richard Sitze <[EMAIL PROTECTED]> wrote:

> Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 10:18:44
> 
> PM:
> 
> > On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> > > Simon Kitching wrote:
> > > > I think this demonstrates a major issue.
> > > > 
> > > > When using logging in an "enterprise" situation, the logging can
> be
> > > > considered a critical part of the application. If you have 
> heavy-duty
> > > > monitoring systems watching for alerts from the software, and have
> > > > sysadmins on call 24x7 to deal with issues, then for an
> application 
> to
> > > > fail to locate the correct logging libs or config files is a 
> *failure*
> > > > of the app. You don't want an app to start up, but then not be
> able 
> to
> > > > generate alerts if problems occur.
> > > > 
> > > > But when using logging in other situations, logging is *not* a 
> critical
> > > > part, and should not cause an application to fail to start.
> > > > 
> > > > The latter is the focus of commons-logging at the moment. And
> > > > unfortunately as commons-logging has no *mandatory* configuration,
> 
> it is
> > > > not possible to add a "fail-on-no-config" option!
> > > > 
> > > > So perhaps we could build two separate jars from mostly-common 
> source
> > > > code? Deploying the traditional commons-logging jar would do the
> "be
> > > > quiet on no config", while the "enterprise" commons-logging jar 
> would do
> > > > something like "write message to STDERR then throw a runtime 
> exception
> > > > on no config"?
> > > 
> > > Why not just introduce a boolean parameter that says whether or not
> an 
> 
> > > inability to log is a failure?  e.g.
> > > 
> > > Log log = LogFactory.getLog(MyClass.class, true);
> > 
> > It's not "inability to log" as such. It's whether finding no specific
> > config info or underlying log implementation and therefore falling
> back
> > to using java.util.logging (java>=1.4) or
> > org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
> > 
> > In many cases, what you *want* an app to do if it can't find any
> > specific logging config is simply to output ERROR and FATAL messages
> to
> > stderr. This is what commons-logging will currently do if its
> > "discovery" process finds nothing.
> > 
> > I guess commons-logging *could* use a parameter such as you suggest to
> > indicate "explicit configuration of logging is mandatory". This would
> > presumably mean detecting whether commons-logging.properties or the
> > corresponding system properties have defined an explicit log
> > implementation and config file for that implementation.
> > 
> > I'm not sure, however, if the decision on whether logging is mandatory
> > or not should be a compile-time one. It seems to me to be more like
> > something the application *deployer* should choose. That then leads us
> > to a circular reference: how do we know whether configuration is
> > mandatory or not, if we can't find any configuration?
> 
> The current proposal is:
> 
> - configuration is always manditory.

Doesn't mandatory configuration relieve us from needing to split
commons-logging.jar into several pieces?  I like the fact that I don't
have to manage multiple commons-logging jar files and will be rather
dissapointed if that is required in the future.  I wouldn't mind having a
simple properties file or a system property like
-Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use
log4j.

David

> 
> - ambiguous [multiple] configurations located by a particular
> ClassLoader 
> in the hierarchy requires an "error" to be logged [where is a reasonable
> 
> question to ask].  How we determine which configs belong to which 
> ClassLoaders is described in the original proposal.
> 
> - in a "core" JCL jar, a configuration *must not* be packaged with JCL.
> 
> - in a "helper" JCL jar, a configuration *must* be packaged, along with 
> *one* JCL logger wrapper class.
> 
> - multiple "helper" JCL jar files, one per logging impl wrapper we 
> support.  Pick the logger impl you want, grab the corresponding "helper"
> 
> JCL jar file, and drop it into your application.
> 
> 
> > 
> > Regards,
> > 
> > Simon
> > 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

David Graham <[EMAIL PROTECTED]> wrote on 12/16/2004 11:47:46 AM:

 

> > 
> > The current proposal is:
> > 
> > - configuration is always manditory.
> 
> Doesn't mandatory configuration relieve us from needing to split
> commons-logging.jar into several pieces?  I like the fact that I don't
> have to manage multiple commons-logging jar files and will be rather
> dissapointed if that is required in the future.  I wouldn't mind having 
a
> simple properties file or a system property like
> -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to 
use
> log4j.

ok, without going back to review exactly what I said in an earlier note, I 
had in mind something like:

  commons-logging-core.jar   - core interface & factory class, NO config
  commons-logging.jar- core + all helpers, NO config
  commons-logging-.jar - core + ONE helper, ONE config

With this scheme, I believe we can scrub the code from LogFactory that 
looks for an attempts to load specific logger impls [Log4J, Avalon, ?], 
and instead depend entirely on the config.

> 
> David
> 
> > 
> > - ambiguous [multiple] configurations located by a particular
> > ClassLoader 
> > in the hierarchy requires an "error" to be logged [where is a 
reasonable
> > 
> > question to ask].  How we determine which configs belong to which 
> > ClassLoaders is described in the original proposal.
> > 
> > - in a "core" JCL jar, a configuration *must not* be packaged with 
JCL.
> > 
> > - in a "helper" JCL jar, a configuration *must* be packaged, along 
with 
> > *one* JCL logger wrapper class.
> > 
> > - multiple "helper" JCL jar files, one per logging impl wrapper we 
> > support.  Pick the logger impl you want, grab the corresponding 
"helper"
> > 
> > JCL jar file, and drop it into your application.
> > 
> > 

 


***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 10:18:44 
PM:

> On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> > Simon Kitching wrote:
> > > I think this demonstrates a major issue.
> > > 
> > > When using logging in an "enterprise" situation, the logging can be
> > > considered a critical part of the application. If you have 
heavy-duty
> > > monitoring systems watching for alerts from the software, and have
> > > sysadmins on call 24x7 to deal with issues, then for an application 
to
> > > fail to locate the correct logging libs or config files is a 
*failure*
> > > of the app. You don't want an app to start up, but then not be able 
to
> > > generate alerts if problems occur.
> > > 
> > > But when using logging in other situations, logging is *not* a 
critical
> > > part, and should not cause an application to fail to start.
> > > 
> > > The latter is the focus of commons-logging at the moment. And
> > > unfortunately as commons-logging has no *mandatory* configuration, 
it is
> > > not possible to add a "fail-on-no-config" option!
> > > 
> > > So perhaps we could build two separate jars from mostly-common 
source
> > > code? Deploying the traditional commons-logging jar would do the "be
> > > quiet on no config", while the "enterprise" commons-logging jar 
would do
> > > something like "write message to STDERR then throw a runtime 
exception
> > > on no config"?
> > 
> > Why not just introduce a boolean parameter that says whether or not an 

> > inability to log is a failure?  e.g.
> > 
> > Log log = LogFactory.getLog(MyClass.class, true);
> 
> It's not "inability to log" as such. It's whether finding no specific
> config info or underlying log implementation and therefore falling back
> to using java.util.logging (java>=1.4) or
> org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
> 
> In many cases, what you *want* an app to do if it can't find any
> specific logging config is simply to output ERROR and FATAL messages to
> stderr. This is what commons-logging will currently do if its
> "discovery" process finds nothing.
> 
> I guess commons-logging *could* use a parameter such as you suggest to
> indicate "explicit configuration of logging is mandatory". This would
> presumably mean detecting whether commons-logging.properties or the
> corresponding system properties have defined an explicit log
> implementation and config file for that implementation.
> 
> I'm not sure, however, if the decision on whether logging is mandatory
> or not should be a compile-time one. It seems to me to be more like
> something the application *deployer* should choose. That then leads us
> to a circular reference: how do we know whether configuration is
> mandatory or not, if we can't find any configuration?

The current proposal is:

- configuration is always manditory.

- ambiguous [multiple] configurations located by a particular ClassLoader 
in the hierarchy requires an "error" to be logged [where is a reasonable 
question to ask].  How we determine which configs belong to which 
ClassLoaders is described in the original proposal.

- in a "core" JCL jar, a configuration *must not* be packaged with JCL.

- in a "helper" JCL jar, a configuration *must* be packaged, along with 
*one* JCL logger wrapper class.

- multiple "helper" JCL jar files, one per logging impl wrapper we 
support.  Pick the logger impl you want, grab the corresponding "helper" 
JCL jar file, and drop it into your application.


> 
> Regards,
> 
> Simon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Just for the record, the primary issue is NOT inability to locate a 
logger.  It's not finding the "expected" logger [from the developer/users 
perspective], and silently falling back to an "alternate" logger.


***
Richard A. Sitze
IBM WebSphere WebServices Development

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 10:18:44 
PM:

> On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> > Simon Kitching wrote:
> > > I think this demonstrates a major issue.
> > > 
> > > When using logging in an "enterprise" situation, the logging can be
> > > considered a critical part of the application. If you have 
heavy-duty
> > > monitoring systems watching for alerts from the software, and have
> > > sysadmins on call 24x7 to deal with issues, then for an application 
to
> > > fail to locate the correct logging libs or config files is a 
*failure*
> > > of the app. You don't want an app to start up, but then not be able 
to
> > > generate alerts if problems occur.
> > > 
> > > But when using logging in other situations, logging is *not* a 
critical
> > > part, and should not cause an application to fail to start.
> > > 
> > > The latter is the focus of commons-logging at the moment. And
> > > unfortunately as commons-logging has no *mandatory* configuration, 
it is
> > > not possible to add a "fail-on-no-config" option!
> > > 
> > > So perhaps we could build two separate jars from mostly-common 
source
> > > code? Deploying the traditional commons-logging jar would do the "be
> > > quiet on no config", while the "enterprise" commons-logging jar 
would do
> > > something like "write message to STDERR then throw a runtime 
exception
> > > on no config"?
> > 
> > Why not just introduce a boolean parameter that says whether or not an 

> > inability to log is a failure?  e.g.
> > 
> > Log log = LogFactory.getLog(MyClass.class, true);
> 
> It's not "inability to log" as such. It's whether finding no specific
> config info or underlying log implementation and therefore falling back
> to using java.util.logging (java>=1.4) or
> org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
> 
> In many cases, what you *want* an app to do if it can't find any
> specific logging config is simply to output ERROR and FATAL messages to
> stderr. This is what commons-logging will currently do if its
> "discovery" process finds nothing.
> 
> I guess commons-logging *could* use a parameter such as you suggest to
> indicate "explicit configuration of logging is mandatory". This would
> presumably mean detecting whether commons-logging.properties or the
> corresponding system properties have defined an explicit log
> implementation and config file for that implementation.
> 
> I'm not sure, however, if the decision on whether logging is mandatory
> or not should be a compile-time one. It seems to me to be more like
> something the application *deployer* should choose. That then leads us
> to a circular reference: how do we know whether configuration is
> mandatory or not, if we can't find any configuration?
> 
> Regards,
> 
> Simon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

***
Richard A. Sitze
IBM WebSphere WebServices Development

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 06:23:35 
PM:

> On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
> > "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004 
> 
> > > ...byte-code engineering contradict each other. One of the really,
> > > really strong things of c-l is, that it needs no additional jars. 
Just
> > > drop commons-logging in, develop your app, deploy with the app,
> > > commons-logging and a logger implementation, off you go.
> > 
> > This is a strong point from a "lazy" point of view [no offense, 
please]. 
> > But it's also one if it's greatest weaknesses.  You have no way of 
knowing 
> > which logger impl. you are going to be using.  Yes, you can configure. 
No, 
> > there is no assurance that what you configured will be used...   you 
can 
> > check it once, but when you start deploying your applications in 
> > production, you have to re-check.. and re-check... and you never know 
when 
> > someone's going to change the classpath and change the behavior.  It's 
a 
> > nightmare.
> 
> I think this demonstrates a major issue.
> 
> When using logging in an "enterprise" situation, the logging can be
> considered a critical part of the application. If you have heavy-duty
> monitoring systems watching for alerts from the software, and have
> sysadmins on call 24x7 to deal with issues, then for an application to
> fail to locate the correct logging libs or config files is a *failure*
> of the app. You don't want an app to start up, but then not be able to
> generate alerts if problems occur.
> 
> But when using logging in other situations, logging is *not* a critical
> part, and should not cause an application to fail to start.
> 
> The latter is the focus of commons-logging at the moment. And
> unfortunately as commons-logging has no *mandatory* configuration, it is
> not possible to add a "fail-on-no-config" option!

I do not advocate a fail-on-no-config or fail-on-ambiguous-config.

I advocate a *warn* or *error* on either, using the simple default logger. 
 The warning will be visible on the console, which suffices for my 
immediate concerns.  How that warning/error (in general) is managed is up 
to the application environment.


> So perhaps we could build two separate jars from mostly-common source
> code? Deploying the traditional commons-logging jar would do the "be
> quiet on no config", while the "enterprise" commons-logging jar would do
> something like "write message to STDERR then throw a runtime exception
> on no config"?
> 
> > Yes, I want to maintain the "easy" route as much as possible, but it's 

> > time we adopt proven best practices from the industry and stop falling 
all 
> > over ourselves to keep a few programmers happy.  It's easier to figure 
out 
> > what your problem is if you missed one of two required jar files, than 
it 
> > is to debug the current situation.  Strategies have been discussed in 
more 
> > detail on other threads, so I'm not going to go in this any further 
here.
> 
> I think this depends on what your application's goal is. You seem to be
> thinking *only* of commons-logging from a J2EE point of view. Writers of
> stand-alone apps often want exactly the behaviour that commons-logging
> currently gives, and would be very against commons-logging terminating
> apps unless config is found.

The environments in question are not [necessarily] related to J2EE.  The 
particular issues should be generalized to more complex classloader 
hierarchies... which is something JCL explicitly attempts to support.


> I hope that my suggestion above (two commons-logging variants built from
> a common source tree) provides a way to address both goals without
> having to create a separate fork for "enterprise" logging.
> 
> > 
> > > I'd very much like to keep that, which means that any bytecode
> > > manipulation code should be part of the commons-logging jar. I'd 
like
> > > to avoid getting dependent on things like BCEL.
> > 
> > I'm cool with any byte-code manip as an ant task, for those who want 
to 
> > pull those dependencies into their environment.  But JCL should not 
start 
> > down this path [redundant with other projects, just like it's 
discovery is 
> > redundant with Jakarta Commons Discovery... admittedly JCL came 
first].
> > 
> > So I'll repeat an earlier request: anyone want to submit the correct 
> > AspectJ [and other's are of course welcome] declarations to perform 
this 
> > type of work?  Even if it's a few lines in the User's Guide. 
> 
> I notice that just4log (just4log.sourceforge.net) supports automatically
> adding entry/exit logging at compile-time. 
> 
> Regards,
> 
> Simon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


--

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

On 2004-12-16 8:29:31, "Henning P. Schmiedehausen" wrote:
> [1] If we went down the path that Ceki has for years lobbied for,
> today it would be "tomcat ships with log4j 1.2.x and your app requires
> log4j 1.3.x,, leading to all kinds of interesting classloader issues
> and general nightmarish behaviour." today... :-)
For logging within an app server like Tomcat, the log4j team
recommends the installation of a single copy of log4j.jar in
TOMCAT_HOME/common/lib/. This log4j.jar file will be loaded only once
in memory, shared by the application server *and* all applications
desiring to use log4j for their logging, with the separation of
logging contexts ensured by a repository selector [1, 2, 3] based on
JNDI. Applications desiring to use a different logging API remain
unaffected.
Given that log4j versions change quite slowly with almost few rare
backward compatibility problems, one could imagine that an application
server, say WildCat, could easily move to the latest official version
of log4j without significant trouble.
Now, in the possible but relatively infrequent event where the
customer's application using log4j version 'k' is deployed on an older
version of WildCat dependent on log4j version k, with k < n, the
customer has several options. First, it should be possible to just
drop and replace log4j version n with version k at the level of
WILDCAT_HOME/common/lib. If that is not possible, then the customer
can bundle log4j version n within the application's war file. Note
that the latter solution is more or less where we stand today.
I guess that's enough talk about log4j on this forum.
[1] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5
[2] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/
[3] http://www.qos.ch/logging/sc.jsp
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Rory Winston]

All, Sorry for sidetracking, this is for Ceki

Ceki, when do you plan to release 1.3.0? I've been following the development 
with some interest for a whiledo you have any idea when 1.3.0 will be ready 
for release?

"Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote:

> 
> 
> Hello Henning,
> 
> Robert Burrell Donkin kindly informed of the existence of your
> discussion.
> 
> Henning, since you mentioned me by name in your last message, allow me
> to respond. If my memory serves me correctly, I have only once
> proposed Tomcat to bundle log4j. It was quite a few years ago. Since
> then, I have been careful to stay away from that topic.
> 
> Being out of the limelight actually helped us to develop log4j without
> all the pressure associated with excessive public attention. So it
> would be nice to have Tomcat officially adopt log4j, but maybe not
> just yet.
> 
> Best regards,
> 
> On 2004-12-16 8:29:31, "Henning P. Schmiedehausen" wrote:
> 
>  > Hm. This does not feel right to me. IMHO this will lead to the
>  > situation that some developers (most notably the log4j guys; Hi Ceki!
>  > [1]) condemn. Your web app container (let's say tomcat) ships with the
>  > "missing config is ok" jar version in its class path and your
>  > application is deployed with the "missing config is bad"
>  > version. Leading to all kinds of interesting classloader issues and
>  > general nightmarish behaviour.
>  >
>  > Regards
>  > Henning
>  >
>  > [1] If we went down the path that Ceki has for years lobbied for,
>  > today it would be "tomcat ships with log4j 1.2.x and your app requires
>  > log4j 1.3.x,, leading to all kinds of interesting classloader issues
>  > and general nightmarish behaviour." today... :-)
> 
> 
> --=20
> Ceki G=FClc=FC
> 
>The complete log4j manual: http://qos.ch/log4j/
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

Hello Henning,
Robert Burrell Donkin kindly informed of the existence of your
discussion.
Henning, since you mentioned me by name in your last message, allow me
to respond. If my memory serves me correctly, I have only once
proposed Tomcat to bundle log4j. It was quite a few years ago. Since
then, I have been careful to stay away from that topic.
Being out of the limelight actually helped us to develop log4j without
all the pressure associated with excessive public attention. So it
would be nice to have Tomcat officially adopt log4j, but maybe not
just yet.
Best regards,
On 2004-12-16 8:29:31, "Henning P. Schmiedehausen" wrote:
> Hm. This does not feel right to me. IMHO this will lead to the
> situation that some developers (most notably the log4j guys; Hi Ceki!
> [1]) condemn. Your web app container (let's say tomcat) ships with the
> "missing config is ok" jar version in its class path and your
> application is deployed with the "missing config is bad"
> version. Leading to all kinds of interesting classloader issues and
> general nightmarish behaviour.
>
> Regards
> Henning
>
> [1] If we went down the path that Ceki has for years lobbied for,
> today it would be "tomcat ships with log4j 1.2.x and your app requires
> log4j 1.3.x,, leading to all kinds of interesting classloader issues
> and general nightmarish behaviour." today... :-)
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

Richard Sitze <[EMAIL PROTECTED]> writes:

>This is a strong point from a "lazy" point of view [no offense, please]. 
>But it's also one if it's greatest weaknesses.  You have no way of knowing 
>which logger impl. you are going to be using.  Yes, you can configure. No, 
>there is no assurance that what you configured will be used...   you can 
>check it once, but when you start deploying your applications in 
>production, you have to re-check.. and re-check... and you never know when 
>someone's going to change the classpath and change the behavior.  It's a 
>nightmare.

Making sure that you always hand out the right logging implementatin
is the job of your application / your container. It should use
e.g. log4j as its enterprise logger and allow components, that are 3rd
party or independently written from your application and want to use
JCL to use these and wire their logging output into your enterprise
logging.

An example here. Turbine optionally configures log4j and offers it to
its components and applications as "its enterprise logger". It also
uses a commons-logging.properties file (which is part of the META
environment and distributed with every turbine application unless the
developer changes it explicitly), to wire JCL onto log4j.

The Turbine core itself uses _only_ JCL and we do encourage our users
whenever they write a new service or component to do the same. So you
can "plug" a Turbine application into your enterprise container and
simply rewire all of its logging using commons-logging.properties
(which then should point at your enterprise logging facility).

Your app would be responsible to offer the JCL implementation
(which boils down to what? One class (factory) and one Log interface
implementation) to its components. When they ask for

"Log log = LogFactory.getLog()", the app is ultimately
responsible that they get a logger which is then integrated with your
enterprise logging. If this fails, this IMHO is an application
failure, not a JCL failure.

The enterprise logging scope (I will keep the L10N and I18N issues out
here) for JCL is IMHO the same scope as for the "regular"
component. If you run a smallish program (or build a component), an
unconfigured JCL will output to stderr. Which works well.

If you run in an enterprise environment, you must make sure, that this
enterprise environment returns the right configuration to the
LogFactory so that it returns your implementation.

The current lookup process is IMHO too fragile because it depends on
jars in the classpath. Using bytecode engineering has its merits
(because it would allow your enterprise application to simply "rewire"
the Factory implementation lookup process to return your enterprise
logger).

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

Simon Kitching <[EMAIL PROTECTED]> writes:

>So perhaps we could build two separate jars from mostly-common source
>code? Deploying the traditional commons-logging jar would do the "be
>quiet on no config", while the "enterprise" commons-logging jar would do
>something like "write message to STDERR then throw a runtime exception
>on no config"?

Hm. This does not feel right to me. IMHO this will lead to the
situation that some developers (most notably the log4j guys; Hi Ceki!
[1]) condemn. Your web app container (let's say tomcat) ships with the
"missing config is ok" jar version in its class path and your
application is deployed with the "missing config is bad"
version. Leading to all kinds of interesting classloader issues and
general nightmarish behaviour.

Regards
Henning

[1] If we went down the path that Ceki has for years lobbied for,
today it would be "tomcat ships with log4j 1.2.x and your app requires
log4j 1.3.x,, leading to all kinds of interesting classloader issues
and general nightmarish behaviour." today... :-)

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Response below...
Simon Kitching wrote:
On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
Simon Kitching wrote:
I think this demonstrates a major issue.
When using logging in an "enterprise" situation, the logging can be
considered a critical part of the application. If you have heavy-duty
monitoring systems watching for alerts from the software, and have
sysadmins on call 24x7 to deal with issues, then for an application to
fail to locate the correct logging libs or config files is a *failure*
of the app. You don't want an app to start up, but then not be able to
generate alerts if problems occur.
But when using logging in other situations, logging is *not* a critical
part, and should not cause an application to fail to start.
The latter is the focus of commons-logging at the moment. And
unfortunately as commons-logging has no *mandatory* configuration, it is
not possible to add a "fail-on-no-config" option!
So perhaps we could build two separate jars from mostly-common source
code? Deploying the traditional commons-logging jar would do the "be
quiet on no config", while the "enterprise" commons-logging jar would do
something like "write message to STDERR then throw a runtime exception
on no config"?
Why not just introduce a boolean parameter that says whether or not an 
inability to log is a failure?  e.g.

Log log = LogFactory.getLog(MyClass.class, true);

It's not "inability to log" as such. It's whether finding no specific
config info or underlying log implementation and therefore falling back
to using java.util.logging (java>=1.4) or
org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
 
In many cases, what you *want* an app to do if it can't find any
specific logging config is simply to output ERROR and FATAL messages to
stderr. This is what commons-logging will currently do if its
"discovery" process finds nothing.

I guess commons-logging *could* use a parameter such as you suggest to
indicate "explicit configuration of logging is mandatory". This would
presumably mean detecting whether commons-logging.properties or the
corresponding system properties have defined an explicit log
implementation and config file for that implementation.
I'm not sure, however, if the decision on whether logging is mandatory
or not should be a compile-time one. It seems to me to be more like
something the application *deployer* should choose. That then leads us
to a circular reference: how do we know whether configuration is
mandatory or not, if we can't find any configuration?
Ah-hah, I see what you're getting at.
I have an idea... All logging implementations for Java configure logging 
by package, right?  What if we allow component developers to include 
their own commons-logging.properties that's not at the root of the 
source tree?  For example, if Morph suddenly decided it was very 
important to have certain messages logged, I just drop a 
commons-logging.properties in net.sf.morph that specifies the logging 
settings for net.sf.morph and all subpackages (e.g. which log factory to 
use, whether my messages *must* be heard, etc).  If JCL detects such a 
file it ensure the component that the logging it specifies is happening. 
 If an application developer, assembler or deployer decides later that 
Morph really isn't as important as I'd like, then they just delete the 
commons-logging.properties or put their own version in the 
WEB-INF/classes directory.  (Forgive me if this is a great show of my 
ignorance of classloading, but I think this is at least how things work 
for Tomcat).

Searching for a file like this on the classpath would certainly have 
performance implications.  However, search cost is incurred only on 
startup and there is precedent (see below), so it can't be too bad. 
It's certainly worth a try.

http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html
Regards,
Simon
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Simon Kitching]

On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> Simon Kitching wrote:
> > I think this demonstrates a major issue.
> > 
> > When using logging in an "enterprise" situation, the logging can be
> > considered a critical part of the application. If you have heavy-duty
> > monitoring systems watching for alerts from the software, and have
> > sysadmins on call 24x7 to deal with issues, then for an application to
> > fail to locate the correct logging libs or config files is a *failure*
> > of the app. You don't want an app to start up, but then not be able to
> > generate alerts if problems occur.
> > 
> > But when using logging in other situations, logging is *not* a critical
> > part, and should not cause an application to fail to start.
> > 
> > The latter is the focus of commons-logging at the moment. And
> > unfortunately as commons-logging has no *mandatory* configuration, it is
> > not possible to add a "fail-on-no-config" option!
> > 
> > So perhaps we could build two separate jars from mostly-common source
> > code? Deploying the traditional commons-logging jar would do the "be
> > quiet on no config", while the "enterprise" commons-logging jar would do
> > something like "write message to STDERR then throw a runtime exception
> > on no config"?
> 
> Why not just introduce a boolean parameter that says whether or not an 
> inability to log is a failure?  e.g.
> 
> Log log = LogFactory.getLog(MyClass.class, true);

It's not "inability to log" as such. It's whether finding no specific
config info or underlying log implementation and therefore falling back
to using java.util.logging (java>=1.4) or
org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
 
In many cases, what you *want* an app to do if it can't find any
specific logging config is simply to output ERROR and FATAL messages to
stderr. This is what commons-logging will currently do if its
"discovery" process finds nothing.

I guess commons-logging *could* use a parameter such as you suggest to
indicate "explicit configuration of logging is mandatory". This would
presumably mean detecting whether commons-logging.properties or the
corresponding system properties have defined an explicit log
implementation and config file for that implementation.

I'm not sure, however, if the decision on whether logging is mandatory
or not should be a compile-time one. It seems to me to be more like
something the application *deployer* should choose. That then leads us
to a circular reference: how do we know whether configuration is
mandatory or not, if we can't find any configuration?

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Simon Kitching wrote:
I think this demonstrates a major issue.
When using logging in an "enterprise" situation, the logging can be
considered a critical part of the application. If you have heavy-duty
monitoring systems watching for alerts from the software, and have
sysadmins on call 24x7 to deal with issues, then for an application to
fail to locate the correct logging libs or config files is a *failure*
of the app. You don't want an app to start up, but then not be able to
generate alerts if problems occur.
But when using logging in other situations, logging is *not* a critical
part, and should not cause an application to fail to start.
The latter is the focus of commons-logging at the moment. And
unfortunately as commons-logging has no *mandatory* configuration, it is
not possible to add a "fail-on-no-config" option!
So perhaps we could build two separate jars from mostly-common source
code? Deploying the traditional commons-logging jar would do the "be
quiet on no config", while the "enterprise" commons-logging jar would do
something like "write message to STDERR then throw a runtime exception
on no config"?
Why not just introduce a boolean parameter that says whether or not an 
inability to log is a failure?  e.g.

Log log = LogFactory.getLog(MyClass.class, true);
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Simon Kitching]

On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
> "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004 

> > ...byte-code engineering contradict each other. One of the really,
> > really strong things of c-l is, that it needs no additional jars. Just
> > drop commons-logging in, develop your app, deploy with the app,
> > commons-logging and a logger implementation, off you go.
> 
> This is a strong point from a "lazy" point of view [no offense, please]. 
> But it's also one if it's greatest weaknesses.  You have no way of knowing 
> which logger impl. you are going to be using.  Yes, you can configure. No, 
> there is no assurance that what you configured will be used...   you can 
> check it once, but when you start deploying your applications in 
> production, you have to re-check.. and re-check... and you never know when 
> someone's going to change the classpath and change the behavior.  It's a 
> nightmare.

I think this demonstrates a major issue.

When using logging in an "enterprise" situation, the logging can be
considered a critical part of the application. If you have heavy-duty
monitoring systems watching for alerts from the software, and have
sysadmins on call 24x7 to deal with issues, then for an application to
fail to locate the correct logging libs or config files is a *failure*
of the app. You don't want an app to start up, but then not be able to
generate alerts if problems occur.

But when using logging in other situations, logging is *not* a critical
part, and should not cause an application to fail to start.

The latter is the focus of commons-logging at the moment. And
unfortunately as commons-logging has no *mandatory* configuration, it is
not possible to add a "fail-on-no-config" option!

So perhaps we could build two separate jars from mostly-common source
code? Deploying the traditional commons-logging jar would do the "be
quiet on no config", while the "enterprise" commons-logging jar would do
something like "write message to STDERR then throw a runtime exception
on no config"?

> Yes, I want to maintain the "easy" route as much as possible, but it's 
> time we adopt proven best practices from the industry and stop falling all 
> over ourselves to keep a few programmers happy.  It's easier to figure out 
> what your problem is if you missed one of two required jar files, than it 
> is to debug the current situation.  Strategies have been discussed in more 
> detail on other threads, so I'm not going to go in this any further here.

I think this depends on what your application's goal is. You seem to be
thinking *only* of commons-logging from a J2EE point of view. Writers of
stand-alone apps often want exactly the behaviour that commons-logging
currently gives, and would be very against commons-logging terminating
apps unless config is found.

I hope that my suggestion above (two commons-logging variants built from
a common source tree) provides a way to address both goals without
having to create a separate fork for "enterprise" logging.

> 
> > I'd very much like to keep that, which means that any bytecode
> > manipulation code should be part of the commons-logging jar. I'd like
> > to avoid getting dependent on things like BCEL.
> 
> I'm cool with any byte-code manip as an ant task, for those who want to 
> pull those dependencies into their environment.  But JCL should not start 
> down this path [redundant with other projects, just like it's discovery is 
> redundant with Jakarta Commons Discovery... admittedly JCL came first].
> 
> So I'll repeat an earlier request: anyone want to submit the correct 
> AspectJ [and other's are of course welcome] declarations to perform this 
> type of work?  Even if it's a few lines in the User's Guide. 

I notice that just4log (just4log.sourceforge.net) supports automatically
adding entry/exit logging at compile-time. 

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[robert burrell donkin]

On 15 Dec 2004, at 21:06, Henning P. Schmiedehausen wrote:
robert burrell donkin <[EMAIL PROTECTED]> writes:
the passivity is a symptom of commons logging being too big, too
complex and too tightly coupled to the needs of applications run in
containers and yet not sophisticated enough. IMO the commons logging
API could and should be reduced to one interface and one public class
each with no dependencies on anything about java 1.0.
IMHO the dependency on "java 1.0" and...
everything else, all the sophisticated configuration can be achieved 
by
byte-code engineering: doping the appropriate jars so that the calls
are wired correctly. there is certainly an amount of resistance to 
byte
code engineering from some quarters but after a long hard slog, i
really think that this is the only way that the initial aims of the
component can be achieved.
...byte-code engineering contradict each other. One of the really,
really strong things of c-l is, that it needs no additional jars. Just
drop commons-logging in, develop your app, deploy with the app,
commons-logging and a logger implementation, off you go.
I'd very much like to keep that, which means that any bytecode
manipulation code should be part of the commons-logging jar. I'd like
to avoid getting dependent on things like BCEL.
the beauty of this approach is that the actual API jar would ship only 
with a minimal, run anywhere implementation hard wired to system.err. 
code compiled against this API jar would have minimal dependencies. the 
byte code engineering would be used to rewire a jar using commons 
logging to use a particular discovery system but would ship as separate 
artifacts.

(the minimal java dependency stuff was really aimed at allowing those 
who want to use commons-logging in library-restricted environments to 
do it)

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004 
03:06:41 PM:

> robert burrell donkin <[EMAIL PROTECTED]> writes:
> 
> >the passivity is a symptom of commons logging being too big, too 
> >complex and too tightly coupled to the needs of applications run in 
> >containers and yet not sophisticated enough. IMO the commons logging 
> >API could and should be reduced to one interface and one public class 
> >each with no dependencies on anything about java 1.0.
> 
> IMHO the dependency on "java 1.0" and...
> 
> >everything else, all the sophisticated configuration can be achieved by 

> >byte-code engineering: doping the appropriate jars so that the calls 
> >are wired correctly. there is certainly an amount of resistance to byte 

> >code engineering from some quarters but after a long hard slog, i 
> >really think that this is the only way that the initial aims of the 
> >component can be achieved.
> 
> ...byte-code engineering contradict each other. One of the really,
> really strong things of c-l is, that it needs no additional jars. Just
> drop commons-logging in, develop your app, deploy with the app,
> commons-logging and a logger implementation, off you go.

This is a strong point from a "lazy" point of view [no offense, please]. 
But it's also one if it's greatest weaknesses.  You have no way of knowing 
which logger impl. you are going to be using.  Yes, you can configure. No, 
there is no assurance that what you configured will be used...   you can 
check it once, but when you start deploying your applications in 
production, you have to re-check.. and re-check... and you never know when 
someone's going to change the classpath and change the behavior.  It's a 
nightmare.

Yes, I want to maintain the "easy" route as much as possible, but it's 
time we adopt proven best practices from the industry and stop falling all 
over ourselves to keep a few programmers happy.  It's easier to figure out 
what your problem is if you missed one of two required jar files, than it 
is to debug the current situation.  Strategies have been discussed in more 
detail on other threads, so I'm not going to go in this any further here.

> I'd very much like to keep that, which means that any bytecode
> manipulation code should be part of the commons-logging jar. I'd like
> to avoid getting dependent on things like BCEL.

I'm cool with any byte-code manip as an ant task, for those who want to 
pull those dependencies into their environment.  But JCL should not start 
down this path [redundant with other projects, just like it's discovery is 
redundant with Jakarta Commons Discovery... admittedly JCL came first].

So I'll repeat an earlier request: anyone want to submit the correct 
AspectJ [and other's are of course welcome] declarations to perform this 
type of work?  Even if it's a few lines in the User's Guide. 

> 
>Regards
>   Henning
> 
> -- 
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
> [EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/
> 
> RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for 
hire
>Linux, Java, perl, Solaris -- Consulting, Training, Development
> 
> What is more important to you...
>[ ] Product Security
> or [ ] Quality of Sales and Marketing Support
>   -- actual question from a Microsoft customer survey
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

robert burrell donkin <[EMAIL PROTECTED]> writes:

>the passivity is a symptom of commons logging being too big, too 
>complex and too tightly coupled to the needs of applications run in 
>containers and yet not sophisticated enough. IMO the commons logging 
>API could and should be reduced to one interface and one public class 
>each with no dependencies on anything about java 1.0.

IMHO the dependency on "java 1.0" and...

>everything else, all the sophisticated configuration can be achieved by 
>byte-code engineering: doping the appropriate jars so that the calls 
>are wired correctly. there is certainly an amount of resistance to byte 
>code engineering from some quarters but after a long hard slog, i 
>really think that this is the only way that the initial aims of the 
>component can be achieved.

...byte-code engineering contradict each other. One of the really,
really strong things of c-l is, that it needs no additional jars. Just
drop commons-logging in, develop your app, deploy with the app,
commons-logging and a logger implementation, off you go.

I'd very much like to keep that, which means that any bytecode
manipulation code should be part of the commons-logging jar. I'd like
to avoid getting dependent on things like BCEL.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
12/15/2004 01:44:47 PM:

> On 11 Dec 2004, at 02:24, Noel J. Bergman wrote:
> 
> > It disturbs me that what seems to me to be a reasonable and small set 
> > of
> > requirements --- along with what appears to have been considerable
> > forethought based upon real world issues, and experiences supporting 
> > many
> > developers --- appears to be discounted a bit too out of hand.  I hope 

> > my
> > perception is wrong.
> >
> > Does anyone really dispute the requirement to support localization for 

> > log
> > messages or the additional JSR-mandated logging requirements?  If not, 

> > then
> > let's work constructively towards satisfying the requirements.  And 
> > not by
> > relying upon some IDE's tooling.
> 
> IMHO given the amount of grief that the commons-logging team (richard 
> included) has suffered over the years, i'm glad that we're actually 
> discussing the issues before launching code on unsuspecting millions. 
> i'd much rather that people speak up and voice their concerns now when 
> we can actually acknowledge them and (at the very least) document 
> reasons for rejecting.
> 
> we've been stuck for a number of years with a flawed API. with more 
> discussion, it might have been possible to fix them at the start. i'd 
> hope that we (as a community) have learnt from that (bitter) experience 
> and would be a little more willing to encourage a full and frank 
> discussion.

Absolutely.  This is exactly my intent, for those who raised 
concerns/issue with the dropping of a proposal "prior to opening 
discussions with the JCL community".  Yes, we did put a lot of thought 
into it.  Yes, I expected and desire a lot of discussion, and debate, with 
the JCL community.  Yes, I expect that there will be changes before we 
settle on the right direction for the next step.  And I wouldn't have it 
any other way: I want the community buy in before we move forward... but I 
also want this to move forward.

> 
> - robert
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]