[EMAIL PROTECTED]: Project commons-discovery (in module jakarta-commons) failed

[Richard Sitze]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-discovery has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-discovery :  Commons Discovery Package


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-discovery.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Circular Dependency with ant.
 -ERROR- Circular Dependency with xml-xerces.
 -ERROR- Circular Dependency with xml-apis.
 -ERROR- Circular Dependency with commons-logging.
 -DEBUG- Extracted fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-discovery/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-discovery/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 35331107062005, vmgump.apache.org:vmgump-public:35331107062005
Gump E-mail Identifier (unique within run) #7.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

[EMAIL PROTECTED]: Project commons-discovery (in module jakarta-commons) failed

[Richard Sitze]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-discovery has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-discovery :  Commons Discovery Package


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-discovery.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Circular Dependency with ant.
 -ERROR- Circular Dependency with xml-xerces.
 -ERROR- Circular Dependency with xml-apis.
 -ERROR- Circular Dependency with commons-logging.
 -DEBUG- Extracted fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-discovery/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-discovery/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 35331107062005, vmgump.apache.org:vmgump-public:35331107062005
Gump E-mail Identifier (unique within run) #7.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

Re: [VOTE] [logging] promote RC1 to alpha status

[Richard Sitze]

+1

***
Richard A. Sitze
IBM WebSphere WebServices Development

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
02/26/2005 01:41:05 PM:

> the release candidate has been available for a while now and i am not
> aware of any problems with it. the next stage in the release process
> will be to promote this release candidate to alpha release status. this
> involves moving the release to a new location with a new name and
> announcing the availability of this release to the public. 
> 
> this is a full release vote (and so three +1's are required). please
> check the release before voting +1. i will not tally the votes before
> 2300 hours GMT on tuesday 1st of march.
> 
> here's my +1
> 
> - robert
> 
> -8<-
> [ ] +1 Promote RC1 to commons-logging-1.0.5-alpha1
> [ ] +0 In favour of this release
> [ ] -0 Against this release
> [ ] -1 Do not release RC1
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: commons benchmark in sandbox.

[Richard Sitze]

With so many benchmark and profiling tools available that do not require 
instrumenting the code, what real benefit do you see this providing? 
Similarly, with AspectJ [or other alternatives], what are you providing 
that goes beyond what you might do in that space?



***
Richard A. Sitze
IBM WebSphere WebServices Development

"Kevin A. Burton" <[EMAIL PROTECTED]> wrote on 02/16/2005 01:27:24 
PM:

> Hey.
> 
> I just added a new project to the sandbox.  Its designed to provide 
> lightweight runtime benchmarking for Java code.  Think log4j for 
> benchmarking.
> 
> The code can be disabled at runtime with almost no performance hit.  Its 

> also very fast when enabled as well being able to product 1M benchmarks 
> per second with a modern CPU.
> 
> The goal is to provide universal and exported performance benchmarks 
> that can be enabled at runtime for the JVM.  It can also be used to 
> provide historical benchmarking.  Think perfmon for Java.  We actually 
> are using it to tie it into ganglia and rrdtool so that we can generate 
> graphs as the the performance of our application.
> 
> Right now its just a working proof of concept and needs a lot before it 
> can be shipped.  Better API design, XML configuration support, 
> documentation, etc.
> 
> Once (and if) its in Jakarta and out of the sandbox it could be used in 
> packages like FeedParser or Tomcat to export benchmarking statistics.
> 
> Kevin
> 
> -- 
> 
> Use Rojo (RSS/Atom aggregator).  Visit http://rojo.com. Ask me for an 
> invite!  Also see irc.freenode.net #rojo if you want to chat.
> 
> Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
> 
> If you're interested in RSS, Weblogs, Social Networking, etc... then you 

> should work for Rojo!  If you recommend someone and we hire them you'll 
> get a free iPod!
> 
> Kevin A. Burton, Location - San Francisco, CA
>AIM/YIM - sfburtonator,  Web - http://peerfear.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: [logging] discovery error handling

[Richard Sitze]

It means a fix will be made available as part of the next phase.


***
Richard A. Sitze
IBM WebSphere WebServices Development

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/14/2005 06:20:14 AM:

> At 05:59 PM 2/13/2005, robert burrell donkin wrote:
> 
> > > Anyway, before camouflaging errors occurring during
> > > Logger retrieval, I'd recommend that you fix the bug exposed by
> > > Example 2 in my analysis [1]. In my opinion it cannot be fixed 
without
> > > a major redesign and overhaul of JCL, but maybe I am wrong...
> >
> >this general issued was discussed earlier. i suspect that it would be
> >possible to improve the situation in JCL1 but richard's more sceptical
> >and seems keener to push straight towards JCL2. i think that there's
> >some danger that momentum is starting to slip away so i'm probably not
> >going to look at fix the issue in the 1.0.x stream right now.
> 
> Does this mean that JCL won't be fixed anytime soon? :-(
> 
> >- 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] discovery error handling

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
02/08/2005 04:25:57 PM:

> one of the drawbacks about JCL 1.0.x is the approach to handling errors
> in the configuration and discovery mechanism. JCL falls down and (in
> most commons use cases) takes the application with it. it also fails to
> provide useful diagnostic information.
> 
> i've been considering for a while adopting a system for error handling
> which allows a system property to be used to tune the exactly behaviour:
> classic more would throw runtimes (as per now), silent more would
> suppress all issues continuing to function as well as it is able and
> diagnostic would print diagnostic information to System.out. though not
> all environments would allow system properties to be set, i think that
> this would improve matters for many common use cases. 
> 
> opinions?

Yes :-), focus all efforts on improving discovery and diagnostics on 
commons-discovery, and let's abandon further efforts to improve JC 
logging/discovery, other than to regress back to "simple simple simple" 
behavior that doesn't break so easily [ala the UGLI discovery].

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

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] 1.0.5 release: plan update and bug review

[Richard Sitze]

Just for the record, might as well get this out now :-)

I'm going to take a fairly STRONG position against fixing discovery in a 
1.0.6 if that is the ONLY change going in.  Why?

- The "fix" I envision will necessitate "backwards incompatible" behavior 
in a "standalone" commons-logging.jar file.  This requires more than a 
point release.

- commons-logging 2.0 should default to a simple discovery process very 
much in line with the UGLI discovery [typical J2SE configuration], and 
give up all attempts for managing complicated ClassLoader hierarchy 
problems.

- commons-logging 2.0 should to defer to commons-discovery, if 
commons-discovery is available in an appropriate class-loader [and yes, 
this means "discovering" commons-discovery... headache time.. but we'll 
keep it simple anyway :-)  right?].

- I want to "fix" the ClassLoader problems in commons-discovery.

- Specifically, allow the commons-logging 2.0 + commons-discover X.Y to 
function well under J2EE and OSGI environs... or any other complicated 
ClassLoader environment.


Now, all that aside, someone is going to argue that we should "go ahead" 
and fix the ClassLoader problems in 1.0.6.  All well and good, but note 
that I want to *encourage* use of the new branch, and let the old branch 
rest piecefully [did I say die?  I didn't say die... did I?].  If you want 
a "sophisticated" discovery mechanism in complicated ClassLoader environs, 
then defer to the new "pluggable" discovery mechanism and be ready to work 
in OSGI, J2EE, or whereever.  If you don't need it, then what comes in 
commons-logging.jar will be sufficient for simple J2SE applications.



***
Richard A. Sitze
IBM WebSphere WebServices Development

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
02/07/2005 04:16:42 PM:

> back up and running now :)
> 
> i propose to take a branch for the 1.0.5 release as soon as the
> outstanding matters have been discussed. this will free up head for
> possible work either towards a 1.0.6 (with improved discovery) or a
> major revision.
> 
> brian contributed the required documentation (many thanks) so all that i
> have on my list now is to work out which bugs will be addressed for this
> release. here's the analysed consensus from the wiki (thanks to dennis
> for his review). please feel free to jump in and disagree if
> appropriate. 
> 
> in the event of no complaints, i propose to update bugzilla and take the
> 1.0.5 release branch some time after 2200GMT tomorrow (tuesday). anyone
> with a problem with this plan should jump in now... 
> 
> - robert
> 
> Open Bugs
> -
> 
> Bug 28291 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=28291
>  Classloader related, these issues will be addressed by later
> releases 
> 
> Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131
>  This is related to httpclient example code but Dennis posted a
> followup (with no response) and I've check the example code (which looks
> ok to me).
> 
> Bug 30268 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=30268
>  Needs architectural changes
> 
> Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632
>  See 30131
> 
> Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618
> The new proposal by IBM. 
> 
> Bug 32662 WONTFIX
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32662
> See
> 
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=110780577017737&w=2
> 
> Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691
> General heading of improvements to API. (Needs a champion.)
> 
> Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347
> API improvements. (Needs a champion.)
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: [logging] releasing log4j resources

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
02/07/2005 02:45:28 PM:

> certainly the web application deployer should know :)
> 
> IIRC it should be possible to tap into lifecycle events and perform the
> shutdown by creating a small amount of code external to the actual
> application. 
> 
> anyone object to me marking this one as WONTFIX?

+1 to mark as WONTFIX.

JCL *uses* a logger implementation, it shouldn't attempt to configure it 
or manage it.

Consider:

 Parent [commons-logging-api.jar, Log4j]
|
   +++
   | |
 ChildAChildB [uses Log,
   Log bound to Log4JLogger,
   Log4JLogger bound to LogFactoryImpl,
   LogFactoryImpl instance bound to ChildB]

When ChildB is disposed of, we currently do not have anyway of recognizing 
that the LogFactoryImpl using Log4J is being managed by Parent or ChildB. 
The ChildB classloader, or rather the LogFactoryImpl, should not attempt 
to manage this resource, as that may cause problems for both Parent and 
ChildA.


> 
> - robert
> 
> On Mon, 2005-02-07 at 20:02, Ceki Gülcü wrote:
> > Shouldn't this web-app which apparently knows it is using log4j call 
> > LogManger.shutdown() directly?
> > 
> > At 09:05 PM 2/7/2005, you wrote:
> > >http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 describes an
> > >issues that arises when restarting web apps in tomcat. JCL bridges to
> > >log4j which has a rolling file appender configured. the file appender
> > >doesn't roll when the application is restarted. the proposed solution 
is
> > >to add a call to LogManager.shutdown.
> > >
> > >i'm a little worried that calling shutdown may be inappropriate in 
this
> > >circumstance the JVM isn't closing, just a web application. before i
> > >take this question to the log4j lists, i wondered whether any log4j
> > >experts would be so kind as to either confirm my concerns or set my 
mind
> > >at ease.
> > >
> > >- 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]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: JCL problems

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/07/2005 01:32:26 PM:



> >The idea of having separate jar files has been floated about for a few 
> >years, for various reasons.  I believe it's only recently been 
associated 
> >with the idea that such would help alleviate classloader problems in 
the 
> >hierarchy [but only if certain rules are followed, as discussed in the 
> >original thread you referenced].
> 
> Sorry for my obtuseness but which rules are you referring to?
> 

Oh boy... ask a simple question...

One problem that we encounter, in one form or another, is when we look for 
a resource that "may or may not" be visible.  For example, a configuration 
file.

As delivered, the JCL jar files do *not* include a configuration file.

 Parent [commons-logging-api.jar, Log4J.jar]
^
|
 Child

This works as expected, for the most part [other ClassLoader problems 
aside].  So how do you configure the child application, in this case, to 
use a different logger?  You might introduce a configuration file.

 Parent [commons-logging-api.jar, Log4J.jar]
^
|
 Child  [commons-logging.properties, LogKit.jar]


So... what happens if/when the parent changes to move from "default" 
behavior to specific configuration behavior?

 Parent [commons-logging-api.jar,
 commons-logging.properties,
 MyLocalLoggerImpl.jar]
^
|
 Child  [commons-logging.properties, LogKit.jar]


Naturally, that drives down into the child, the parent effectively 
"mandates" the logger for the children.  This is a very natural scenario. 
So, of course... sooner or later in our not-so-mythical universe, we get a 
user who wants to return "control" back to the client application [EJB's]. 
 They would typically do this by setting [or the system is preset] the 
ClassLoader to do child-first resource resolution:

 Parent [commons-logging-api.jar,
 commons-logging.properties,
 MyLocalLoggerImpl.jar]
^
|
 Child, child-first loading
[commons-logging.properties, LogKit.jar]


Now we locate the proper config for the child, and all works as expected. 
But equally viable and frequently seen in this situation is a "self 
contained EAR file": the EAR file contains a copy of the commons-logging 
jar file, and depends on the "default" behavior built into the LogFactory, 
i.e. NO config file:

 Parent [commons-logging-api.jar,
 commons-logging.properties,
 MyLocalLoggerImpl.jar]
^
|
 Child, child-first loading
[commons-logging-api.jar, LogKit.jar]


In this case, the child's LogFactory is going to locate the 
commons-logging.properties file from the parent, and attempt to load 
MyLocalLoggerImpl [which extends Parent's Log interface] and return it 
through the Child's LogFactory as a Child Log interface... and of course 
we get an Exception.

A guideline ['rule'] that was floated about was that a parent class loader 
must never contain a configuration file, whether it be 
commons-logging.properties or 
META-INF/services/org.apache.commons.logging.Log*.  This is not something 
we enforce today, and it's really counter to the "expected" 
use/configuration of JCL.  So instead, we try the guideline that all 
children *must* provide a configuration file, noting that it may be 
ignored with parent-first search behavior.  This is a small improvement, 
but again unenforcable.

However, I've put more thought into this since my proposal of a few months 
back. :-)

There are really THREE independent things that need to be done:

a. Based on the discussion of ClassLoading issues from the other day, this 
is more properly handled by a discovery process that does NOT look higher 
in the hierarchy than the ClassLoader used to load the target interface 
(Log, in this case).  This would prevent discovery of a configuration that 
does not apply to the "local" Log.

b. Step completely away from "default" behavior [auto discovery]. 
Everything should be configured explicitely, either by placing a config 
file in every variant of the distributable jar files or possibly by 
hard-coding the logger impl for each variant [needs more thought].

c. Configuration discovery must enforce the rule that only ONE 
configuration may exist in any one ClassLoader.  This doesn't mean we 
can't have diff configs in each ClassLoader in a hierarchy, or different 
*ways* to configure within a ClassLoader instance: it means that we must 
*must* have a clear understanding of which configuration is appropriate at 
a single *point* in the hierarchy.

For example, the following *could* legal [though we could take a hard-line 
stance against it also]:

 Parent [A.jar(commons-logging.properties)]
^
|
 Child  [B.jar(commons-logging.properties),
 C.jar(META-INF/services/org.apache.commons.logging.Log)]


This might be considered legal because the discovery process plac

Re: [logging] Identify Class Loader Problems

[Richard Sitze]

Oh for better diagramming facilities in mail :-)

***
Richard A. Sitze
IBM WebSphere WebServices Development

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/07/2005 11:17:36 AM:

> 
> On 2005-01-27 22:52:02, Richard Sitze wrote:
> 
> Richard,
> 
> Sorry for not responding earlier. I'be got a question regarding item C.
> 
>  > C.  Host / Sub
>  >
>  >   - commons-logging.jar#org.apache.commons.logging.Log is
>  > loaded/loadable by Host.
>  >
>  >   - A host, such as JUnit, creates and manages an independent Sub
>  > ClassLoader
>  >
>  >   - Sub does NOT reference Host as a parent.
> 
> How is that possible? As far as I know, a child class loader will
> (by default) inherit the system class loader as a parent, in this case
> 'Host'.


   System ClassLoader
|
 +--+-+
 ||
Host --- creates --> Sub


> As the set up you describe seems impossible to me, I can't make sense
> of the rest of your conclusions for item 'C'. What am I missing?
> 
>  >   - Sub is set as the thread context ClassLoader.
>  >
>  >   - Execution is within code belonging to Host.
>  >
>  >   Problems:
>  >
>  >   1. The discovery process may *fail* altogether as it starts with 
the
>  >  thread context class loader, and cannot reach the Host loader.
>  >
>  >   2. The discovery process allows a Log implementation defined by the
>  >  Sub to be discovered by the Host, as the host executes
>  >  Host[LogFactory], via the thread context class loader.
>  >  Consider the case where the *Sub* defines
>  >  commons-logging.properties
>  >  or META-INF/Services/org.apache.commons.logging.Log.
> 
> 
> 
> 
> -- 
> 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] history lessons revisited

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 01/30/2005 04:09:54 
PM:

> 
> On 28 Jan 2005, at 20:15, Richard Sitze wrote:
> 
> > [re-send.. I don't see this picked up... hmmm]
> >
> >
> > Once, a long long time ago... someone wrote:
> >
> >> The problem: it won't work if commons-logging.jar is installed in the
> >> parent class loader, and log4j.jar ( or another logger ) is installed
> >> in a child loader ( like WEB-INF/lib ).
> >>
> >> What happens:
> >> - the factory uses the thread class loader to check if the log4j
> >>  ( or any other impl. ) exists ( and it does ).
> >>
> >> - it creates an instance of the Logger adapter. This will be created
> >>   using parent loader ( the one that loads commons-logging ).
> >>
> >> - the Logger instance makes references to Category or other classes
> >>   that are used in it's implementation. End of story, since the class
> >>   loader can't find the reference.
> >>
> >> This works fine for JAXP because the adapter for a parser is part of
> >> the parser jar. It doesn't work for c-l because the adapter is in the
> >> root loader ( with the API), not with the logging impl.
> >>
> >> That doesn't affect people who just use a single logger or can put
> >> the logger impl. in the same place with common-logging. It only 
affect
> >> containers like tomcat, when you want to let each webapp use it's own
> >> logger impl. of choice.
> >>
> >> I tried all kind of introspection games, it won't work. The only
> >> solution I see is to make sure the adapters are in the same place
> >> with the logger.
> >>
> >> Solution:
> >> Split commons-logging.jar in commons-logging-api.jar ( only the API
> >> and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
> >>
> >> Alternatively, leave commons-logging.jar as it is and create a second
> >> commons-logging-api.jar.
> >>
> >> The -api will be included in the common loader. Each webapp will have
> >> to include commons-logging.jar ( or -impl ), and it's own logger.
> >>
> >> Or course, the best would be to have the adapter included in the
> >> logger impl.
> >>
> >> What do you think ? Craig, Remy can we make another c-l dot release
> >> with this change ? ( I'll do some more testing to see how it works )
> 
> i suspect that this solution may run into some issues with the way that 
> JCL 1.0.x is factored into API and implementation. of course, i'd be 
> glad for someone to prove me wrong ;)
> 
> > And now I ask... is it *ever* appropriate to use to the Thread Context
> > Class Loader for our "auto detect" of impls?  The correct class loader
> > to use is *always* the classloader used to load the wrapper.  No?
> 
> yes: the test should always be performed with the classloader that used 
> to load the wrapper.

Ok, so this was my main focus/point on this topic.  I know we use the 
context class loader for some situations [and it's appropriate to do so]. 
Beginning to recognize that we don't need to take a 'carte-blanc' toward 
this.

Is this something you'd like to capture for the 1.0.5 release?  It 
resolves point "A" in my summary of class loader issues.

> (i seem to recall a discussion about this on the commons logging list 
> sometime in the last few months but i can't remember whether any subtle 
> issues emerged...)
> 
> it may be appropriate to use the thread context class loader if that's 
> the one to be used to load the wrapper. i wonder whether it might make 
> sense for logging implementations to be passed in the classloader which 
> should be used to load whatever classes they required...
> 
> - robert

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] Identify Class Loader Problems

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/01/2005 01:55:13 PM:

> 
> On 2005-01-27 22:52:02, Richard Sitze wrote:
> 
>  > A.  Parent / Child ClassLoaders, General
>  >
>  >   - commons-logging.jar#org.apache.commons.logging.Log is
>  > loaded/loadable by Parent.
>  >
>  >   - Child is the thread context ClassLoader.
>  >
>  >   - Parent defines a LogAWrapper for LogAImpl
>  >
>  >   - Child defines a LogAImpl
>  >
>  >   Problem:
>  >
>  >   1. Discovery finds Child[LogAImpl], and attempts to instantiate
>  >  LogAWrapper in Parent.  Fails, because Parent cannot see child.
> 
> Richard,
> 
> Forgive my nitpicking, but what do you mean exactly by LogAWrapper? By
> LogAImpl?

By "wrapper", I mean a commons-logging wrapper class.
by "impl", I mean a target logger implementation, such as Log4J.

This is, I believe, the Log4J problem you've previously described.  Where 
you drop Log4J in the client, and it caused the discovery mechanism to 
throw an exception.

LogA is any logger... such as Log4J:

 Discovery finds Child[Log4J], and attempts to instantiate
 Log4JLogger in Parent.  Fails, because Parent cannot see child:
 org.apache.commons.logging.impl.Log4JLogger [in parent] cannot load
 org.apache.log4j.Logger [in child].

> 
> Many thanks in advance for your response.
> 
> 
> -- 
> 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]

[logging] Identify Class Loader Problems

[Richard Sitze]

[re-send.. I don't see this picked up... hmmm]

I'd like to begin to identify the ClassLoader problems with the
current JCL discovery mechanism.  If you are aware of additional
issues, please respond and let's get them all out on the table.

I believe the following two scenarios summarize the specific issues,
as well as more general problems.

A.  Parent / Child ClassLoaders, General

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded/loadable by Parent.

  - Child is the thread context ClassLoader.

  - Parent defines a LogAWrapper for LogAImpl

  - Child defines a LogAImpl

  Problem:

  1. Discovery finds Child[LogAImpl], and attempts to instantiate
 LogAWrapper in Parent.  Fails, because Parent cannot see child. 


B.  Parent / Child ClassLoaders, Child does not defer to Parent first.

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded/loadable by Parent.

  - Child is the thread context ClassLoader.

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded by the Child.

  - It is clear that Parent[Log] and Child[Log] are different Classes.

  Problems:

  1. The discovery process allows a Log implementation defined by the
 Parent to be discovered by the Child as the child executes
 Child[LogFactory].  This does NOT happen by way of the
 relationship between the Log and the LogImpl, because the
 Parent[Log] and the Child[Log] are not the same class.
 It happens via classes named in configuration files:
 commons-logging.properties and
 META-INF/Services/org.apache.commons.logging.Log.

  2. The discovery process allows a Log implementation defined by the
 Child to be discovered by the Parent, as the parent executes
 Parent[LogFactory], via the thread context class loader.

 Examples include dropping Log4J into the child, and the [old]
 behavior that favors Log4J forcing it and it's JCL wrapper
 to be loaded via the Child and exposed to the parent.


C.  Host / Sub

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded/loadable by Host.

  - A host, such as JUnit, creates and manages an independent Sub
ClassLoader

  - Sub does NOT reference Host as a parent.

  - Sub is set as the thread context ClassLoader.

  - Execution is within code belonging to Host.

  Problems:

  1. The discovery process may *fail* altogether as it starts with the
 thread context class loader, and cannot reach the Host loader.

  2. The discovery process allows a Log implementation defined by the
 Sub to be discovered by the Host, as the host executes
 Host[LogFactory], via the thread context class loader.
 Consider the case where the *Sub* defines
 commons-logging.properties
 or META-INF/Services/org.apache.commons.logging.Log.


SUMMARY of PROBLEM:

There are ONE general problem at work here:
  - Disrespect for proper ISOLATION as defined by ClassLoaders

The fundamental problem is dealing with the thread context classloader
in [common] situations where it represents an "isolated" or
"isolating" mechanism.  For scenario A, we are simply loading
when we should be.  For scenario B, by setting "child first"
search behavior, we are granting the child a degree of independence.
For scenario C, by creating a Sub that isn't related to the
"parent" at all.

In both cases, JCL behavior incorrectly *assumes* that a more
traditional "Parent/Child" relationship exists with the thread context
classloader.

While the current mechanism *is* generally useful, I'm realizing
that we've only addressed one corner case, and have broken other
*very* reasonable classloader configurations.


WHAT CAN BE DONE:

- For A.1, For auto configuration of for predefined wrapper impls,
  any "impl" class should be located using the ClassLoader of the
  wrapper, never the thread context class loader.


Detect "independent" thread context class loaders and respect the
boundries.  By independent, I mean any classloader that gives
preference to it's own "internal" classes.

- The trivial case is a thread context class loader that doesn't
  include the current ClassLoader [used to load 'this' class, i.e.
  LogFactory] in it's hierarchy.  In this case, the discovery
  mechanism simply has *NO* business crossing the boundry, it should
  revert back to using the ClassLoader used to load the [currently
  executing] LogFactory.  This should cover scenario C.

- Scenario B is a bit more difficult to resolve.

  For B.1, the child "resource manager" [LogFactory] is in
  control.  We can presume during discovery that we should NOT
  look any higher up the hierarchy than the level at which our
  interface [Log or LogFactory] was discovered for configuration
  or implementation resources.  [various games can be played
  to determine which loader in a hierarchy was used to obtain
  any particular resource].

  For B.2, the parent "resouce manager" [LogFactory] is in
  control.  We can "check" by requesting our base interface [Log or
 

[logging] history lessons revisited

[Richard Sitze]

[re-send.. I don't see this picked up... hmmm]


Once, a long long time ago... someone wrote:

> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed
> in a child loader ( like WEB-INF/lib ).
> 
> What happens:
> - the factory uses the thread class loader to check if the log4j
>  ( or any other impl. ) exists ( and it does ).
> 
> - it creates an instance of the Logger adapter. This will be created
>   using parent loader ( the one that loads commons-logging ).
> 
> - the Logger instance makes references to Category or other classes
>   that are used in it's implementation. End of story, since the class
>   loader can't find the reference.
> 
> This works fine for JAXP because the adapter for a parser is part of
> the parser jar. It doesn't work for c-l because the adapter is in the
> root loader ( with the API), not with the logging impl.
> 
> That doesn't affect people who just use a single logger or can put
> the logger impl. in the same place with common-logging. It only affect
> containers like tomcat, when you want to let each webapp use it's own
> logger impl. of choice.
> 
> I tried all kind of introspection games, it won't work. The only
> solution I see is to make sure the adapters are in the same place
> with the logger.
> 
> Solution:
> Split commons-logging.jar in commons-logging-api.jar ( only the API
> and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. 
> 
> Alternatively, leave commons-logging.jar as it is and create a second
> commons-logging-api.jar.
> 
> The -api will be included in the common loader. Each webapp will have
> to include commons-logging.jar ( or -impl ), and it's own logger. 
> 
> Or course, the best would be to have the adapter included in the
> logger impl.
> 
> What do you think ? Craig, Remy can we make another c-l dot release
> with this change ? ( I'll do some more testing to see how it works )

And now I ask... is it *ever* appropriate to use to the Thread Context
Class Loader for our "auto detect" of impls?  The correct class loader
to use is *always* the classloader used to load the wrapper.  No?


***
Richard A. Sitze
IBM WebSphere WebServices Development

[logging] history lessons revisited

[Richard Sitze]

Once, a long long time ago... someone wrote:

> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed
> in a child loader ( like WEB-INF/lib ).
> 
> What happens:
> - the factory uses the thread class loader to check if the log4j
>  ( or any other impl. ) exists ( and it does ).
> 
> - it creates an instance of the Logger adapter. This will be created
>   using parent loader ( the one that loads commons-logging ).
> 
> - the Logger instance makes references to Category or other classes
>   that are used in it's implementation. End of story, since the class
>   loader can't find the reference.
> 
> This works fine for JAXP because the adapter for a parser is part of
> the parser jar. It doesn't work for c-l because the adapter is in the
> root loader ( with the API), not with the logging impl.
> 
> That doesn't affect people who just use a single logger or can put
> the logger impl. in the same place with common-logging. It only affect
> containers like tomcat, when you want to let each webapp use it's own
> logger impl. of choice.
> 
> I tried all kind of introspection games, it won't work. The only
> solution I see is to make sure the adapters are in the same place
> with the logger.
> 
> Solution:
> Split commons-logging.jar in commons-logging-api.jar ( only the API
> and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. 
> 
> Alternatively, leave commons-logging.jar as it is and create a second
> commons-logging-api.jar.
> 
> The -api will be included in the common loader. Each webapp will have
> to include commons-logging.jar ( or -impl ), and it's own logger. 
> 
> Or course, the best would be to have the adapter included in the
> logger impl.
> 
> What do you think ? Craig, Remy can we make another c-l dot release
> with this change ? ( I'll do some more testing to see how it works )

And now I ask... is it *ever* appropriate to use to the Thread Context
Class Loader for our "auto detect" of impls?  The correct class loader
to use is *always* the classloader used to load the wrapper.  No?


***
Richard A. Sitze
IBM WebSphere WebServices Development

[logging] Identify Class Loader Problems

[Richard Sitze]

I'd like to begin to identify the ClassLoader problems with the
current JCL discovery mechanism.  If you are aware of additional
issues, please respond and let's get them all out on the table.

I believe the following two scenarios summarize the specific issues,
as well as more general problems.

A.  Parent / Child ClassLoaders, General

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded/loadable by Parent.

  - Child is the thread context ClassLoader.

  - Parent defines a LogAWrapper for LogAImpl

  - Child defines a LogAImpl

  Problem:

  1. Discovery finds Child[LogAImpl], and attempts to instantiate
 LogAWrapper in Parent.  Fails, because Parent cannot see child. 


B.  Parent / Child ClassLoaders, Child does not defer to Parent first.

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded/loadable by Parent.

  - Child is the thread context ClassLoader.

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded by the Child.

  - It is clear that Parent[Log] and Child[Log] are different Classes.

  Problems:

  1. The discovery process allows a Log implementation defined by the
 Parent to be discovered by the Child as the child executes
 Child[LogFactory].  This does NOT happen by way of the
 relationship between the Log and the LogImpl, because the
 Parent[Log] and the Child[Log] are not the same class.
 It happens via classes named in configuration files:
 commons-logging.properties and
 META-INF/Services/org.apache.commons.logging.Log.

  2. The discovery process allows a Log implementation defined by the
 Child to be discovered by the Parent, as the parent executes
 Parent[LogFactory], via the thread context class loader.

 Examples include dropping Log4J into the child, and the [old]
 behavior that favors Log4J forcing it and it's JCL wrapper
 to be loaded via the Child and exposed to the parent.


C.  Host / Sub

  - commons-logging.jar#org.apache.commons.logging.Log is
loaded/loadable by Host.

  - A host, such as JUnit, creates and manages an independent Sub
ClassLoader

  - Sub does NOT reference Host as a parent.

  - Sub is set as the thread context ClassLoader.

  - Execution is within code belonging to Host.

  Problems:

  1. The discovery process may *fail* altogether as it starts with the
 thread context class loader, and cannot reach the Host loader.

  2. The discovery process allows a Log implementation defined by the
 Sub to be discovered by the Host, as the host executes
 Host[LogFactory], via the thread context class loader.
 Consider the case where the *Sub* defines
 commons-logging.properties
 or META-INF/Services/org.apache.commons.logging.Log.


SUMMARY of PROBLEM:

There are ONE general problem at work here:
  - Disrespect for proper ISOLATION as defined by ClassLoaders

The fundamental problem is dealing with the thread context classloader
in [common] situations where it represents an "isolated" or
"isolating" mechanism.  For scenario A, we are simply loading
when we should be.  For scenario B, by setting "child first"
search behavior, we are granting the child a degree of independence.
For scenario C, by creating a Sub that isn't related to the
"parent" at all.

In both cases, JCL behavior incorrectly *assumes* that a more
traditional "Parent/Child" relationship exists with the thread context
classloader.

While the current mechanism *is* generally useful, I'm realizing
that we've only addressed one corner case, and have broken other
*very* reasonable classloader configurations.


WHAT CAN BE DONE:

- For A.1, For auto configuration of for predefined wrapper impls,
  any "impl" class should be located using the ClassLoader of the
  wrapper, never the thread context class loader.


Detect "independent" thread context class loaders and respect the
boundries.  By independent, I mean any classloader that gives
preference to it's own "internal" classes.

- The trivial case is a thread context class loader that doesn't
  include the current ClassLoader [used to load 'this' class, i.e.
  LogFactory] in it's hierarchy.  In this case, the discovery
  mechanism simply has *NO* business crossing the boundry, it should
  revert back to using the ClassLoader used to load the [currently
  executing] LogFactory.  This should cover scenario C.

- Scenario B is a bit more difficult to resolve.

  For B.1, the child "resource manager" [LogFactory] is in
  control.  We can presume during discovery that we should NOT
  look any higher up the hierarchy than the level at which our
  interface [Log or LogFactory] was discovered for configuration
  or implementation resources.  [various games can be played
  to determine which loader in a hierarchy was used to obtain
  any particular resource].

  For B.2, the parent "resouce manager" [LogFactory] is in
  control.  We can "check" by requesting our base interface [Log or
  LogFactory] from the thread context class loade

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?

[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 <http://www.boardVU.com>
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] API - methods for logging entry and exit events

[Richard Sitze]

Phil Steitz <[EMAIL PROTECTED]> wrote on 01/24/2005 05:25:09 PM:



> While I agree with everything that you have said about "indiscriminate 
> logging," I think you are missing Richard's point here.  In some 
> environments, this sort of ad hoc change is not allowed or cannot be 
> executed quickly enough to help resolve a production problem.  The 
> relevant information simply needs to be available in the logs.
> 
> I agree with you that entry/exit logging and other forms of "automatic" 
> instrumentation can create more problems than they solve.  The challenge 

> is to get the right info into the logs without, as you put it, 
> "polluting" them with junk that strains the infrastructure and makes it 
> hard to find the relevant info. Sadly, success here depends much less on 

> what the logging framework provides than what the developer is thinking 
> when deciding when and what to log.

Agreed 100%.  Careful and thoughtful logging should be strongly 
encouraged, and placed at a high priority.

However, logging tends to be an afterthought for many developers, 
something that is sprinkled in during debugging of particular problems... 
hence by it's nature it tends to focus on known problems instead of 
"unknown".  Entry/exit logging won't necessarily "fix" this in some cases, 
but it will provide a minimum of information in those areas of the code 
that have less focus on "thoughtful" logging.  Note also that the minimum 
is sufficient in many cases.

Taking a step back, I do have to agree that "automated and indescriminate" 
logging can result in excessive pollution of a log.  So let me say that 
I'm not advocating that *every* method on every class be instrumented with 
entry/exit: public methods are good candidates, while small helper methods 
are less so.

Let's step back and look at the bigger picture in such situations.

The first thing that comes to my mind is logging related to tight inner 
loops of a program.  I'd be the first to rip "indiscriminate" logging out 
of "tight loops" during runtime or code review.  That said, I'd rather 
have it [automatic] than have nothing.  Pick your poison.

Please, before anyone jumps down my throat, I'm not advocating eliminating 
logging from all loops.  The key point is that we're all ahead when the 
community thinks about all aspects of component development.

> 
> Phil

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] API - methods for logging entry and exit events

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 01/24/2005 11:06:21 AM:

> Richard Sitze wrote on 2005-01-21 20:07:49:
> 
>  >The purpose of logging is to capture enough state of a system, so that
>  >when you identify *where* the error occurs in the logs, you have
>  >information that can help you identify the cause of the error.
>  >Class/method 'boundries' are convenient for many reasons, not least of
>  >which is that in a well designed [dare I say OO?] modularized software
>  >component the methods are [typically] relatively short and 
"functionally
>  >defined" by their parameters.  Stack traces for exceptions [if you 
HAVE an
>  >exception] can identify a method, but don't capture the state of the
>  >system in the same way that an entry log entry [eeks] would. 
Entry/exit
>  >help you identify the state of the system at the time a fault occurs, 
and
>  >in many cases can identify the fault itself.
> 
> In other words, you are advocating the use of logging as a sort of
> persistent debugger. Clearly, a debugger can provide a perfectly
> detailed view of the system, down to the register level. However, no
> one usually cares about that much detail. Not only is that level of
> detail distracting, it will noticeably slow down the application and
> hog megabytes of disk space. Is indiscriminate logging IBM's secret
> justification for ever bigger and faster machines?

1. It's not indiscriminate logging.  That's why we call it tracing, and 
that's why the logging impls [such as Log4J] allow us to turn it on/off.

2. The fact of the matter is that in many corporate operational 
environments, production-level [that's *not* development] systems are 
guarded carefully.  Installing additional components [debuggers], never 
MIND running them, is not an option.  When one fails to duplicate a 
problem in a development environment, customers *expect* us to be able to 
glean information from productions system that can demonstrate the 
problems.

3. Are your pokes/jabs at me for being an IBM employee necessary?  I've 
spent 2/5 of my career at IBM.  When I exceed 1/2, you come on back and 
I'll listen to you more seriously.

My goal is to be an advocate of the technologies and techniques I see that 
can benefit the community.  I *will* argue for what I believe to be in the 
best interest of the development community.  And when the decisions are 
made, I will support them.  That's the stance I take with my employer: 
defending open-source decisions that I may not agree with.

That I am tainted by my experience, environment, etc., is a fact of life.. 
and part of the process.  It's the strength of open source development. 
It's why we have developers from many backgrounds make up our community.  
Why do you want to make that a negative?

> 
>  >Likewise, errors can be caused by earlier eventsthe entry/exit 
flow
>  >information can help identify the factors related to such.. again 
based on
>  >conveniant boundries in the code.
> 
> Theoretically speaking, there is no denying that as the quantity of
> information about the system increases, so does the probability of
> finding the cause of a given error. But where do you stop?

I claim that entry/exit at class/method is reasonable.. along with other 
best-practices I've described in other notes.

It's easily identifiable, it's convenient, it's easy to automate [AspectJ 
or other tooling], and more importantly it's *useful*.  Should it stop 
there?  No.  Is it a reasonable, and easily understood, starting point for 
instrumenting code with logging?  Yes.

>  >I do agree that with some serious planning [thought], and effort that
>  >there may be more helpful bits of information to log in some cases, 
but if
>  >experience shows anything it is that these are typically identified 
from
>  >hindsight in many components.  We don't always *have* the luxury of
>  >hindsight.  In these cases, the more information logged the better.
> 
> Let me present this from a different angle.
> 
> Logging is about fixing the next run, not the current one. The current
> one failed, rememberer? So, in some sense, you always have the luxury
> of hindsight, almost by construction.
> 
> You can rely on log files with tons and tons of noise, or you can look
> at less detailed logs but which still provide a view of the big
> picture. Armed with the big picture you can try to reproduce the
> problem on your side. Once you are able to reproduce the error, you can
> fix it.

The more you understand about the macro picture, and where a problem lies, 
the more you want information on the micro picture in that area.

I've personally been in situations where the errors could not be 
duplicated &q

Re: [logging] API - methods for logging entry and exit events

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 01/21/2005 01:45:46 PM:

> 
> Logging too much can be as bad as the absence of logging.
> 
> Cluttering the log output with entry and exit events will increase the
> amount of noise and negatively impact the usefulness of the
> logs. Consequenly, logging enter and exit events amount to bad practice.
> 
> For a deployed system, which one would assume has undergone some
> testing, no one, and I mean no one, will care about method entry and
> exit. A developer may have use for entry and exit methods during
> development but such statements should be removed well before the
> application is deployed.

Well Ceki, there are many views out there.  I don't only disagree based on 
opinion of best-practice, I disagree from experience with Enterprise 
[large scale 24/7 business] customers, and person experience with 
developing and maintaining applications running in these spaces.

The purpose of logging is to capture enough state of a system, so that 
when you identify *where* the error occurs in the logs, you have 
information that can help you identify the cause of the error. 
Class/method 'boundries' are convenient for many reasons, not least of 
which is that in a well designed [dare I say OO?] modularized software 
component the methods are [typically] relatively short and "functionally 
defined" by their parameters.  Stack traces for exceptions [if you HAVE an 
exception] can identify a method, but don't capture the state of the 
system in the same way that an entry log entry [eeks] would.  Entry/exit 
help you identify the state of the system at the time a fault occurs, and 
in many cases can identify the fault itself.

Likewise, errors can be caused by earlier eventsthe entry/exit flow 
information can help identify the factors related to such.. again based on 
conveniant boundries in the code.

I do agree that with some serious planning [thought], and effort that 
there may be more helpful bits of information to log in some cases, but if 
experience shows anything it is that these are typically identified from 
hindsight in many components.  We don't always *have* the luxury of 
hindsight.  In these cases, the more information logged the better.

entry/exit logging is a best-practice that is *easily* understood by 
developers, it provides a minimal set of information that can offer a 
significant improvement over speriodic logging within the code.

Now... if you feel that such methods are not appropriate for the 'general' 
case... while I disagree, I won't argue *too* strongly.. but I would point 
out that we have requested these API's under the guise of 'Enterprise 
Logging' services ;-).

> 
> -- 
> 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]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


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

Re: [logging][PROPOSAL] 1.0.5 release

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
01/19/2005 04:49:09 PM:

> IMO the first step before any work can begin on any improvements is to 
> release the current code (this contains an important enhancement 
> improving memory release in the 1.0.x series of releases).  therefore, 
> i propose that we should start the release process for 1.0.5 by 
> electing a release manager and formulating a release plan.

+1 release 1.0.5
+1 robert as release manager

> i'm willing to act as release manager for this release. my vision would 
> be that a release branch would be taken as soon as possible but with a 
> long release candidate phase would follow to allow the release to be 
> tested.

... waiting to see your release plan ;-)

> 
> - robert
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] API - methods for logging entry and exit events

[Richard Sitze]

Emmanuel Bourg <[EMAIL PROTECTED]> wrote on 01/19/2005 06:16:35 AM:

> 9. Logging entry/exit event is not so common and I'd better write 
directly:
> 
> log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
> 
> rather than
> 
> log.enter(this, "foo", new Object[] { param1, param2 }, "Entering");
> 
> enter()/exit() doesn't make the code much shorter, it provides just a 
> more detailed semantic.

1. But more than just an alternate to debug.  For loggers that "support" 
it, it would be mapped to a different logging level [i.e. JSR-47 "FINER"]. 
 If we were to follow the guidelines described in the current JCL users 
guide for "debug" level logging, and map those over to include the 
entry/exit method "level", then best practices for JCL would be:

a) log.debug() to be used as we cross component
   boundries, allowing a high-level
   view of the flow between multiple
   components.  Also reasonable to
   log "interesting" events/information
   that are meaningfull at a
   component level.

b) log.entry/exit() would be used as we cross
   class and method boundries,
   allowing a view of the flow
   between and within classes
   within a component.

c) log.trace() would be used to provide additional
   detail reflecting flow and information
   within a method.

And by having these on separate levels [for those impls
that support the levels], you could enable
(a), (a)+(b), or (a)+(b)+(c).


2. Just FYI, the [conceptual] equivalent to

log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");

would be

log.enter(this, "foo", new Object[] { param1, param2 }, null);

Specifically, 

Log.enter(Class clazz,
  String method,
  Object[] params,
  String additionalText)

is intended to be mapped to the logger, and it is expected that the logger 
impl would express that as something similar to:

"Entering " + clazz.getName() + "." + methodName + "(" + params + ") " 
+ additionalText

[please consider that psuedo-code... there are details missing I know :-)]

> Emmanuel Bourg

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] API - methods for logging entry and exit events

[Richard Sitze]

Emmanuel Bourg <[EMAIL PROTECTED]> wrote on 01/19/2005 06:16:35 AM:

> 9. Logging entry/exit event is not so common and I'd better write 
directly:
> 
> log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
> 
> rather than
> 
> log.enter(this, "foo", new Object[] { param1, param2 }, "Entering");
> 
> enter()/exit() doesn't make the code much shorter, it provides just a 
> more detailed semantic.

1. But more than just an alternate to debug.  For loggers that "support" 
it, it would be mapped to a different logging level [i.e. JSR-47 "FINER"]. 
 If we were to follow the guidelines described in the current JCL users 
guide for "debug" level logging, and map those over to include the 
entry/exit method "level", then best practices for JCL would be:

a) log.debug() to be used as we cross component
   boundries, allowing a high-level
   view of the flow between multiple
   components.  Also reasonable to
   log "interesting" events/information
   that are meaningfull at a
   component level.

b) log.entry/exit() would be used as we cross
   class and method boundries,
   allowing a view of the flow
   between and within classes
   within a component.

c) log.trace() would be used to provide additional
   detail reflecting flow and information
   within a method.

And by having these on separate levels [for those impls
that support the levels], you could enable
(a), (a)+(b), or (a)+(b)+(c).


2. Just FYI, the [conceptual] equivalent to

log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");

would be

log.enter(this, "foo", new Object[] { param1, param2 }, null);

Specifically, 

Log.enter(Class clazz,
  String method,
  Object[] params,
  String additionalText)

is intended to be mapped to the logger, and it is expected that the logger 
impl would express that as something similar to:

"Entering " + clazz.getName() + "." + methodName + "(" + params + ") " 
+ additionalText

[please consider that psuedo-code... there are details missing I know :-)]

> Emmanuel Bourg

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [logging] API - methods for logging entry and exit events

[Richard Sitze]

Eclipse makes search/replace of strings during refactoring "optional". 
It's certainly easy enough to manage there.

Emmanuel Bourg <[EMAIL PROTECTED]> wrote on 01/19/2005 06:22:29 AM:

> Tomas Znamenacek wrote:
> 
> > 1. Refactoring a method containing calls to log.enter() and 
log.exit(),
> > with hardcoded method name, will render these calls inaccurate.
> 
> I don't know how the Eclipse refactoring works, but at least for 
> IntelliJ there is no problem here. With:
> 
> public void foo() {
>  log.enter(this, "foo");
> }
> 
> Renaming the method will automatically change the string.
> 
> Emmanuel Bourg
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: commons-logging auto-detection

[Richard Sitze]

Paul Libbrecht <[EMAIL PROTECTED]> wrote on 01/04/2005 03:26:00 AM:

> Hi,
> 
> This may be related but I was fighting recently with embedding Jelly 
> within jEdit which, of course, has its own class-loading mechanism 
> because of plugins.
> I simply did not manage to have jelly:log messages directed to my 
> console but it may be not so important.
> 
> I realized that one thing that would have strongly advantaged me is to 
> be able to "pre-load" the current logging factory (or even a "context 
> logger", of which all child-loggers that would be created would appear) 
> set as a thread-local static instance.
> This way, as long as we understand classloading times (which is really 
> not that hard), it is possible for plugins that use other things that 
> use logging to actually influence this logging.

I think that what you are asking for is a way to bind a LogFactory 
instance to a particular ClassLoader, perhaps immediately following the 
construction of the ClassLoader instance:

 setFactory(ClassLoader, LogFactory);

Thoughts:

a.  Under the auspices of the 'one config' policy, such an API would throw 
an exception if an attempt were made to bind a LogFactory instance to a 
ClassLoader which has a different LogFactory instance already bound to it.

b.  Though this is a simple method to implement [it's cacheFactory made 
public], keep it simple: we've talked about looking for a pluggable 
discovery mech, with a minimalistic default discovery.  The default 
shouldn't exhibit this behavior, perhaps commons-discovery (JCD) can take 
on this new idea.

Under this scheme, you would establish the presence of JCD in your JVM, 
JCL LogFactory.getFactory [static method] would locate JCD and use it 
instead of it's default internal mechanism.  Your application code would 
create a new ClassLoader, and use JCD.bind(ClassLoader, Object) to do the 
binding.

> 
> I would choose this to have priority to others, at least if a certain 
> system property is set.
> 
> paul
> 
> 
> Le 2 janv. 05, à 22:50, robert burrell donkin a écrit :
> > On 28 Dec 2004, at 00:40, Matt Sgarlata wrote:
> >> I think often JCL will be used as you describe, but not always.
> >>
> >> For example, let's say I am developing a component that monitors 
> >> database activity and monitors usage statistics (this is a 
> >> hypothetical example).  The main purpose of this component is to log 
> >> messages to be processed later by a human.  I use JCL and put a 
> >> commons-logging.properties in my org.dbmonitor package that says "use 

> >> Log4J and display INFO and higher messages".
> >>
> >> This component may be deployed in many different environments.  Here 
> >> are two examples:
> >> 1) Standalone on a server.  In this case, the default settings 
> >> specified at the component level should be used.
> >> 2) As a component of another application.  In this case, the overall 
> >> application specifies logging properties that overwrite those in the 
> >> component.  To do this, the application specifies a 
> >> commons-logging.properties in the default package, which overwrites 
> >> the properties specified at the component level.  In this example, 
> >> the application chooses it only wants WARN and higher messages and 
> >> that it wants the messages rendered with JDK 1.4 logging.
> >>
> >> My point is that one overall configuration of logging for the entire 
> >> JVM may be too restrictive.  I think we could benefit from multiple 
> >> JCL configurations, each targeted at different parts of a system.
> >
> > i think that the idea we're going forward with is that there needs 
> > only to be one discovery configuration for the whole of the JVM (not 
> > one logging implementation). when a request for a log is received, the 

> > pluggable discovery mechanism chosen by the configuration determines 
> > how the bridging implementation is assigned. at the present, the 
> > discovery mechanism is not configurable and is implemented in 
> > LogFactory. hopefully later, it would be possible to choose to use the 

> > current mechanism or use a system property to replace it with another 
> > completely different one.
> >
> > FWIW i think that the package level discovery mechanism would be 
> > powerful in some use cases and would support such a discovery 
> > mechanism but only as pluggable implementation, not as part of the 
> > default discovery mechanism (the classloader issues concern me 
> > greatly).
> >
> > - 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]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


-

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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

news <[EMAIL PROTECTED]> wrote on 12/27/2004 06:40:16 PM:

> I think often JCL will be used as you describe, but not always.

"Not always" is of less concern.  Matt, the PRIMARY focus of JCL is as 
Ceki described.  There are no if/ands/buts about it.  If you choose to use 
it in any other fashion, you are certainly welcome too.

However, from a design standpoint, this one point is critical.  We make 
decisions that direct the development of JCL on this point.

> For example, let's say I am developing a component that monitors 
> database activity and monitors usage statistics (this is a hypothetical 
> example).  The main purpose of this component is to log messages to be 
> processed later by a human.  I use JCL and put a 
> commons-logging.properties in my org.dbmonitor package that says "use 
> Log4J and display INFO and higher messages".
> 
> This component may be deployed in many different environments.  Here are 

> two examples:
> 1) Standalone on a server.  In this case, the default settings specified 

> at the component level should be used.
> 2) As a component of another application.  In this case, the overall 
> application specifies logging properties that overwrite those in the 
> component.  To do this, the application specifies a 
> commons-logging.properties in the default package, which overwrites the 
> properties specified at the component level.  In this example, the 
> application chooses it only wants WARN and higher messages and that it 
> wants the messages rendered with JDK 1.4 logging.
> 
> My point is that one overall configuration of logging for the entire JVM 

> may be too restrictive.  I think we could benefit from multiple JCL 
> configurations, each targeted at different parts of a system.
> 
> Matt
> 
> Ceki Gülcü wrote:
> > 
> > Matt,
> > 
> > JCL exists mainly for the purpose of libraries wishing to *integrate*
> > with the logging API chosen by the user by deferring the selection of
> > the logging impl to runtime. The author of library "net.sf.morph"
> > probably does *not* wish to impose any logging related property on the
> > end-user. Consequently, it does not make sense to have package
> > specific properties at the JCL level. Would you agree?
> > 
> > 
> > At 08:26 PM 12/27/2004, Matt Sgarlata wrote:
> > 
> >> Couldn't this be refined even further by incorporating a change to 
JCL 
> >> I proposed earlier?  Here's a copy of my original post:
> >>
> >> 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 
> >>
> > 
> > 
> 
> 
> -
> 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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Martin Cooper <[EMAIL PROTECTED]> wrote on 12/27/2004 01:07:28 PM:

> On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze <[EMAIL PROTECTED]> 
wrote:
> > Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:
> > 
> > > At 03:05 AM 12/27/2004, Charles Daniels wrote:
> > >
> > > >If I understand the JCL discovery mechanism correctly, it actually
> > > >should work just fine in the scenario you describe above.  For it 
to
> > > >work, you would not set the org.apache.commons.logging.LogFactory
> > system
> > > >property, because, as you pointed out, system properties are 
JVM-wide.
> > > >Rather, for individual applications to use distinct underlying 
logging
> > > >implementations, you can simply place a commons-logging.properties 
file
> > > >in each application context (in WEB-INF/classes), setting the
> > > >org.apache.commons.logging.LogFactory property as appropriate in 
each
> > > >distinct commons-logging.properties file.  Since these properties 
files
> > > >will be loaded via distinct context class loaders, each application 
can
> > > >use distinct logging implementations.
> > >
> > > Good point. This will require some understanding by the user about 
the
> > > classloader delegation mechanism used by the app server, which 
varies
> > > from vendor to vendor or even from version to version of an app 
server
> > > by the same vendor.  Nevertheless, I stand corrected.
> > 
> > I wish :-(
> > 
> > In fact, this works ONLY if JCL is *not* available in a "common"
> > classloader higher up the hierarchy.  In that case, the config file
> > packaged in commons-logging.jar is found and used.
> > 
> > If JCL *is* packaged as a shared library in a parent classloader, then 
the
> > work around is typically a non-standard feature offered by some J2EE
> > hosts, for switching the search order within the classloader hierarchy
> > from parent first to parent last.  This allows the config file 
packaged
> > with the app to be located first.
> 
> I think you have this backwards. The standard J2EE class loader lookup
> order is local first and then parents (i.e. parent last), as opposed
> to the standard Java 2 order, which is the reverse. The non-standard
> feature provided by some containers is to use the Java 2 order instead
> of the J2EE order. See:
> 
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

Excellent point.  However, these are recommendations, not requirements. 
The problem, as described, is real enough.  Also, more importantly, I tend 
to use J2EE to demonstrate the issues surrounding more sophisticated 
ClassLoader hierarchies, but it should never be assumed that it is the 
only one.

We all agree that the problem is real enough in various environments.

> --
> Martin Cooper
> 
> 
> > Part of the proposal for "new discovery" is to circumvent the 
classloader
> > hierarchy [at a cost] and for picking up configs from the lowest point 
in
> > the hierarchy.
> > 
> > >
> > > --
> > > 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]
> > 
> >
> 
> -
> 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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/27/2004 
02:57:45 AM:

> "Charles Daniels" <[EMAIL PROTECTED]> writes:
> 
> >> -Original Message-
> >> From: Ceki Gülcü [mailto:[EMAIL PROTECTED] 
> >> Sent: Sunday, December 26, 2004 11:24 AM
> >> To: commons-dev@jakarta.apache.org
> >> Subject: commons-logging auto-detection WAS: [logging] 
> >> Enterprise Common Logging... dare we say 2.0?
> >> 
> >> 
> >> Simon et al.
> >> 
> >> Log4j is slowly migrating to a model where there will be only a 
single
> >> log4j.jar installed per Application Server. This single copy will be
> >> installed under the ./common/lib or ./lib/ directories. See 
> >> [1, 2, 3] for
> >> further details.
> >> 
> >> Consider the case of single log4j.jar placed in ./common/lib, and two
> >> web-applications called 'A' and 'B' both built on top of Struts. Also
> >> assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the
> >> user of application 'B' wishes to use log4j. Since Struts uses JCL,
> >> there is no way for user of application 'A' to direct the logs
> >> generated by Struts to go to j.u.l and at the same time to have 
Struts
> >> in application 'B' direct its logging output to log4j. (Setting the
> >> org.apache.commons.logging.LogFactory system property will not help
> >> because system properties are shared by all applications.)
> >> 
> >> This simple example shows that the current JCL discovery mechanism
> >> will not always work as intended.
> 
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above.  For it to

Not to mention within a J2EE environment, you can bind properties [such as 
org.apache.commons.logging.LogFactory] to the ClassLoader.  This has to be 
done by the J2EE application prior to any invocation of LogFactory, but 
it's do-able.

Hmm not so sure this works in JCL, but it does with JCDiscovery.

> Yep. Which once again shows, that using JCL in a component is a _good_
> thing, even though Ceki will never cease to argue against it. :-)

Humor aside, Ceki has taken a very reasonable view of JCL.  Please, let's 
not incite to humor-wars here.

> 
>Regards
>   Henning
> 
> 
> -
> 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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:

> At 03:05 AM 12/27/2004, Charles Daniels wrote:
> 
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above.  For it to
> >work, you would not set the org.apache.commons.logging.LogFactory 
system
> >property, because, as you pointed out, system properties are JVM-wide.
> >Rather, for individual applications to use distinct underlying logging
> >implementations, you can simply place a commons-logging.properties file
> >in each application context (in WEB-INF/classes), setting the
> >org.apache.commons.logging.LogFactory property as appropriate in each
> >distinct commons-logging.properties file.  Since these properties files
> >will be loaded via distinct context class loaders, each application can
> >use distinct logging implementations.
> 
> Good point. This will require some understanding by the user about the
> classloader delegation mechanism used by the app server, which varies
> from vendor to vendor or even from version to version of an app server
> by the same vendor.  Nevertheless, I stand corrected.

I wish :-(

In fact, this works ONLY if JCL is *not* available in a "common" 
classloader higher up the hierarchy.  In that case, the config file 
packaged in commons-logging.jar is found and used.

If JCL *is* packaged as a shared library in a parent classloader, then the 
work around is typically a non-standard feature offered by some J2EE 
hosts, for switching the search order within the classloader hierarchy 
from parent first to parent last.  This allows the config file packaged 
with the app to be located first.

Part of the proposal for "new discovery" is to circumvent the classloader 
hierarchy [at a cost] and for picking up configs from the lowest point in 
the hierarchy.

> 
> -- 
> 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] ECL: Log interface vs. abstract class

[Richard Sitze]

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/25/2004 06:25:51 
PM:

> On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> > In  my last  message, I  failed to  emphasize the  brittleness  of the
> > "break  into  interfaces" hypothesis.   Even  if  at  a high-level  of
> > abstraction two  APIs perform the same  task, this does  not mean that
> > they can be abstracted away by a thin facade (or bridge). For example,
> > all the attempts  made at bridging X.25 and  TCP/IP, both well defined
> > and  stable protocols,  have  failed miserably,  even  if both  stacks
> > supposedly fit into layers 1-4 of the 7 layer OSI network model.
> 
> I quite agree with this. 
> 
> And I don't think the approach of providing multiple optional interfaces
> in commons-logging to support "advanced" features that various logging
> libraries implement is useful either. As I've written in previous
> emails, I do *not* like the idea of an application failing to start
> because an appropriate logging implementation is not present.
> 
> I think commons-logging should be a *simple* API that abstracts only the
> *basic* functionality of logging. The current API is fine; log strings
> at various priority levels to a single named category. Any reasonable
> log implementation will be able to provide a sane mapping for these
> concepts.
> 
> But I don't think it is worth trying to extend JCL much beyond this. As
> Ceki says, logging libraries can provide widely varying features and it
> is not productive to try to map these to portable APIs.

Agreed in general, but there are some directions that are reasonable to 
follow.  i18n is one.

> JCL does a very useful job for jakarta-commons libraries: provide a
> means for the commons libraries to implement logging without enforcing a
> logging implementation on the larger app which uses the library. Note
> that the kind of log messages generated by commons components are of
> course implementation-related and are therefore aimed at the *developer*
> not the user. For this reason, i18n support is not terribly useful for
> commons component logging.

Not true.  In particular, the Message level API's [fatal, error, warn, 
info] may be targeted towards either end users, or [international] 
developers using the component.  In either case, i18n is useful.

For example, HTTPSender reflects an edge component to which customers are 
directly exposed.  Failure to open ports, dropped socket connections... 
any socket, TCP/IP, or HTTP error is of interest to the end user, not just 
the developer using HTTPSender.  Clearly, the developer would very much 
prefer that the users *resolve* these problems [in their native languages] 
rather than have the user contact the developer.  And the component 
developer would prefer that the app developer understand how/if the API's 
are being misused, again in their natural language if possible.

There is a need for i18n logging, and IBM's recognition of this need is 
much broader than *my* immediately daily chores.  I'm just a spokeman here 
folks: the proposal is submitted on behalf of IBM, not IBM WebSphere 
[J2EE].  IBM and many other global companies are involved with a number of 
open source projects.  Internationalization IS becoming more and more 
important for our customers.  And our customers using open source are your 
customers.

The IBM community also feels *strongly* that we must NOT fragment the 
logging community any further than it already is, strong alignment with 
JCL is necessary.

> However I'm not convinced that for *applications* (rather than
> libraries) it is sensible to use JCL at all; why not just pick a
> concrete logging implementation and use that? You get all the necessary
> features, and apps can deploy whatever logging implementation they want.

Agree 100%.  NO question.  This is fundamental to JCL's goals.

> The only awkward situation is container frameworks like J2EE. In this
> case, you may want logging to be redirected to the container's logging
> implementation so that logging from all apps within the framework is
> treated consistently. I can see some kind of common API cabable of
> generating i18n messages being useful here. 
>
> After all the discussion on logging recently, I'm coming to the
> conclusion that Richard's original proposed features (i18n, discovery
> changes) should *not* be included in JCL. None of these features help
> commons components with their logging requirements, and these features

Disagree strongly.  And I believe there are others would also disagree.

> *are* going to make JCL significantly more complex and controversial. It
> would be better to start a separate project. If this project can
> successfully resolve the issues then maybe it could be merged back in to
> JCL.
> 
> To summarize, my (non-binding) votes are:
>   -1 to adding extra *optional* features to JCL that fail if the
> "discovered" logging implementation doesn't suport them. This
> includes Richard's EnterpriseLog class, 

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: [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?

[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] ECL: pluggable message resolution

[Richard Sitze]

robert burrell donkin <[EMAIL PROTECTED]> wrote on 
12/20/2004 02:51:17 PM:



> > ...  how do you propose to reconcile this "pluggable" mechanism
> > with the underlying logger that DOES accept "MSGID" and Object[] 
> > directly?
> >
> > I'm of the opinion that IF a reasonable proposal can be produced, then 

> > it
> > can be introduced at a later point in time [evolution].
> 
> it seems to me that pluggability arises as a natural consequence.
> 
> one day (i'm sure) it will be possible to create thin bridges to 
> i18nable logging systems. AFAIK none of the generations of logging 
> systems which JCL currently targets can be bridged in such a manner.
> 
> it seems to me that the most elegant approach would be to allow (and 
> encourage) native thin bridges (to i18nable logging systems) but to 
> also build an implementation which would adapts from the enterprise 
> interfaces to base JCL. it would make sense for this implementation to 
> be pluggable (since the base rendering should ideally be minimally 
> sufficient) so that others can easily substitute a more sophisticated 
> rendering/i18n implementation.
> 
> opinions?

I keep coming back to logging impls to which the wrappers pass the key and 
resource bundle name.  What does it mean to plug in an alternate mapping 
mechanism?  In such a scenario we do NOT want to translate before the 
logger.

Can anyone provide an example walk-through of what this means to the 
component developer, what resources and alternate resources the developer 
might provide, demonstrate the advantage this has?  I'm just not seeing 
this.

Is the alternate mechanism by-component?

It's an interesting concept.  Lots of questions and issues.  I would agree 
that we don't want to do anything that would make this impossible, but 
neither do I want "fun cool" features to hold us back on other simple 
tasks that we can perform.

> 
> >> And I'd like to see a Java 5 versiion of this interface that takes
> > advantage
> >> of variable argument lists, rather than the String[].
> >
> > Unlikely in the JCL.
> 
> sad but true
> 
> it would be quite a big step to say that the enterprise portion is for 
> java 5 only. i wouldn't actively object provided that active support 
> for this measure was adequately demonstrated.

An interesting question.

... if you are developing for Java 5 alone, it strikes me that you might 
be focusing on the logging classes provided?  I could argue that any Java 
5 application/framework could very well be required to deal with one 
component or another that leverages the JSR-47 logging anyway.

> 

***
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 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 

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] ECL: pluggable message resolution

[Richard Sitze]

[forgive me for changing the subject, I'm trying to take steps to try to 
help us focus on separate issues]

"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 12/17/2004 09:10:34 PM:

> 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.

I would claim that for a first shot let's keep this simple.  It is 
pluggable in that you may plug in your own Log implementation that does 
what you need.

That aside, how do you propose to reconcile this "pluggable" mechanism 
with the underlying logger that DOES accept "MSGID" and Object[] directly?

I'm of the opinion that IF a reasonable proposal can be produced, then it 
can be introduced at a later point in time [evolution].


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

Unlikely in the JCL.

> 
>--- Noel


***
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]

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?

[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

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?

[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 sub

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?

[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]

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

[Richard Sitze]

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.

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.

> 
> - 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?

[Richard Sitze]

Glad you made it Robert, was starting to feel that this was getting 
snubbed by the core logging advocates ;-)! 


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

> 
> On 10 Dec 2004, at 00:40, David Graham wrote:
> 
> >
> > --- simon <[EMAIL PROTECTED]> wrote:
> > 
> >
> >> Regarding the addition of "entry/exit" logging APIs, I'm also in 
> >> favour.
> >> The code seems trivial, and it can be mapped to "TRACE" level for
> >> logging implementations that don't provide "FINER" equivalents. It 
> >> also
> >> seems to me that:
> >>   log.enter("MyClass", "MyMethod", "Entering method");
> >> is nice and readable.
> >
> > Until you refactor the class name or method name.  Then your logging 
> > code
> > is completely misleading.  Considering the fact that IDEs allow you to
> > rename things without even looking at their implementation code, the
> > chance of the logging not keeping up with the names is high.
> 
> +1
> 
> it would make more sense to take a class (rather than a classname)

The proposed API's take a Class, not a class name.  His concern is still 
valid for method names.  Thanks for recognizing this distinction.

> 
> > I would personally never use the enter/exit methods for those reasons. 

> >  If
> > I wanted that kind of detail, I would use AspectJ.
> 
> +1
> 
> but that's the point: at the moment you can't crosscut and log an enter 
> or exit to the object's logger because the appropriate method does not 
> exist.

Again, thank you for recognizing and pointing this out.  I think I tried 
(and may have failed) in another note... wasn't aware of the proper 
terminology.

> 
> - 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: Enterprise Logging - API Proposal

[Richard Sitze]

Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/13/2004 
07:05:31 PM:

> Ah-hah, I understand our main disconnect now: I'm thinking in terms of 
> configuring logging for an overall application and you're thinking in 
> terms of components.  So now at least I understand where you're coming 

A step forward... :-)

> from, but I think it's time for us to agree to disagree :)  I think 

Give me time ;-)  The proper role and position for commons-logging is up 
to the individual developer.  That said, within the commons-logging 
development community it is a fundamental premise that commons-logging's 
mere existence is justified ONLY as an enabler for logging in components 
that must be developed independently from a single application/framework.

> someone said earlier that perhaps part of your proposal would fit better 

> in Log4J or in some other logging component.  In any case, thanks for 
> spending so much time discussing your ideas with me.  More comments 
below...

If you are developing applications or frameworks, and you want Log4J 
function, then go use Log4J.  End of story, commons-logging has little/no 
value to you.  If your application integrates components that use JCL 
[Jakarta Commons Logging], then bind JCL to Log4J in your hosting 
environment, and you are ready to move forward.

> 
> 
> Richard Sitze wrote:
> 
> >Now, were does the *component* developer 'place' this content?  I claim 
we 
> >need a standard approach for this, based on the 'resource bundle name' 
> >parameters we pass into the 
> >EnterpriseLogFactory.getEnterpriseLog(loggerName, resourceBundleName);
> >
> > 
> >
> 
> I think instead of the resourceBundleName we could optionally pass in a 
> MessageSource implementation.  That way if internationalization for a 
> component was dependent on a particular implementation, it could be 
> passed in.  If no MessageSource was passed in, we could still try 
> java.util.ResourceBundle and the underlying logging implementation.  I'm 

> sure we disagree on this point, but I just wanted to through this idea 
> out there :)

Not a bad idea.  With every level of flexibility we gain more complex 
code.  I would resist this at this moment because it either  a) introduces 
a 3rd party dependency on MessageSource, b) introduces yet more code to 
develope for commons-logging (keep it simple).

In addition, it also requires the user to new up and manage the 
MessageSource, yet one more ticky-mark on the check-list of new work to 
do.  There is admittedly a balance between "programmer work" and 
"function".  Everyone is going to have their own opinions on where the 
right place is to strike this balance.

So far, there are proposals for new API's.. but we've tried to keep new 
Interfaces, and implementations behind them, to a bare minimum (ELog & 
ELogFactory).


> 
> Matt
> 
> 
> -
> 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: Enterprise Logging - API Proposal

[Richard Sitze]

Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/13/2004 
02:26:41 PM:

> 
> >>Then calling code that wants to make use of localized logging would 
make 
> >> 
> >>
> >>this call:
> >>
> >>private static final LocalizedLog log = (LocalizedLog) 
> >>LogFactory.getLog(MyClass.class);
> >> 
> >>
> >
> >Not sufficient.
> >a) Leaving the existing LogFactory alone allows a minimal 
implementation 
> >to be obtained, if that is appropriate, for Log.  It also allows an 
> >EnterpriseLog/LocalizedLog to be obtained.
> >b) Use of an alternate factory, as opposed to type-casts which might 
fail, 
> >represents a programmatic "contract".  It assures the developer that 
they 
> >*will* get an Enterprise/Localized Log class back.  Not something that 
may 
> >or may not typecase.
> > 
> >
> I advocate that the type cast above *never* fail, because LogFactory 
> will (in JavaDoc, not in its actual interface) guarantee a LocalizedLog 
> will be returned.  If the underlying logging implementation doesn't 

Reasonable, but overly restrictive.  getLog() should be allowed to return 
a Log instance only.  I understand we have a difference in opinion here. 
I'd like to hear other opinions on this.  In addition, the proposed 
EnterpriseLogFactory.getEnterpriseLog() method takes two parameters:

1.  logger [category] name
2.  resourceBundleName

Without something identifying the resourceBundle, we have no way to 
resolve the messages, or to help the underlying logger implementation 
determine how to find these resources.

Could we introduce the 'Log getLog(String name, String 
resourceBundleName)' method on the existing Factory?  Sure... but if it's 
ALWAYS going to return an EntLog, then let's make it contractual and 
change the return type to EntLog and we're starting down a road that 
brought the orginal proposal to introduce this on a subclass: 
EntLogFactory.

Matt, I'm not going to claim that the original proposal is "the only way 
to do things."  I only want to make it clear that the simple solution(s) 
have inherent implications that not everyone might agree with, and we must 
be aware of them.

> support internationalization, then the messages are just passed through 
> unresolved.  I will argue why I like this approach below...
> >Not sufficient.  Again, commons logging, though minimal, must be 
useful. 
> >It is trivial work for a wrapper to use the Java tools to do the 
message 
> >translation.  If the translation still fails, then agree: dump the 
message 
> >directly.
> >
> >We *are* working on an assumption that
> >a) the component using logging *owns* the message resource bundle(s)
> >b) the general "scheme" for accessing/translating fits ONE paradigm, 
and 
> >said paradigm must be mappable to the target implementation [if 
supported 
> >directly], or resolved by the wrapper [if not].
> >
> >
> >>(4) It is inappropriate for any type of message key resolution to be 
> >>implemented in commons-logging.  Message key resolution is certainly 
> >>important though, and should definitely be implemented somewhere else 
:)
> >> 
> >>
> >
> >I argue against this.  Please keep the focus on the expected target for 

> >making use of commons-logging: component, not hosting 
> >application/framework.
> >
> >Note that the message key resolution and message formatting must be 
> >directly exposed, the component developer must:
> >
> >a) write the message resources: key / text
> >b) assume and develope to some mechanism that enables translation, or 
> >multiple texts per key
> >c) assume some formatting mechanism, and embed formatting directives in 

> >the messages
> >
> >No matter the target environment, the extraction and formatting of 
these 
> >messages must be performed as the component developer has planned. 
> >Therefore, for a common I18N logging, we must assume and adopt a 
> >"standard" translation and formatting mechanism that all components 
would 
> >use.
> >
> >Ideally, such a standard would be supported by all, or at least a 
> >majority, of the target logger implementations.  Also, minimal is 
> >prefered.  We believe that the mechanisms provided by the JDK core 
> >classes, as per the original proposal, satisfy both of these.
> >
> >Is this minimal?  depends on your definition of minimal.  Do I see any 
> >alternatives?  No.
> > 
> >
> Ah but I do see alternatives : )
> 
> First, I'm sure everyone will agree: messages should be parameterizable 
> in this standard format shown below.
> 
> messageKeyNumberOne=This is an {0} message from {1}

Agreed.

Now, were does the *component* developer 'place' this content?  I claim we 
need a standard approach for this, based on the 'resource bundle name' 
parameters we pass into the 
EnterpriseLogFactory.getEnterpriseLog(loggerName, resourceBundleName);

> 
> So I can plug in "ignorant" and "Matt" or "insightful" and "God", as the 

> case may be.
> 
> The goal of "standardizing on a format" is satisfied just by what I have 

> written previously.

We agree on this point.

Re: Enterprise Logging - API Proposal

[Richard Sitze]

Will move the discussion back to your proposal.


Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/12/2004 
02:58:38 PM:

> To support localized log messages, we only need to introduce one 
> *optional* interface that will *not* affect any existing functionality.
> 
> interface LocalizedLog extends Log { // methods TBD }

As per the earlier proposal.

> 
> Then calling code that wants to make use of localized logging would make 

> this call:
> 
> private static final LocalizedLog log = (LocalizedLog) 
> LogFactory.getLog(MyClass.class);

Not sufficient.
a) Leaving the existing LogFactory alone allows a minimal implementation 
to be obtained, if that is appropriate, for Log.  It also allows an 
EnterpriseLog/LocalizedLog to be obtained.
b) Use of an alternate factory, as opposed to type-casts which might fail, 
represents a programmatic "contract".  It assures the developer that they 
*will* get an Enterprise/Localized Log class back.  Not something that may 
or may not typecase.

> And existing code or code that doesn't want to make use of localized 
> logging stays like this:
> 
> private static final Log log = LogFactory.getLog(MyClass.class);
> 
> To accomplish this, the LogFactory implementation will be changed to 
> *always* return a LocalizedLog.  If the underlying logging 
> implementation supports internationalization, log messages will be 
> internationalized.  If not, the LocalizedLog methods will delegate to 
> the plain old Log methods and log output will display the message keys 
> unresolved.  Clearly if your code is using the LocalizedLog API you will 

> probably want to chose an implementation that supports localization, but 

> if you don't that won't cause errors in commons-logging (your log 
> messages will be written, they just won't be resolved).
> 
> This API is based on the following assumptions, which I think we should 
> all be able to agree on:
> (1) Commons-logging should remain a thin bridge to other logging APIs

Agreed.  That is the intent.

> (2) Some logging APIs already offer localized log messages (e.g. Log4J)
> Which in turn implies
> (3) Commons-logging will pass through localized logging calls to 
> underlying logging implementations which support internationalization.

Absolutely

> Logging implementations which do not support localization will simply 
> print out the arguments to the localized logging calls directly, without 

> any resolution

Not sufficient.  Again, commons logging, though minimal, must be useful. 
It is trivial work for a wrapper to use the Java tools to do the message 
translation.  If the translation still fails, then agree: dump the message 
directly.

We *are* working on an assumption that
a) the component using logging *owns* the message resource bundle(s)
b) the general "scheme" for accessing/translating fits ONE paradigm, and 
said paradigm must be mappable to the target implementation [if supported 
directly], or resolved by the wrapper [if not].


> (4) It is inappropriate for any type of message key resolution to be 
> implemented in commons-logging.  Message key resolution is certainly 
> important though, and should definitely be implemented somewhere else :)

I argue against this.  Please keep the focus on the expected target for 
making use of commons-logging: component, not hosting 
application/framework.

Note that the message key resolution and message formatting must be 
directly exposed, the component developer must:

a) write the message resources: key / text
b) assume and develope to some mechanism that enables translation, or 
multiple texts per key
c) assume some formatting mechanism, and embed formatting directives in 
the messages

No matter the target environment, the extraction and formatting of these 
messages must be performed as the component developer has planned. 
Therefore, for a common I18N logging, we must assume and adopt a 
"standard" translation and formatting mechanism that all components would 
use.

Ideally, such a standard would be supported by all, or at least a 
majority, of the target logger implementations.  Also, minimal is 
prefered.  We believe that the mechanisms provided by the JDK core 
classes, as per the original proposal, satisfy both of these.

Is this minimal?  depends on your definition of minimal.  Do I see any 
alternatives?  No.

Now, once we've settle on such, it is not a problem [and it is minimal 
work] for the wrapper classes to step in to do the translation for those 
loggers that don't do it themselves.

> 
> Matt
> 
> Simon Kitching wrote:
> 
> >Hi Richard,
> >
> >The class javadoc for the EnterpriseLog class states:
> >
> >Please note that a specific implementation of Commons Logging can 
choose
> >to support either the simple logging interface (represented by [EMAIL 
> >PROTECTED]
> >Log}) or the advanced logging interface (represented by this
> >interface).  A user of a Common Logging implementation that supports
> >only the simple logging interface will not be able to instantiat

Re: [VOTE] [logging] Enterprise Logging - API Proposal

[Richard Sitze]

Matt, I think you are jumping the gun here.  It is way to premature to 
vote on your proposal, if for no other reason then there is a preexisting 
proposal on the table.

That said, I would like to point out that your proposal is, on the 
surface, very much in line with the original proposal.  Specifically - 
naming aside - EnterpriseLog is intended to extend Log, just as your 
LocalizedLog does.  If that is your 'key point', then there is nothing new 
here.




Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/13/2004 
12:11:30 PM:

> The API I proposed yesterday circumvents this problem and allows us to 
> add whatever methods we need for internationalization while not breaking 

> backwards compatability.  Instead of adding methods to the Log 
> interface, we introduce a new interface, called "LocalizedLog".  The key 

> is that the Log and LogFactory APIs can remain unchanged and yet still 
> allow us to introduce this new functionality.
> 
> Since no one's voiced any concerns with my proposal, why don't we go 
> ahead and put it to a vote?  I'm not a committer, but here's my +1 (and 
> I am willing to contribute code to make this happen).  We can vote on 
> other changes separately (e.g. - add equivalent to FINER, perhaps ENTER 
> and EXIT)
> 
> 
>  [ ] +1  I support this API proposal and am willing to help
>  [ ] +0  I support this API proposal but am unable to help
>  [ ] -0  I do not support this API proposal
>  [ ] -1  I do not support this API proposal, and here are my reasons
> 
> 
> Matt
> 
> Richard Sitze wrote:
> 
> >Interesting point Simon.. more below
> >
> >Simon Kitching <[EMAIL PROTECTED]> wrote on 12/10/2004 
10:57:47 
> >PM:
> >
> > 
> >
> >>Hi Richard,
> >>
> >>The class javadoc for the EnterpriseLog class states:
> >>
> >>Please note that a specific implementation of Commons Logging can 
choose
> >>to support either the simple logging interface (represented by [EMAIL 
> >>PROTECTED]
> >>Log}) or the advanced logging interface (represented by this
> >>interface).  A user of a Common Logging implementation that supports
> >>only the simple logging interface will not be able to instantiate a
> >>EnterpriseLog. 
> >>
> >>
> >>Given the following code:
> >>
> >>if ((day == saturday) || (day == sunday)) {
> >>  EnterpriseLog log = EnterpriseLogFactory.getLog(...);
> >>  log.error("This code doesn't work on weekends");
> >>}
> >>
> >>are you proposing that this code will run fine all week, then suddenly
> >>throw a runtime error on saturday if the underlying log implementation
> >>does not support "enterprise" logging?
> >> 
> >>
> >
> >As you noted below, the desired behavior is that logging will always 
> >succeed.  If I recall correctly, the current JCL will fall back to a 
> >SimpleLogger if it cannot locate an explicitly configured Log 
> >implementation.  Two points worth considering on this topic:
> >
> >1. Fall back is "ok", BUT - we *MUST* log an error/info/warning message 
on 
> >this event, so that there is a clear understanding that something is 
not 
> >as it should be.  The "silent fail & fallback" of the current JCL has 
to 
> >go.
> >
> >2. A "simple" EnterpriseLog implementation must be made available, to 
> >allow the behavior you describe below.
> >
> > 
> >
> >>While this example is a bit contrived, I can certainly envisage an app
> >>put together with modules, one of which uses "enterprise" logging, and
> >>is only invoked under some conditions...
> >>
> >>Incidentally, it looks like JCL itself will throw an exception on
> >>startup if an explicit log implementation is specified (eg via system
> >>properties or commons-logging.properties) but that implementation 
cannot
> >>be found. This is quite in contradiction to the log4j logging 
approach,
> >>which is that an app should *never* fail just because logging fails. I
> >>prefer the log4j philosophy myself...
> >>
> >>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]
> >
> >
> > 
> >
> 
> 
> -
> 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]

This is probably only worth saying one time, so please take this as 
informational, and not as argumentative.

First, the term we use is - in the end - of no real concern to us.  We 
have a functional requirement.  Would be nice if the term was meaningful. 
That said, I believe "enterprise" is meaningful, if not familiar to some 
of our peer developers.

Enterprise: An undertaking, especially one of some scope, complication, 
and risk.

"Enterprise" does have a lot of marketing hype behind it, yet I assure 
you, as a developer, my (and IBMs) intent is not market-speak.  From my 
perspective, this is an "old" term describing the best-practices and 
design considerations that are different for large systems.  There IS a 
learning curve that a programmer must work through to understand the 
change in mind-set required for writing software that would be deployed 
into such environments.  And yes, many of these are cumbersome and 
undesirable for others.  The separation between Log and EnterpriseLog 
should address this concern.

In that light, from the perspective of a 2.0 release, there is 
justification for adding (upwards compatible) some elements of the 
proposal, or variants thereof, to the Log interface.  That would expose 
some new function to the more simple use cases, and allow the more 
difficult to digest API's to remain on EnterpriseLog.


David Graham <[EMAIL PROTECTED]> wrote on 12/11/2004 01:04:40 PM:

> 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. 
> 
> Additionally, it might have helped all of us if the proposal didn't use
> marketing hype terms devoid of meaning (ie. "enterprise") to describe 
what
> is actually a small and reasonable set of additions related to localized
> messages.
> 
> There are no "JSR-mandated logging requirements" for commons logging so
> I'm not really sure what that means.
> 
> David
> 
> --- "Noel J. Bergman" <[EMAIL PROTECTED]> 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.
> > 
> >--- Noel
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> 
> 
> __ 
> Do you Yahoo!? 
> Read only the mail you want - Yahoo! Mail SpamGuard. 
> http://promotions.yahoo.com/new_mail 
> 
> -
> 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: Enterprise Logging

[Richard Sitze]

Interesting point Simon.. more below

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/10/2004 10:57:47 
PM:

> Hi Richard,
> 
> The class javadoc for the EnterpriseLog class states:
> 
> Please note that a specific implementation of Commons Logging can choose
> to support either the simple logging interface (represented by [EMAIL 
> PROTECTED]
> Log}) or the advanced logging interface (represented by this
> interface).  A user of a Common Logging implementation that supports
> only the simple logging interface will not be able to instantiate a
> EnterpriseLog. 
> 
> 
> Given the following code:
> 
> if ((day == saturday) || (day == sunday)) {
>   EnterpriseLog log = EnterpriseLogFactory.getLog(...);
>   log.error("This code doesn't work on weekends");
> }
> 
> are you proposing that this code will run fine all week, then suddenly
> throw a runtime error on saturday if the underlying log implementation
> does not support "enterprise" logging?

As you noted below, the desired behavior is that logging will always 
succeed.  If I recall correctly, the current JCL will fall back to a 
SimpleLogger if it cannot locate an explicitly configured Log 
implementation.  Two points worth considering on this topic:

1. Fall back is "ok", BUT - we *MUST* log an error/info/warning message on 
this event, so that there is a clear understanding that something is not 
as it should be.  The "silent fail & fallback" of the current JCL has to 
go.

2. A "simple" EnterpriseLog implementation must be made available, to 
allow the behavior you describe below.

> 
> While this example is a bit contrived, I can certainly envisage an app
> put together with modules, one of which uses "enterprise" logging, and
> is only invoked under some conditions...
> 
> Incidentally, it looks like JCL itself will throw an exception on
> startup if an explicit log implementation is specified (eg via system
> properties or commons-logging.properties) but that implementation cannot
> be found. This is quite in contradiction to the log4j logging approach,
> which is that an app should *never* fail just because logging fails. I
> prefer the log4j philosophy myself...
> 
> 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]

Good points.  Please consider:

a.  There are logging implementations today, I believe, that can accept 
this information.

b.  Consider AspectJ as an enabler of such methods, as opposed to an 
alternative.

c.  I'm not fluent in AspectJ terminology, so forgive any mistakes... but 
I see this as an opportunity for someone to submit AspectJ rule(s) that 
support this type of logging for both commons logging 1.0.x and for the 
new proposal.  No reason AspectJ can't make use of these methods on the 
Log interface.   Doing so would keep the logging consistent with whatever 
we map commons-logging to.

e.  In the absence of such rules, and for those who do not yet feel that 
AspectJ is "usable" in their production environments [and these DO exist], 
it would be better if the code were instrumented using more traditional 
approaches.




Paulo Gaspar <[EMAIL PROTECTED]> wrote on 12/10/2004 01:03:47 PM:

> I agree. Aspect oriented tools obsolete the need for this kind of 
> logging method.
> 
> Paulo Gaspar
> 
> David Graham wrote:
> 
> >--- simon <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >
> >I would personally never use the enter/exit methods for those reasons. 
If
> >I wanted that kind of detail, I would use AspectJ.
> >
> >David
> > 
> >
> 
> 
> -
> 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]

"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/10/2004 
04:34:07 AM:

> Richard Sitze <[EMAIL PROTECTED]> writes:
> 
> Hi,
> 
> >B.2.  Fix fragile configuration problems - Currently
> >  the user has NO idea which impl is in effect.
> >  All the default/fall back behavior means that in
> >  the end we have an apparent non-deterministic
> >  logging implementation.  Errors in config file
> >  names, classpath errors, classpath ordering,
> >  etc., can all change the behavior... with no
> >  idea which is in effect.
> 
> >  The fundamental problem with the current factory
> >  is that it is dependent on "passively"
> >  identifying a logging implementation.
> 
> >  We propose one solution below, but would ask a
> >  more general question: any new bright ideas?
> 
> +1 It could be as simple as providing a property in
> commons-logging.properties which says "use.classpath.detection = no"
> 
> If the commons-logging.properties is omitted or the property is missing,
> then still the (fragile) class path checker is used.
> 
> >  - For message level logging, support globalized
> >variants on the new EnterpriseLog interface:
> 
> >info(Class callingClass,
> > String methodName,
> > String messageID);
> 
> -0 on callingClass. Reason for this:
> 
> Many of the log using applications have the calling class anyway. They
> use a pattern like this:
> 
>Log log = LogFactory.getLog(this.getClass());
> 
> So you might already _have_ a class object. If the log is obtained by
> the
> 
>Log log = LogFactory.getLog("foo.log");
> 
> pattern, we can still add a 
> 
> log.setLogClass(this.getClass());
> 
> method which is completely optional. But you get one less parameter to
> pass (which will be this.getClass() most of the time anyway) and if
> you have a lot of logging statements, this will either evaluate to
> having to drag another object (which contains the Class object of the
> current class) around or a lot of this.getClass() method calls.

We considered binding the class name to the Log object.  Yes, we *may* 
have the class name in the form of a category name, but further discussion 
convinced us that users of logs do not necessarily use class names for 
category names, I know of a number of exceptions to that myself.  Also, 
for those that use alternate category names, do we really want to force a 
one Log instance for every class, even when the category name is common? 
We felt like this was unnecessarily complicated, had a number of runtime 
lifecycle concerns.  We left the Log instance bound to a single category.

> 
> >  - Utility function to support formatting for
> >other purposes (exception strings):
> 
> >formatMessage(String messageID);
> >formatMessage(String messageID, Object messageParam);
> >formatMessage(String messageID, Object[] messageParams);
> 
> Strictly -1. This is not the scope of commons-logging! We could add
> this to some other commons project. Once we add non-logging
> functionality to commons-logging, people will start using this for
> non-logging related purposes.

The intent was to facilitate obtaining loggable error/warning information 
to be logged AND use the same information in an exception.

However, you raise a very good point.

Other comments on this?

> 
> [...]
> 
> >- Repackaging
> 
> +1 on that.
> 
> One thing that you have missed and that I would like to see is
> programmatic change of the log level to be used. I have no real idea
> yet on how to do this but I really would like to be able to change the
> log level of a log statement e.g. from INFO to WARN without having to
> do source code changes.

Well... we didn't exactly miss it.  We did discuss it, there are clearly 
advocates for such.

That said, Commons Logging has strongly resisted this for some time.

Please put commons logging into the context of a component level log 
wrapper, it's not an application level logging mechanism [commons logging 
bridged the component logging TO your application logger].

You are claiming that you want to be able to configure the logging of a 
component as it pertains to your application.  As a component developer, I 
would resist this... When I tell my component users to 'turn on logging', 
then I *WANT* logging on, I want deterministic behavior, I don't want to 
worry about how they've configured the component level logging.


> 
>Regards
> 

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

[Richard Sitze]

We don't globalize trace level messaging [debug, entry/exit, trace]

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/09/2004 07:23:54 
PM:

> On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > > -Original Message-
> > > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> > > Sent: Thursday, December 09, 2004 4:54 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > > 
> > > I'm not a logging expert, but couldn't the internationalized 
> > > logger be 
> > > just a specific Log implementation ? You would just log the 
> > > key of the 
> > > message with the existing methods :
> > > 
> > > log.warn("key");
> > > 
> > > The Locale would be a configuration parameter. There is just an 
issue 
> > > with the message's parameters :) This will require at least an 
> > > additional method like warn(String, Object[]).
> > 
> > Since all of the logging methods (fatal, error, etc.) accept a message
> > of type Object, you could support i18n/l10n by doing something like 
the
> > following:
> > 
> > log.warn(new Message("key", params));
> > 
> > where params is an Object[].  Of course, Message could have additional
> > constructors.
> > 
> > The Message class would encapsulate all l10n functionality.  This way,
> > you probably wouldn't even have to create any new implementations
> > specifically for handling i18n/l10n.  Further, you probably wouldn't
> > even have to modify existing Log implementations since most of them
> > (perhaps all?) just end up doing something like 
String.valueOf(message)
> > to get the actual text to log.  Therefore, the new Message class would
> > simply implement toString to properly construct the localized message.
> 
> Alas, I don't think that is efficient enough. This approach would
> require a new Message object to be created *before* each call,
> regardless of whether that logging level was enabled or not.
> 
> Of course, each call could be wrapped in:
>   if (log.isWarnEnabled()) {
> log.warn(new Message());
>   }
> but that would get tiring very quickly!
> 
> Actually, for warn/error/fatal, this approach is probably not too bad.
> After all, there won't be a whole lot of such calls, and they *are*
> likely to have logging enabled.
> 
> It's only for debug/trace levels that this approach would have problems.
> Is it really important to "globalize" debug and trace messages?
> 
> 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.
> 
> 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]

"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 07:42:47 PM:

> 8<
> 
> > > 
> > > Since all of the logging methods (fatal, error, etc.) 
> > accept a message
> > > of type Object, you could support i18n/l10n by doing 
> > something like the
> > > following:
> > > 
> > > log.warn(new Message("key", params));
> > > 
> > > where params is an Object[].  Of course, Message could have 
> > additional
> > > constructors.
> > > 
> > > The Message class would encapsulate all l10n functionality. 
> >  This way,
> > > you probably wouldn't even have to create any new implementations
> > > specifically for handling i18n/l10n.  Further, you probably wouldn't
> > > even have to modify existing Log implementations since most of them
> > > (perhaps all?) just end up doing something like 
> > String.valueOf(message)
> > > to get the actual text to log.  Therefore, the new Message 
> > class would
> > > simply implement toString to properly construct the 
> > localized message.
> > 
> > Alas, I don't think that is efficient enough. This approach would
> > require a new Message object to be created *before* each call,
> > regardless of whether that logging level was enabled or not.
> > 
> > Of course, each call could be wrapped in:
> >   if (log.isWarnEnabled()) {
> > log.warn(new Message());
> >   }
> > but that would get tiring very quickly!
> 
> That's what you should be doing already, even without the proposed
> Message class, unless you are passing only a string literal (i.e., not a
> string constructed via concatenation), otherwise you take a performance
> hit regardless.  For example:
> 
>   log.warn("No such object: " + name);
> 
> You would want a code guard around this to avoid unnecessary
> concatenation.  Even the new internationalized logging methods (as
> proposed earlier in this thread) were add, you would still want to use a
> code guard when passing multiple message parameters:
> 
>   log.warn("key", new Object[] { param1, param2 });
> 
> Otherwise you might unnecessarily create the object array.  So you
> should really be using code guards as a matter of practice anyway.
> 
> > 
> > Actually, for warn/error/fatal, this approach is probably not too bad.
> > After all, there won't be a whole lot of such calls, and they *are*
> > likely to have logging enabled.
> > 
> > It's only for debug/trace levels that this approach would 
> > have problems.
> > Is it really important to "globalize" debug and trace messages?
> 
> JCL User Guide proposes that debug and trace messages NOT be localized.
> Only warn/error/fatal messages are to be localized.  Therefore, in the
> case of debug/trace messages, no Message instances would be used, so
> there is no problem.
> 
> > 
> > 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.

The resource bundle is named on the EnterpriseLogFactory factory methods 
that produce the EnterpriseLog.  It's up the the wrapper/implementation to 
determine what to do with the resource bundle name and keys.

Keep it simple

> 
> > 
> > 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?

[Richard Sitze]

"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 06:20:14 PM:

> > -Original Message-
> > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, December 09, 2004 4:54 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > I'm not a logging expert, but couldn't the internationalized 
> > logger be 
> > just a specific Log implementation ? You would just log the 
> > key of the 
> > message with the existing methods :
> > 
> > log.warn("key");
> > 
> > The Locale would be a configuration parameter. There is just an issue 
> > with the message's parameters :) This will require at least an 
> > additional method like warn(String, Object[]).

I think there is value in an explicit contract between the component 
developer and the logger... if the logger doesn't support i18n, then that 
logger can't be used.

> 
> Since all of the logging methods (fatal, error, etc.) accept a message
> of type Object, you could support i18n/l10n by doing something like the
> following:
> 
> log.warn(new Message("key", params));
> 
> where params is an Object[].  Of course, Message could have additional
> constructors.
> 
> The Message class would encapsulate all l10n functionality.  This way,
> you probably wouldn't even have to create any new implementations
> specifically for handling i18n/l10n.  Further, you probably wouldn't
> even have to modify existing Log implementations since most of them
> (perhaps all?) just end up doing something like String.valueOf(message)
> to get the actual text to log.  Therefore, the new Message class would
> simply implement toString to properly construct the localized message.

We considered that, and it can certainly be discussed here... the problem 
with this approach is

a) the overhead of newing up objects
b) more "work" for the developer, we want to "enable" globalization by 
more direct support

> 
> > 
> > Emmanuel Bourg
> > 
> > 
> 
> 
> -
> 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]

Huh... is this where I hide in the corner and pretend that I didn't write 
that section of the user's guide?


"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 05:20:24 PM:



> Further, the JCL User Guide has a section labeled "National Language
> Support And Internationalization", in which the following excerpt
> appears:
> 
> "NLS internationalization SHOULD be strongly considered for used for
> fatal, error, warn, and info messages. It is generally considered
> optional for debug and trace messages. 
> 
> Perhaps more direct support for internationalizing log messages can be
> introduced in a future or alternate version of the Log interface."
> 
> So it seems to me that the suggestion from IBM is not necessarily making
> the "thin bridge" any fatter.  Rather, it is simply following up on what
> is already suggested in the User Guide.



***
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]

The discovery process is a concern.  It's not trivial.  It only gets worse 
over time.  Enough said.

To be quite frank, here is what I believe to be the right strategy

1.  Implement a "workable" discovery mechanism where it belongs... in 
Commons Discovery.

2.  Have the existing LogFactory attempt to use Commons Discovery, and 
failing that fall back to...

3.  Clean up [for 2.0] the LogFactory mechanisms... simplify, simplify, 
simplify...  minimize, minimize..  I'm advocating regressive behavior with 
this statement.  This is necessary to "fix" the problems we had with 
1.0.x.

If you *want* solid discovery, the price should be bringing that it your 
environment.  I think a simple J2SE [single classloader] discovery is 
reasonable for the LogFactory, should hit the 80% user mark.  For those 
that want the 20%, let's please solve the problem in Discovery, and resist 
duplicating the solution in many Jakarta components.




simon <[EMAIL PROTECTED]> wrote on 12/09/2004 05:18:37 PM:

> On Fri, 2004-12-10 at 11:52, Martin Cooper wrote:
> > This sure doesn't sound like Commons Logging would be "an ultra-thin
> > bridge between different logging libraries" any more.
> > 
> > http://jakarta.apache.org/commons/logging/
> > 
> > This sounds more like a different package altogether. IMO, we have
> > enough trouble as it is with some people resisting adding a dependency
> > on Commons Logging that the last thing I want to see is a bunch more
> > functionality - and size - added to this component.
> 
> It looks to me like the changes will be just a couple of fairly simple
> new classes for globalisation, and a couple of trivial methods to
> support the JSR-47 "finer" log level. I don't think that's a big deal.
> 
> The "repackaging" of the logging library to separate the "interfaces"
> from the log-library-specific adapters is something that has already
> been proposed on this list, and clearly will *reduce* jar file size
> (though add complexity by forcing users to deploy two jars instead of
> one).
> 
> It is less clear how the proposed changes to the 'discovery' process
> would affect code size/complexity, and I agree a close eye needs to be
> kept on this to make sure commons-logging stays the "thin bridge" it was
> always meant to be.
> 
> Regards,
> 
> Simon
> 

***
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]

Good point.  Which is why we elected to begin our proposal as an extension 
to the existing Log interface, rather than making any immediate 
adaptations to it.  Any component based on the the existing interface [JCL 
1.0.X] will be able to execute with JCL 2.  Likewise, component developers 
make choose to remain in their corner of the world.

For users using Log implementations, or the Log interface methods on an 
EnterpriseLog implementation, the runtime overhead wouldn't be any 
different than it is today.

For those components that are ready to step out to a broader audience, and 
are looking for the desired level of function [and there IS a need, these 
requirements aren't just hot air], there is the additional methods.  As a 
real example, the axis community uses globalized messages.  They translate 
in-place prior to every log invocation that they want globalized... and it 
gets VERY old having to implement something like:

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

Never mind that every component that needs to globalize needs to come up 
with something on their own that is equivalent to Message.  Yes, the 
proposal takes this a few steps further, but it's an improvement:

 log.error(ThisClass.getName(), "thisMethodName", "MSGID", new String 
{arg1, ..., argN } );


Size... is that really an issue?

Perhaps so.  And this IS the time to reconsider alternate packaging.  I 
don't want Log4J and Avalan and I-don't-know-what enabled simply because 
they're all packaged with commons-logging.jar.  And the impls happen to be 
on a classpath.  As a component developer, the packaging should NOT 
matter.  As an application developer, I want to use commons-logging in MY 
environment, and don't need the overhead of all the other logger impls 
laying around [size or runtime discover tricks].  Most importantly, I want 
to *know* which logger implementation I'm going to be using.

One proposal is that we build N number of utility commons jar files, one 
for each logger implementation we support:

 commons-logging-log4j.jar
 commons-logging-avalon.jar
 commons-logging-jsr47.jar

etc.  The standard LogFactory/Log & EnterpriseLogFactory/EnterpriseLog 
interface/classes would be packaged with each.  A generic

commons-logging-core.jar

would contain ONLY the core classes, and would be reasonably useful in 
those environments where the application developer [infrastructure owner] 
would be providing their own implementation.  And.. I suppose for those 
who really WANT it all... they can still have the old commons-logging.jar 
file.


Martin Cooper <[EMAIL PROTECTED]> wrote on 12/09/2004 04:52:15 PM:

> This sure doesn't sound like Commons Logging would be "an ultra-thin
> bridge between different logging libraries" any more.
> 
> http://jakarta.apache.org/commons/logging/
> 
> This sounds more like a different package altogether. IMO, we have
> enough trouble as it is with some people resisting adding a dependency
> on Commons Logging that the last thing I want to see is a bunch more
> functionality - and size - added to this component.
> 
> --
> Martin Cooper



> >B.2.  Fix fragile configuration problems.
> > 
> >  This area is more discussion, and less is
> >  currently represented in any proposed
> >  interface/class changes.
> > 
> >  Two things can/should be done here:
> > 
> >  a. tighten the 'discovery' process to minimize
> > "non-deterministic behavior".
> > 
> >  b. give *serious* consideration to how we
> > package commons logging.
> > 
> >- Declarative Configuration:
> > 
> >  Now, regarding 'fragile' configurations, a
> >  declarative configuration driven programmatically
> >  by the "target framework" into which a component
> >  might be installed/executing within would resolve
> >  a lot of the problems.
> > 
> >  In such a solution, we should guard against
> >  any multiplicity of such "declarations".  Throw
> >  exception, something, to if multiple occur in the
> >  runtime.
> > 
> >- ONE Configuration
> > 
> >  Even in a dynamic "discovery" process, we
> >  should adopt a strategy of allowing only ONE
> >  configuration to exist.
> > 
> >  - In absense of an explicit declaration, if there
> >is only one logger available, use it.
> > 
> >  - In absense of an explicit declaration, if there
> >are multiple loadable loggers available,
> >then configurable preference list could be
> >consulted.  Such a list MUST NOT be packaged with
> >the commons logging distributable.
> > 
> >  - In presense of an explicit declaration, if that
> >is NOT available, then fall back to a default
> >logger (preference list or simple logger) AND
> >log warning/info.
> >

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

[Richard Sitze]

I'm very interested in any insight into how to leverage the existing i18n 
project... that said, I have no interest in mandating use of i18n. Commons 
logging is lightweight, needs to remain as lightweight as possible.

For i18n, my perspective is that Jakarta Commons Logging (JCL) must adhere 
to the most simple/standard mechanisms supported by Java.  If your 
application uses i18n on a GUI, then perhaps Jakarta i18n is reasonable 
for that use... but I'm not sure it's appropriate for the behind the 
scenes work that logging represents.




[EMAIL PROTECTED] wrote on 12/09/2004 03:46:26 PM:

> Have you had a look at the commons-sandbox i18n project? This might be a
> solution to enable localized logging with fine grained messages.
> Methods would look like this:
> LogMessage logMessage = new LogMessage("someMessakeKey", new String[] {
> "param1", "param2" }

In particular, I don't like having to new up an object here.  What have I 
gained?  Please remember that for logging implementations that support 
i18n, the expectation is that we pass the key & params straight through.


> EnterpriseLogger.info(String messageName, LogMessage logMessage);
> Log message class could have similar attributes as the ErrorMessage 
class.
> Regards,
> Daniel
> 
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > 
[mailto:[EMAIL PROTECTED]
> > Im Auftrag von Richard Sitze
> > Gesendet: Donnerstag, 9. Dezember 2004 21:21
> > An: [EMAIL PROTECTED]
> > Betreff: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > IBM would like to open a discussion within the Jakarta commons 
community
> > on evolving the Jakarta Commons Logging (JCL) API's to support 
Enterprise
> > level logging functionality.  We recognize the value that a "logging
> > implementation independent API" brings to open source component
> > development, and would like to work with the community to accomplish 
this
> > goal.
> > 
> > We present a set of requirements as a baseline for the discussion, a
> > proposal for meeting these requirements, a number of points of 
discussion,
> > and attached are two Java source files that correspond to the 
discussion
> > below.
> > 
> > 
> > Requirements:
> > 
> >   We recognize that the community has an overriding
> >   requirement:
> > 
> > A.1.  Evolution: maintain compatibility with the
> >   current LogFactory/Log interfaces.
> > 
> >   We have ONE primary requirement:
> > 
> > A.2.  Globalization
> > 
> > 
> >   Having opened the door, we'd also like to propose a few
> >   other requirements:
> > 
> > B.1.  Functional alignment with JSR-47 concepts.
> > 
> > B.2.  Fix fragile configuration problems - Currently
> >   the user has NO idea which impl is in effect.
> >   All the default/fall back behavior means that in
> >   the end we have an apparent non-deterministic
> >   logging implementation.  Errors in config file
> >   names, classpath errors, classpath ordering,
> >   etc., can all change the behavior... with no
> >   idea which is in effect.
> > 
> >   The fundamental problem with the current factory
> >   is that it is dependent on "passively"
> >   identifying a logging implementation.
> > 
> >   We propose one solution below, but would ask a
> >   more general question: any new bright ideas?
> > 
> > 
> > 
> > Proposals:
> > 
> > A.1.  Evolution: Maintain compatibility with the
> >   current LogFactory/Log interfaces BY PROVIDING
> > 
> >   - Drop-in replacement of commons-logging.jar
> > version 1.x with a version 2.x variant.
> > 
> >   - EnterpriseLogFactory class that extends the
> > existing LogFactory.
> > 
> >   - EnterpriseLog interface that extends the
> > existing Log interface.
> > 
> > 
> > A.2.  Globalization.  For the enterprise logging we
> >   need globalized messages (translated) for message
> >   level logging API's: info, warn, error, fatal.
> >   The remaining logging API's are considered trace
> >   level logging API's, and do not require message
> >   translation.
> > 
> >   - For message level logging, support globalized
> > variants on the new EnterpriseLog interface:
> > 
> &g

[logging] Common Logging 2.0? EnterpriseLog.java

[Richard Sitze]

package org.apache.commons.logging;

/**
 * An advanced logging interface abstracting logging APIs.  This 
interface
 * extends the simple logging interface decribed by [EMAIL PROTECTED] Log}, 
providing
 * the following additional capabilities:
 * 
 * the ability to capture internationalized data (e.g. translated 
messages)
 * ability to identify the software capturing the event 
 * (i.e. class and method name)
 * ability to capture the execution of a program by tracing method 
entry
 * and exit.
 * 
 * This interface is instantiated using [EMAIL PROTECTED] 
EnterpriseLogFactory}. 
The
 * classes that implement this interface must have a constructor that 
takes 
 * a single String parameter representing the "name" of this 
 * EnterpriseLog.  Please note that a specific implementation 
of
 * Commons Logging can choose to support either the simple logging 
interface
 * (represented by [EMAIL PROTECTED] Log}) or the advanced logging interface 
(represented 
 * by this interface).  A user of a Common Logging implementation that 
supports
 * only the simple logging interface will not be able to instantiate a 
 * EnterpriseLog.  Conversely, a user of a Common Logging 
 * implementation that supports the advanced logging interface will be 
able to 
 * instantiate either a Log or EnterpriseLog.
 *
 * Configuration of the underlying logging system will generally be 
done
 * external to the Logging APIs, through whatever mechanism is supported 
by
 * that system.
 *
 */

public interface EnterpriseLog extends Log 
{
// - Logging 
Properties


// - Logging 
Methods

/**
 *  Log a locale-specific (internationalized) error message with 
 * no message substitution values. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle)
 */

public void error(Class  clazz,
  String method,
  String key);

   /**
 *  Log a locale-specific (internationalized) error message with 
 * one message substitution value. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle))
 * @param parmThe value to insert into the message text 
 *(e.g. when formatting a Java massage (@link 
MessageFormat))
 */

public void error(Class  clazz,
  String method,
  String key,
  Object parm);

   /**
 *  Log a locale-specific (internationalized) error message with 
 * multiple message substitution values. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle))
 * @param parms   The list of values to insert into the message text 
 *(e.g. when formatting a Java massage (@link 
MessageFormat))
 */

public void error(Classclazz,
  String   method,
  String   key,
  Object[] parms);


/**
 *  Log a locale-specific (internationalized) fatal error message 
with 
 * no message substitution values. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle)
 */

public void fatal(Class  clazz,
  String method,
  String key);

   /**
 *  Log a locale-specific (internationalized) fatal error message 
with 
 * one message substitution value. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle))
 * @param parmThe value to insert into the message text 
 *(e.g. when formatting a Java massage (@link 
MessageFormat))
 */

public void fatal(Class  clazz,
  String method,
  String key,
  Object parm);

   /**
 *  Log a locale-specific (internationalized) fatal error message 
with 
 * multiple message substitution values. 
 *
 * @param clazz   The class containing the me

[logging] Common Logging 2.0? EnterpriseLogFactory.java

[Richard Sitze]

[Looks like the attachments got lost...  Let's try them separately]


package org.apache.commons.logging;


/**
 * Factory for creating [EMAIL PROTECTED] Log} and [EMAIL PROTECTED] 
EnterpriseLog} 
instances, 
 * with discovery and configuration features similar to that employed by 
 * standard Java APIs such as JAXP.
 *
 * Please note that a specific implementation of Commons Logging can 
choose 
 * to support either the simple logging interface defined by [EMAIL PROTECTED] 
Log}) 
or 
 * the advanced logging interface defined by [EMAIL PROTECTED] EnterpriseLog}.  
A 
user 
 * of a Common Logging implementation that supports only the simple 
logging 
 * interface will not be able to instantiate a EnterpriseLog. 
 
 * Conversely, a user of a Common Logging implementation that supports the 

 * advanced logging interface will be able to instantiate either a 
Log
 * or EnterpriseLog.
 *
 */
public abstract class EnterpriseLogFactory extends LogFactory{


// - Manifest 
Constants

// --- 
Constructors


/**
 * Protected constructor that is not available for public use.
 */
protected EnterpriseLogFactory()
{
// TBD
}


// - Public 
Methods

/**
 * Construct (if necessary) and return a EnterpriseLog 
instance,
 * using the factory's current set of configuration attributes.
 *
 * NOTE - Depending upon the implementation of
 * the EnterpriseLogFactory you are using, the 
 * EnterpriseLog instance you are returned may or may 
 * not be local to the current application, and may or may not be 
 *returned again on a subsequent call with the same name argument.
 *
 * @param name Logical name of the EnterpriseLog instance 
to be
 *  returned (the meaning of this name is only known to the underlying
 *  logging implementation that is being wrapped)
 * 
 * @param resourceBundleName Logical name of the repository to use 
when
 *  retrieving internationalized message text (the meaning of this 
name is 
 *  only known to the underlying logging implementation that is being 
wrapped,
 *  but a common usage would be the name of a Java resources bundle)
 *
 * @exception LogConfigurationException if a suitable Log
 *  instance cannot be returned
 */
public abstract EnterpriseLog getEnterpriseInstance(String name,
 String resourceBundleName) throws LogConfigurationException;


// - Static 
Methods


/**
 * Construct (if necessary) and return a 
EnterpriseLogFactory
 * instance, using the following ordered lookup procedure to determine
 * the name of the implementation class to be loaded.
 * 
 * The org.apache.commons.logging.LogFactory system
 * property.
 * The JDK 1.3 Service Discovery mechanism
 * Use the properties file commons-logging.properties
 * file, if found in the class path of this class.  The 
configuration
 * file is in standard java.util.Properties format 
and
 * contains the fully qualified name of the implementation class
 * with the key being the system property defined above.
 * Fall back to a default implementation class
 * 
(org.apache.commons.logging.impl.EnterpriseLogFactoryImpl).
 * 
 *
 * NOTE - If the properties file method of identifying the
 * EnterpriseLogFactory implementation class is utilized, 
all of the
 * properties defined in this file will be set as configuration 
attributes
 * on the corresponding EnterpriseLogFactory 
instance.
 *
 * @exception LogConfigurationException if the implementation class is 
not
 *  available or cannot be instantiated.
 */
public static EnterpriseLogFactory getEnterpriseFactory() 
  throws LogConfigurationException
{
// TBD
}


/**
 * Convenience method to return a named enterprise logger, without the 

 * application having to care about factories.
 *
 * @param name Logical name of the EnterpriseLog instance 
to be
 *  returned (the meaning of this name is only known to the underlying
 *  logging implementation that is being wrapped)
 * 
 * 
 * @param resourceBundleName Logical name of the repository to use 
when
 *  retrieving internationalized message text (the meaning of this 
name is 
 *  only known to the underlying logging implementation that is being 
wrapped,
 *  but a common usage would be the name of a Java resources bundle)
 *
 * @exception LogConfigurationException if a suitable Log
 *  instance cannot be returned
 */
public static EnterpriseLog getEnterpriseLog(String name, String 
resourceBundleName)
throws LogConfigurationException
{

return (getEnterpr

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

[Richard Sitze]

IBM would like to open a discussion within the Jakarta commons community 
on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise 
level logging functionality.  We recognize the value that a "logging 
implementation independent API" brings to open source component 
development, and would like to work with the community to accomplish this 
goal.

We present a set of requirements as a baseline for the discussion, a 
proposal for meeting these requirements, a number of points of discussion, 
and attached are two Java source files that correspond to the discussion 
below.


Requirements:

  We recognize that the community has an overriding
  requirement:

A.1.  Evolution: maintain compatibility with the
  current LogFactory/Log interfaces.

  We have ONE primary requirement:

A.2.  Globalization


  Having opened the door, we'd also like to propose a few
  other requirements:

B.1.  Functional alignment with JSR-47 concepts.

B.2.  Fix fragile configuration problems - Currently
  the user has NO idea which impl is in effect.
  All the default/fall back behavior means that in
  the end we have an apparent non-deterministic
  logging implementation.  Errors in config file
  names, classpath errors, classpath ordering,
  etc., can all change the behavior... with no
  idea which is in effect.

  The fundamental problem with the current factory
  is that it is dependent on "passively"
  identifying a logging implementation.

  We propose one solution below, but would ask a
  more general question: any new bright ideas?



Proposals:

A.1.  Evolution: Maintain compatibility with the
  current LogFactory/Log interfaces BY PROVIDING

  - Drop-in replacement of commons-logging.jar
version 1.x with a version 2.x variant.

  - EnterpriseLogFactory class that extends the
existing LogFactory.

  - EnterpriseLog interface that extends the
existing Log interface.


A.2.  Globalization.  For the enterprise logging we
  need globalized messages (translated) for message
  level logging API's: info, warn, error, fatal.
  The remaining logging API's are considered trace
  level logging API's, and do not require message
  translation.

  - For message level logging, support globalized
variants on the new EnterpriseLog interface:

info(Class callingClass,
 String methodName,
 String messageID);

info(Class callingClass,
 String methodName,
 String messageID,
 Object messageParam);

info(Class callingClass,
 String methodName,
 String messageID,
 Object[] messageParams);

same for warn, error, fatal.


  - Utility function to support formatting for
other purposes (exception strings):

formatMessage(String messageID);
formatMessage(String messageID, Object messageParam);
formatMessage(String messageID, Object[] messageParams);


  Ensure that component has an assurance that the
  message will be translated/formatted as expected:

  - ALL message translation must be done using
the standard java.util.ResourceBundle class,
or functional equivalent.

  - ALL message formatting must be done using
the standard java.text.MessageFormat class,
or functional equivalent.

  - Bind a ResourceBundleName to an EnterpriseLog
instance.

  - Expects that the named ResourceBundle is
available to the logger.


B.1.  Functional alignment with JSR-47 concepts.
  JSR-47 has 3 trace levels:  FINE, FINER, FINEST
  JCL has 2 trace levels defined today: debug,
  trace which corresponds to JSR-47 FINE and
  FINEST in the current implementation.

  The JSR-47 FINER level has no corresponding APIs
  in JCL.  The expectation is that the FINER level
  be used for "class/method level flow".

  We propose a set of API's that would correspond
  to the JSR-47 FINER LEVEL, but more generally
  support the "class/method level flow" logging.

  - enter(Class clazz, String methodName,
  Object message);

  - enter(Class clazz, String methodName,
  Object methodArg,
  Object message)

  - enter(Class clazz, String methodName,
  Object[] methodArgs,
  Object message);

  - exit(Class clazz, String methodName,
 Object result,
 Object message);

  - exit(Class clazz, String methodName,
 Throwable exception,
   

[GUMP@brutus]: Project commons-discovery (in module jakarta-commons) success

[Richard Sitze]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-discovery *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-discovery.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/gump_work/build_jakarta-commons_commons-discovery.html
Work Name: build_jakarta-commons_commons-discovery (Type: Build)
Work ended in a state of : Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/discovery]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
-
  [javadoc]  //- groupContext::Object Cache
  [javadoc]  // Cache : HashMap
  [javadoc]  // Key   : groupContext (String)
  [javadoc]  //Value : Object
  [javadoc]  
  [javadoc]  When we 'release', it is expected that the caller of the 'release'
  [javadoc]  have the same thread context class loader... as that will be used
  [javadoc]  to identify cached entries to be released."
  [javadoc] "[this was ServiceDiscovery12..."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "[this was ServiceDiscovery12... the 1.1 versus 1.2 issue
  [javadoc]  has been abstracted to org.apache.commons.discover.jdk.JDKHooks]
  [javadoc]  
  [javadoc]  Implement the JDK1.3 'Service Provider' specification"
  [javadoc] "Represents a Service Programming Interface (spi)."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "Represents a Service Programming Interface (spi)"
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:136:
 warning - @param argument "level" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:152:
 warning - @param argument "logLevel" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:278:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:302:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:492:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:523:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:601:
 warning - @param argument "attribute" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverSingleton.java:327:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverSingleton.java:360:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jaka

[GUMP@stormcrow]: Project commons-discovery (in module jakarta-commons) success

[Richard Sitze]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-discovery *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-discovery.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/gump_work/build_jakarta-commons_commons-discovery.html
Work Name: build_jakarta-commons_commons-discovery (Type: Build)
Work ended in a state of : Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/discovery]
CLASSPATH: 
/usr/java/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
-
  [javadoc]  // Key   : groupContext (String)
  [javadoc]  //Value : Object
  [javadoc]  
  [javadoc]  When we 'release', it is expected that the caller of the 'release'
  [javadoc]  have the same thread context class loader... as that will be used
  [javadoc]  to identify cached entries to be released."
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/Service.java:50:
 warning - The first sentence is interpreted to be:
  [javadoc] "[this was ServiceDiscovery12..."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "[this was ServiceDiscovery12... the 1.1 versus 1.2 issue
  [javadoc]  has been abstracted to org.apache.commons.discover.jdk.JDKHooks]
  [javadoc]  
  [javadoc]  Implement the JDK1.3 'Service Provider' specification"
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/SPInterface.java:36:
 warning - The first sentence is interpreted to be:
  [javadoc] "Represents a Service Programming Interface (spi)."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "Represents a Service Programming Interface (spi)"
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:136:
 warning - @param argument "level" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:152:
 warning - @param argument "logLevel" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:278:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:302:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:492:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:523:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:601:
 warning - @param argument "attribute" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discov

[GUMP@stormcrow]: Project commons-discovery (in module jakarta-commons) success

[Richard Sitze]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-discovery *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-discovery.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/gump_work/build_jakarta-commons_commons-discovery.html
Work Name: build_jakarta-commons_commons-discovery (Type: Build)
Work ended in a state of : Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/discovery]
CLASSPATH: 
/usr/java/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
-
  [javadoc]  // Key   : groupContext (String)
  [javadoc]  //Value : Object
  [javadoc]  
  [javadoc]  When we 'release', it is expected that the caller of the 'release'
  [javadoc]  have the same thread context class loader... as that will be used
  [javadoc]  to identify cached entries to be released."
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/Service.java:50:
 warning - The first sentence is interpreted to be:
  [javadoc] "[this was ServiceDiscovery12..."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "[this was ServiceDiscovery12... the 1.1 versus 1.2 issue
  [javadoc]  has been abstracted to org.apache.commons.discover.jdk.JDKHooks]
  [javadoc]  
  [javadoc]  Implement the JDK1.3 'Service Provider' specification"
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/SPInterface.java:36:
 warning - The first sentence is interpreted to be:
  [javadoc] "Represents a Service Programming Interface (spi)."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "Represents a Service Programming Interface (spi)"
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:136:
 warning - @param argument "level" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:152:
 warning - @param argument "logLevel" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:278:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:302:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:492:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:523:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:601:
 warning - @param argument "attribute" is not a parameter name.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discov

[GUMP@brutus]: Project commons-discovery (in module jakarta-commons) success

[Richard Sitze]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-discovery *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [commons-discovery.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/gump_work/build_jakarta-commons_commons-discovery.html
Work Name: build_jakarta-commons_commons-discovery (Type: Build)
Work ended in a state of : Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/discovery]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
-
  [javadoc]  //- groupContext::Object Cache
  [javadoc]  // Cache : HashMap
  [javadoc]  // Key   : groupContext (String)
  [javadoc]  //Value : Object
  [javadoc]  
  [javadoc]  When we 'release', it is expected that the caller of the 'release'
  [javadoc]  have the same thread context class loader... as that will be used
  [javadoc]  to identify cached entries to be released."
  [javadoc] "[this was ServiceDiscovery12..."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "[this was ServiceDiscovery12... the 1.1 versus 1.2 issue
  [javadoc]  has been abstracted to org.apache.commons.discover.jdk.JDKHooks]
  [javadoc]  
  [javadoc]  Implement the JDK1.3 'Service Provider' specification"
  [javadoc] "Represents a Service Programming Interface (spi)."
  [javadoc] This sentence is different from what would be generated using 
-breakiterator: 
  [javadoc] "Represents a Service Programming Interface (spi)"
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:136:
 warning - @param argument "level" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/log/SimpleLog.java:152:
 warning - @param argument "logLevel" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:278:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:302:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:492:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:523:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverClass.java:601:
 warning - @param argument "attribute" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverSingleton.java:327:
 warning - @param argument "properties" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/DiscoverSingleton.java:360:
 warning - @param argument "spiClass" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-common

[GUMP@brutus]: jakarta-commons/commons-discovery success

[Richard Sitze]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project commons-discovery *no longer* has an issue.
Project State : 'Success'

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [commons-discovery.jar] identifier set to project name
 -INFO- Enable "verbose" output, due to 1 previous error(s).
 -INFO- No license on redistributable project with outputs.


The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-discovery/gump_work/build_jakarta-commons_commons-discovery.html
Work Name: build_jakarta-commons_commons-discovery (Type: Build)
State: Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/discovery]
CLASSPATH : 
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar-
  [jar] adding directory org/apache/commons/discovery/log/
  [jar] adding entry org/apache/commons/discovery/log/DiscoveryLogFactory.class
  [jar] adding entry org/apache/commons/discovery/log/SimpleLog.class
  [jar] adding entry org/apache/commons/discovery/package.html
  [jar] adding directory org/apache/commons/discovery/resource/
  [jar] adding entry org/apache/commons/discovery/resource/ClassLoaders.class
  [jar] adding entry 
org/apache/commons/discovery/resource/DiscoverResources$1.class
  [jar] adding entry org/apache/commons/discovery/resource/DiscoverResources.class
  [jar] adding entry 
org/apache/commons/discovery/resource/ResourceDiscoverImpl$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/ResourceDiscoverImpl.class
  [jar] adding directory org/apache/commons/discovery/resource/classes/
  [jar] adding entry 
org/apache/commons/discovery/resource/classes/DiscoverClasses$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/classes/DiscoverClasses.class
  [jar] adding entry 
org/apache/commons/discovery/resource/classes/ResourceClassDiscoverImpl$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/classes/ResourceClassDiscoverImpl.class
  [jar] adding directory org/apache/commons/discovery/resource/names/
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverMappedNames$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverMappedNames.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInAlternateManagedProperties$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInAlternateManagedProperties.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInDictionary$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInDictionary.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInFile$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInFile.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInManagedProperties$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInManagedProperties.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInSystemProperties$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverNamesInSystemProperties.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/DiscoverServiceNames.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/NameDiscoverers$1.class
  [jar] adding entry 
org/apache/commons/discovery/resource/names/NameDiscoverers.class
  [jar] 

[GUMP@brutus]: jakarta-commons/commons-discovery prerequisite failed

[Richard Sitze]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project commons-discovery *no longer* has an issue.
Project State : 'Prerequisite Failed', Reason 'Build Failed'

Full details are available at:

http://brutus.apache.org:8080/gump/jakarta-commons/commons-discovery/index.html

That said, some snippets follow:


The following annotations were provided:
 -INFO- Sole jar [commons-discovery.jar] identifier set to project name
 -INFO- Prerequisite failed with reason build failed



To subscribe to this information via syndicated feeds:
 RSS: http://brutus.apache.org:8080/gump/jakarta-commons/commons-discovery/rss.xml
 Atom: http://brutus.apache.org:8080/gump/jakarta-commons/commons-discovery/atom.xml


--
Produced by Gump 2.0.3-alpha-0002.
[Run (20040524 15:00:12, brutus:brutus-public:20040524 15:00:12)]
http://brutus.apache.org:8080/gump/index.html
http://brutus.apache.org:8080/gump/options.html

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

FileUpload-Modifying request content-type

[Richard Sitze]

Return Receipt
   
Your  FileUpload-Modifying request content-type
document   
:  
   
was   Richard Sitze/Austin/IBM 
received   
by:
   
at:   05/12/2004 08:52:40 CDT  
   

RE: commons-logging & classloading (continued)

[Richard Sitze]

So, I'm coming into this a bit late and all, and I know a few others have 
been looking at this over the past few weeks...  hope this does more than 
just add fuel to the fire.

commons-discovery was created to address the classloader usage patterns 
being discussed : how to discover an implemention for a given interface.

Commons-discovery was explicitly designed to be a general replacement for 
LogFactory - I'd like to see LogFactory eliminated entirely from 
commons-logging.

On the surface, you may not find that commons-discovery does anything more 
than LogFactory.  Underneath, it's a set of tools that let you setup your 
own patterns.


That said:

LogFactory was designed to work in a J2EE environment by dropping it into 
the "Server" level.  It also functions quite well embedded into the 
application.

As is being discovered, it doesn't work so well if you want some hybrid of 
that.  It's a known problem, and I'm sorry to say I simply don't see ANY 
straight forward fix available - particularly by working with the 
ClassLoaders.  The following was proposed:


 if (!Log.class.isAssignableFrom(logClass)) {
 // Plan B. Bend over backwards to continue
 Class logInterface =
 LoadClass("org.apache.commons.logging.Log");
 if (logInterface == null) {
 throw new LogConfigurationException
 ("Log interface can not be found");
 }
 if (!logInterface.isAssignableFrom(logClass))
 throw new LogConfigurationException
 ("Class " + logClassName + " does not implement Log");
 }


The situation:
- logClass bundled into a webapp.
- commons-logging bundled into a webapp, with "local" configuration 
settings.
- commons-logging bundled into the webserver, with "global" configuration 
settings.

Clearly logClass, which implemented the "local" copy of Log, failed to 
load because it doesn't implement the (expected) "global" copy of Log.
Calling LoadClass("org.apache.commons.logging.Log") will only return the 
"global" copy - classloaders (by design) always defer to parent 
classloaders.  In this case, the web-app classloader gives the server 
classloader first crack at loading Log.  You simply don't have anyway to 
"see" the local copy that's the fundamental problem.

***
Richard A. Sitze
IBM WebSphere WebServices Development



It's a kind of growing pain with the success of Commons.
Some servers have some commons jars while others not. In the
application you always include jars you needed. At the end of
day, situation like that seems inevitable, not just logging,
not mention the version problem. 

Is it possible some standard be set or a classloader component
in Commons?

- sean

--- Ojares Rami EINT <[EMAIL PROTECTED]> wrote:
> Well put Norbert.
> I think that since classloading and threads are such complex
> issues there should be a way to not use the pattern
> of loading the implementation from thread's context classloader.
> (Hint to Craig :)
> 
> - rami
> 
> >-Original Message-
> >From: Norbert Klose [mailto:[EMAIL PROTECTED] 
> >Sent: Thursday, October 30, 2003 12:21 PM
> >To: [EMAIL PROTECTED]
> >Subject: commons-logging & classloading (continued)
> >
> >
> >Hello,
> >
> >i currently use Tomcat 4.1.27 bundled with commons-logging 
> >1.0.3. My own webapp i'm working on also uses commons-logging, 
> >so i include a copy of the jar file into the WEB-INF/lib 
> >directory to be protable to other servlet containers that does 
> >not include the commons-logging package. I found some 
> >discussions in the mail archive that is about commons-logging 
> >and its class loading strategy. But as i could not found an 
> >anwser to my problem, i post my problem here again, hoping to 
> >get a hint for a solution (or maybe to settle on a new consens).
> >
> >The problem is, that when tomcat wants to anser a HTTPS 
> >request it instantiates a Http11ConnectionHandler which 
> >processes the connection. 
> >The Http11ConnectionHandler instance itself instantiates a 
> >JSSE14Support class which itself instantiates a 
> >org.apache.commons.logging.Log implementation class. Because 
> >the thread that runs the Http11ConnectionHandler has the 
> >WebappClassloader of my web application as its 
> >context class loader (which ist used by commons-logging to 
> >load the Log implementation (logClass)), BUT the 
> >org.apache.commons.logging.Log interface itself was loaded 
> >from the Common StandardClassLoader, the predicate in 
> >LogFactoryImpl.getLogConstructor()
> >
> >  (!Log.class.isAssignableFrom(logClass))
> >
> >is false, so that LogFactoryImpl.getLogConstructor() throws a 
> >LogConfigurationException. Because both classes are loaded 
> >from different classloaders. 
> >
> >IMHO what commons-logging MUST ensure to work correctly is, 
> >that the logClass is loaded from the same classloader than the 
> >Log.class is and this is not guaranteed by the cur

Re: Logging packaging questions

[Richard Sitze]

Hence the need to maintain commons-logging.jar AS-IS.

We already HAVE commons-logging-api.jar, we simply need to add new jar 
files for each implementation 'flavor'.  Consideration could be given to 
including a commons-logging.properties file that configures the logger, 
though there are pro/cons with that.

***
Richard A. Sitze
IBM WebSphere WebServices Development



Nicolas Mailhot wrote:

>>If the split goes through,
>>the situation is likely to arise where log4j is used as a 
commons-logging
>>backend, but since log4j is not configured by default, all the 
commons-logging
>>logging will be automatically brocken. Come to think of it, this is 
exactly
>>what we have now, without the split, and looks like we are not happy :)
> 
> Since this is exactly what we have now the split would not make it
> worse.

It will. Much worse.
What we have now can be fixed by removing the 'Class-Path:' entries.
After that, only those who put log4j on classpath *manually* and do
not configure it will have their logging brocken.
If the split happens, any naive user who believes that he can use
log4j as a backend for commons-logging and does not install
SimpleLog - or installs it, but does not override the alternatives so
that log4j is *not* used - will have his logging brocken.

> So there is no reason not to go for the split because we know the
> other benefits we'll get.

I think that working setup is preferrable to better modularization :)
I'd like to have both, but it looks that we can't.
Unless you persuade log4j developers to make it self-configured.

> It is commons-logging responsibility IMHO to do initial log4j
> configuration if its used - commons is supposed to hide the backend so
> why should we know something about it ?

This question is best answered by the bug 13201 description
(http://issues.apache.org/bugzilla/show_bug.cgi?id=13201):

   I am requesting that the code added to Log4JCategory in
   commons-logging-1.0.1 that sets up a default initialization in log4j be
   removed.

   Why? When I put 1.0.1 in place of 1.0, I started getting extraneous
   messages logged to the console. Subsequent research led me to the new
   initialization code in Log4JCategory. The problem is in the way the
   initialization code tries to decide if log4j has been configured. It
   assumes that the root category has been configured with an appender. I
   happen to have a log4j properties configuration that doesn't configure
   an appender, so the initialization code couldn't tell that log4j had
   been configured, it created the default root appender, and I started
   getting the extraneous messages.

   I realize there are easy workarounds for my particular problem, but I
   believe this presents a more philosophical issue. Quoting from the
   commons-logging api org.apache.commons.logging package description:

   "The basic principle is that the user is totally responsible for the
   configuration of the underlying logging system. Commons-logging should
   not change the existing configuration."

   The code in question directly violates this expressly stated principal
   and is inappropriate. Allowing this code to remain opens a Pandora's 
box
   of attempts to configure the underlying logger, which should be 
resisted
   based on the above principal.

> [ and this part is related to the crossposted message so please add
> these remarks to the common thread ]

Done!


Regards,

Leonid Dubinskly.


-
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]

VOTE ? protocol

[Richard Sitze]

Interesting...  If you have commons-committer status, your vote is 
binding.  Is there a protocol for someone to declare themselves 
non-binding?

***
Richard A. Sitze
IBM WebSphere WebServices Development



+1 (non-binding)

- robert

On Thursday, April 3, 2003, at 05:41 PM, Richard Sitze wrote:

> [OK, Let's try the more formal VOTE subject line :-)  Sorry for the
> duplicate note.]
>
> commons-discovery has been fairly stable for a while (one recent bug 
fix,
> and a few in the past), and I'd like to cut a 0.2 release.
>
> Please VOTE  for or against.
>


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

Re: [logging][VOTE] Proposal To Release Commons Logging 1.0.3

[Richard Sitze]

+1

***
Richard A. Sitze
IBM WebSphere WebServices Development



Commons-logging has recently undergone some bug fixes, documentation
cleanup, and the addition of additional unit test suites to simulate its
use within servlet containers and other environments with hierarchies of
class loaders.  The code is stable, and many projects would like to have a
formal release that incorporates the recent changes.

I hereby propose that we release the HEAD branch code in commons-logging
as version 1.0.3 (because we haven't broken any public APIs, or added
anything significant that would warrant a 1.1 version number).  The
proposed release notes for this release are attached to this message.  I
will be release manager if no one else wants to, but it would be fine with
me if someone else volunteered.

Here's my +1.

Craig McClanahan

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]

VOTE: commons-discovery release 0.2

[Richard Sitze]

[OK, Let's try the more formal VOTE subject line :-)  Sorry for the 
duplicate note.]

commons-discovery has been fairly stable for a while (one recent bug fix, 
and a few in the past), and I'd like to cut a 0.2 release.

Please VOTE  for or against.




POSITION: There has not been any discussion on discovery in a while 
now.  There are components [axis] that prereq commons-discovery that need 
a formal release of this prereq.  SOOoo.. as before:  If you have 
requirements, you are welcome to discuss them for a future release, but 
unless there is something hiding in the shadows I don't want to hold up a 
quick point release.


***
Richard A. Sitze
IBM WebSphere WebServices Development

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

discovery: vote for 0.2

[Richard Sitze]

Discovery has been very stable for a while now, with a few bug fixes 
It's a prereq for at least one project (Axis) that is getting ready to cut 
a new release.

I'd like to ask for a vote to cut a 0.2 release,


and a volunteer with sufficient karma to help me out.  I'd be happy to do 
what busy work needs to be done, but I've got very limited access in the 
Apache domain.


[is anyone in the open-source community using discovery, other than Axis? 
I'm using it for my own projects, but I'm curious]



***
Richard A. Sitze
IBM WebSphere WebServices Development

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

Re: [logging] Moving Towards A 1.0.3 Release

[Richard Sitze]

Summary: +1 on all issues

> Folks,
> 
> A lot of people are interested in an updated release of commons-logging
> that incorporates post-1.0.2 bugfixes.  In order to do so, we need to
> address the following outstanding bug reports -- I've described my own
> recommendations on dealing with them in indented paragraphs marked
> "CRM>>>" -- we need to come to consensus on the actions to take and them
> implement them in order to reach a 1.0.3 release quickly:
> 
> 
> 13201 Remove default log4j configuration
> 
>   CRM>>> I agree.  The code in Log4JLogger.initialize() violates
>   the basic scope of commons-logging, which states  "The basic
>   principle is that the user is totally responsible for the
>   configuration of the underlying logging system.  Commons-logging
>   whould not change the existing configuration."  As an alternative
>   to the application explicitly configuring things, logging
>   implementations should provide auto-configuration mechanisms
>   (for Log4J, that means recognizing the existence of the
>   "log4j.properties" resource and using it.)
> 
>   Similar code exists in the deprecated Log4JCategoryLogger class,
>   and should be removed from there as well.

+1

> 
> 
> 16880 Language specs violation in Commons Logging 1.0.2 in class
>   LogFactoryImpl
> 
>   CRM>>> I haven't investigated this one yet, but we'll want to
>   make sure we do not introduce any security-related vulnerabilities
>   in dealing with it.

+1

> 
> 
> 17561 LogFactoryImpl.guessConfig overrides configuration
> 
>   CRM>>> As the bug report points out, we currently mess up the
>   Log4J configuration even if you explicitly select SimpleLog.
>   Dealing with 13201 will fix part of that; as a further step I
>   would like to deprecate Log4jFactory and the way that it is
>   created as a proxy for the standard LogFactoryImpl.  It seems
>   to add zero value, and only obfuscates the code -- anything
>   specific that we need should be possible in the base class.
>   I'd like to see Log4jFactory removed in 1.1, because
>   LogFactoryImpl should be capable of doing everything.

+1

> 
> 
> 17894 Unable to configure commons-logging SimpleLog for a webapp
> 
>   Other than the part about getting the manifest created
>   correctly (which I've fixed), this *appears* to be a duplicate
>   of 17561.

Agreed.

> 
> What do you guys think on these issues?


***
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [commons-logging] Is log4j the only choice if found on the classpath?

[Richard Sitze]

I think some work was done to alleviate the 'forced' Log4J... are you 
using a released build, or a nightly build?  If the first, try a 
nightly... if it still happens (re)open a bugzilla bug report.


***
Richard A. Sitze
IBM WebSphere WebServices Development


Hi:

I am trying to find out how to define that a specific Logger is used 
while using the
commons-logging framework.

I started to define a commons-logging.properties file and put it on my 
applications
classpath. The test properties file looks as follows (BTW: is there a 
place in the
API doc where the commons-logging.properties file and all the possible 
keys
is explained?):

#org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl 


org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
#org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JCategoryLog 


#org.apache.commons.logging.Log=org.apache.commons.logging.impl.LogKitLogger 


#org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog

I appears to me that I can switch between the Jdk14Logger and the 
LogKitLogger as long
as no log4j jar file is on the path.  As soon as I put  log4j-1.2.4.jar 
(or log4j.jar
and log4j-core.jar) in addition on the path, changes in the properties 
file indicating that
a different logger from log4j should be used, as for  example 
LogKitLogger, seem
not to be noticed by the commons-logging framework.

Am I missing something?  I would like to be able to switch between all 
the three if necessary
without removing log4j jars from the path.

Andreas


-
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] Class Loading Problems

[Richard Sitze]

I'm partially responsible for the current classloading scheme.  I'd sure 
like to understand what your problems are.  Can you describe a 
step-by-step scenario that demonstrates what you see happening, and why 
you think it's not correct?

Likewise, for any code changes that you make, please help me understand 
what you are doing differently, and why.  Remember that it's important 
that you preserve current behavior (fixing if broken is OK, changing 
because you don't agree with it isn't... admittedly a subtle distinction, 
but one I've gone to some effort to adhere to).

***
Richard A. Sitze
IBM WebSphere WebServices Development




Hi,
this misunderstanding is not any kind of problem,
I yust do not know all convensions and have problems with my english.
 I will try to fix this problem on weekend, it must trivial to solve for
some of situations,
 proposed solution "class loader priority" will not wok 100%, but it will
work then "ThreadContextClassLoader" is
the "SystemClassLoader". All problems I have saw on user lists (problem in
logging and lang) are caused by
 "SystemClassLoader" = "ThreadContextClassLoader", but
"AppLicationClassLoader" != "SystemClassLoader".



Howdy,

>>>can I add myself to logging comiters list and fix this problem ?
>>
>> No, you can't make yourself a committer.  You are welcome to open bug
>
>A commons committer can participate in any common component.

I know -- it was my misunderstanding.  I should've checked if the person
was already committer for other commons things.  I apologize ;)

Yoav Shapira
Millennium ChemInformatics




This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, 
proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


-
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] Adding jndi java:env support

[Richard Sitze]

I'll wait for the formal call to vote before I start voting, BUT I support 
the following:

+  release a 1.0.3 before any major code changes
+  JNDI

-  NO API changes
-  NO new runtime dependencies, and I'd like to be able to build, even if 
I cannot test it.



***
Richard A. Sitze




sounds like a good plan.

this sounds (to me) like a change big enough to call for a new (major?) 
version.

(i'm not a cvs expert) but from what i can see there have been some small 
changes since the last release. maybe a quick bugfix 1.0.3 release would 
be a good idea before adding making this change.

- robert

On Thursday, December 12, 2002, at 03:29 AM, Costin Manolache wrote:

> Based on Ceki's email - I think it would be a good idea to add
> this mechanism in the default logging factory.
>
> My proposal is to insert a lookup for
>
>  java:comp/env/CommonsLoggingFactory
>
> at the top of the discovery chain. If such a factory exists, it'll
> be used to create the logger. If not, we'll continue with the
> normal mechanism.
>
> The big downsize is that we'll add a compile dependency on
> JNDI ( the code can catch ClassNotFound - and run even if
> JNDI is not present ).
>
> This will allow containers using commons-logging to better enforce
> isolation between apps.
>
> In addition, I think we should add an optional "domain name" prefix.
> If such a prefix is set ( for example in 
> java:comp/env/CommonsLoggingDomain)
> then it'll be added in front of every log name that is created.
>
> For example, if the container will set myHost:8080/myApp/ as a prefix,
>  logs created in that app will be named:
>   myHost:8080/myApp/org.apache.
>
>
> As a note, web.xml allows you to define and set a number of
> jndi entries. This could also be used to allow user-based tuning,
> but in general the container settings should be able to
> take preference .
>
> Costin
>
>
>
>
> --
> To unsubscribe, e-mail:    org>
> For additional commands, e-mail:  org>
>


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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: What should we do about sandbox ? RE: License and copyright issues

[Richard Sitze]

I like playing in the sandbox, I just don't like to be unpleasantly 
surprised on what I find buried within.  I can see both sides, but it does 
appear to be IMPERATIVE that the catbox... err  sandbox be kept clean for 
visitors.

We simply cannot become, or even appear to become, a public repository for 
copyrighted code.

***
Richard A. Sitze


Costin Manolache wrote:
> Martin Cooper wrote:
> 
> 
>>I found a few things not yet mentioned:
>>
>>1) In codec\Metaphone.java, "Copyright 1997, William B. Brogden", which 
is
>>clearly a problem.
>>
>>2) In scaffold, numerous instances of "Copyright (c) 2002 Synthis
>>Corporation.", also clearly a problem.
> 
> 
> Acording to jakarta-commons rules, the sandbox is just a CVS repository 
> where experiments may happen. 
> 
> I see it similar with commiters using their homes or public_html
> pages on jakarta - or with the commiters cvs repository.
> 
> The sandbox is open to any jakarta commiter.
> 
> The question is: do we have to police it and monitor all forms
> of activities that happen on apache servers ? Because as far as 
> I can see, there is no difference between a file placed by a 
> jakarta commiters on his public_html or home and the files
> in commons-sandbox. 
> 
> We made it very clear that sandbox code can't be released,
> and the fact that it is accessible using public cvs and 
> viewcvs is similar with the public_html files.

These were my thoughts exactly, and partly why I only noticed the 
potential issue (probably non-issue) with jxpath, and not those in codec 
and scaffold.  I was only looking in jakarta-commons, not 
jakarta-commons-sandbox.

> I would propose to ask the sandbox to be removed from viewcvs
> and the eventually discuss what to do about the public cvs. 
> As a way to protect ourself. I wouldn't mind if this is voted
> down :-) 

Certainly a possibility, but that kinda kills the ability to create a 
community which is the whole point to the sandbox.

> What do you think about this issue ? Any other proposed solutions ?

Shouldn't we bring this question up with the jakarta PMC?  Since this is 
really a legal question, I would think the board, via the PMC, should 
have the say on how this should be handled.

michael




--
To unsubscribe, e-mail:   <
mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-dev-help@;jakarta.apache.org>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[discovery] Design Question: Qualifying service names?

[Richard Sitze]

To locate a service (based on sun's current mechanism) we can drop a file 
whose name is the service interface and content is the name of the 
implementation:

 META-INF/services/package.ServiceName:
  implPackage.ServiceNameImpl

One 'scheme' for locating a service is have the implementation provide a 
(possibly static) method which can be queried to see if the implementation 
is appropriate, by some criteria:

  boolean 
implPackage.ServiceNameImpl.isEnvironmentallyFriendly(someContext)

The problem with this approach is that (a) if it's not the right service, 
then why load it, and (b) it may not even be loadable if dependent classes 
are not available.  (b) is really a nit, but why load a (possibly) bunch 
of services + dependencies if we don't need them?

So, I'm considering a way to qualify the service in such a way that we can 
pre-determine if it's really what we want.  Here are a few schemes for 
discussion:

1.  The most flexible:  For every impl class, look for a implHelper class 
that we can load & query:
  boolean 
implPackage.ServiceNameImplHelper.isEnvironmentallyFriendly(someContext)

2.  [optionally] qualify the name of the of a service, i.e. one of the 
following:
 META-INF/services/qualifier/package.ServiceName
 META-INF/services/package.ServiceName.qualifier

 META-INF/services/package.ServiceName:
  implPackage.ServiceNameImpl  # qualifierType=qualifier

For example, consider a Socket factory that could be qualified by a 
protocol:
 META-INF/services/http/package.ServiceName
 META-INF/services/https/package.ServiceName

 META-INF/services/package.ServiceName.http
 META-INF/services/package.ServiceName.https

 META-INF/services/package.ServiceName:
  implPackage.ServiceNameImplHttp  # protocol=http
  implPackage.ServiceNameImplHttps  # protocol=https

Thoughts from the community?


***
Richard A. Sitze
IBM WebSphere WebServices Development

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Issues with logging

[Richard Sitze]

Please open a defect in Bugzilla for this.


***
Richard A. Sitze
IBM WebSphere WebServices Development


Hi,
 This issue has already been raised long time back under the subject 
"Support for JDK1.4 Logger in Commons Package". It was told that time that 
it will be fixed. But the fix has not happened yet. Hope it is resolved 
quickly.

Krupa.

-Original Message-
From: Giacomo Pati [mailto:[EMAIL PROTECTED]]
Sent: 30 September 2002 16:47
To: [EMAIL PROTECTED]
Subject: Issues with logging



Hi all

We've dicovered an issue with the current commons-logging code (1.0.2).

We have a servlet depoyed into a Servlet engine which has a log4j.jar in
its common classpath but our servlet (using commons-logging) need to used
logkit. We tried to use the system property
"org.apache.commons.logging.Log" set to
"org.apache.commons.logging.impl.LogKitLogger" as suggested with no luck.

So, we looked into the code and found that the constructor of
org.apache.commons.logging.impl.LogFactoryImpl is doing the following:

public LogFactoryImpl() {
super();
guessConfig();
}

and the guessConfig does:

protected void guessConfig() {
if( isLog4JAvailable() ) {
proxyFactory = null;
try {
Class proxyClass=
loadClass(
"org.apache.commons.logging.impl.Log4jFactory" );
if (proxyClass != null) {
proxyFactory = (LogFactory)proxyClass.newInstance();
}
} catch( Throwable t ) {
; // ignore
}
}
// other logger specific initialization
// ...
}

Admittedly if have no idea what the proxyFactory is used for but for us
this means commons-logging does not respect the system property suggested
to use any other logging kit if there is a log4j in the classpath
anywhere.

Is this intentional?

By commenting the 'guessConfig()' call from the constructor we could solve
our problems but I'd really like to hear your oppinions about it.

Cheers

Giacomo


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

This message, together with any attachments, is
confidential and is intended only for the use of
the addressee(s) and may contain information
which is covered by legal, professional or other
privilege. If you are not the intended recipient,
please destroy this E-mail and inform us.

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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Released Commons Logging 1.0.2

[Richard Sitze]

The Commons team is proud to announce a release of Commons Logging 1.0.2. 
This release introduces bug fixes for various NullPointerExceptions, and 
Security Exceptions in J2EE environments.

Binary/Source: 
http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2

Additional Information:  http://jakarta.apache.org/commons/logging.html

***
Richard A. Sitze


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] VOTE for cutting release 1.0.2

[Richard Sitze]

I'll close the vote this evening.  Unless the tallies change, I'll try to 
get a release out by end-of-day tomorrow.

***
Richard A. Sitze
IBM WebSphere WebServices Development


now that richard is listed as a committer and we have a release manager, 
here's my +1.

(by my count that's +3 (binding) votes now. which - i think - is enough to 

get started.)

- robert

On Thursday, September 26, 2002, at 04:48 PM, Scott Sanders wrote:

> Richard has volunteered, with the exception of daedalus issues, which I
> volunteered to help him with.
>
> Scott
>
>> -Original Message-
>> From: robert burrell donkin
>> [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, September 26, 2002 4:05 AM
>> To: Jakarta Commons Developers List
>> Subject: Re: [logging] VOTE for cutting release 1.0.2
>>
>>
>> On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote:
>>
>> 
>>
>>> 4.  Folks, if you are committers, please update the commons-logging
>>> STATUS.html document with your name, and that includes myself! :-)
>>
>> 1. i'd suggestion that people do this ASAP since (by my
>> count) there are
>> not enough votes from committers for the required quorum.
>>
>> 2. a release manager is required. that person needs to be a
>> committer (see
>> 1) and (probably) needs an account on daedelus. any volunteers?
>>
>> (FYI my vote would be binding...)
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:commons-dev-> [EMAIL PROTECTED]>
>> For
>> additional commands,
>> e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]
.
> org>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
.
> org>
>


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



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

Re: [logging] VOTE for cutting release 1.0.2

[Richard Sitze]

I volunteer to be the release manager.

This is also my explicit vote for cutting 1.0.2:  +1

By my count, current binding votes are at:

+12  (scott sanders, richard sitze)
+00
-10


***
Richard A. Sitze
IBM WebSphere WebServices Development


On Thursday, September 26, 2002, at 03:07 PM, Richard Sitze wrote:

> I volunteer(ed) [I wouldn't ask for a vote without doing that :-]  I 
will
> happily stand aside if there is anyone with experience who would prefer 
to
> do it.

i'm happy about you acting as release manager but it's probably better to 
say it explicitly.

we gathered quite a few -1's (on this principle) the last time we tried to 

release without explicitly naming a release manager.

- robert


> I DON'T have an account on daedelus, but I've had a number of offers 
from
> various folks, who do, that are willing to help me with that.
>
>
> ***
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
> On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote:
>
> 
>
>> 4.  Folks, if you are committers, please update the commons-logging
>> STATUS.html document with your name, and that includes myself! :-)
>
> 1. i'd suggestion that people do this ASAP since (by my count) there are
> not enough votes from committers for the required quorum.
>
> 2. a release manager is required. that person needs to be a committer 
(see
>
> 1) and (probably) needs an account on daedelus. any volunteers?
>
> (FYI my vote would be binding...)
>
> - robert
>
>
> --
> To unsubscribe, e-mail:   <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]
.
> org>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
.
> org>
>


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



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

RE: [logging] VOTE for cutting release 1.0.2

[Richard Sitze]

We need a quick release to enable us to pull this into another Jakarta 
Project that has a dependency on this change (AXIS), that is expected to 
be released VERY soon.  This is one reason I'm asking for a 1.0.2 release, 
instead of a more significant 1.1 release... for whatever THAT's worth.

So, with that in mind, and keeping in mind that I don't own this project, 
nor am I in charge... and I hate to say this:

1.  Steven, you don't appear to be a committer, so while your vote & 
concerns are noted, your vote isn't binding.  Regardless, you are welcome 
to submit a patch if you have one.

2.  If you ARE a committer, then fix it. :-) Soon.  :-)   Please.

3.  Steven Downey, by same token I find no evidence to support the 
validity your vote - so you cancel each other out one way or another.

[The 'committer' list is out-of-date for commons-logging.  I know that I 
am a committer, and I've never added my name to the list.  I find Scott 
Sanders & myself on the list of commons contributors.. which is the best 
resource I can find to identify valid voters]

4.  Folks, if you are committers, please update the commons-logging 
STATUS.html document with your name, and that includes myself! :-)



***
Richard A. Sitze
IBM WebSphere WebServices Development


I'm voting -1 because the issue I raised with the initialization of
log4j added in 1.0.1 has not been resolved.

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103057245722889&w=
2


I assume this is a valid reason for a -1 vote. If not, someone please
correct me (like I really need to say that :)  )

Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."


> -Original Message-
> From: Richard Sitze [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, September 25, 2002 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: [logging] VOTE for cutting release 1.0.2
> 
> 
> There were some changes that went into commons-logging post 
> 1.0.1.  Not a 
> lot of noise since then, so I'm presuming that things are 
> stable.  These 
> changes are prereqs for AXIS 1.0 (scheduled for next week), 
> so we would 
> like to get them in a formal release.
> 
> I'm a bit reluctant to call for a VOTE out of the blue, but 
> there's no 
> better way to learn than to try :-)
> 
> So, this is a call for VOTE to cut a release 1.0.2.  Target 
> date is this 
> weekend.
> 
> I'd be happy to do what I can towards managing the release.
> 
> 
> 
> ***
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> --
> To unsubscribe, e-mail: 
> <mailto:commons-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 



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



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

Re: discovery error

[Richard Sitze]

This does not appear to be a discovery error.

That said, there are a few NPE exception in commons-logging 1.0.1.  And 
these were fixed.  Please a recent nightly build and see if that corrects 
this problem.

***
Richard A. Sitze
IBM WebSphere WebServices Development


Hi all,
I'using the last discovery release.
I have the following error :

Sep 18 17:03:47 2002: java.lang.ExceptionInInitializerError:
java.lang.NullPointerException
at java.util.Hashtable.get(Hashtable.java, Compiled Code)
at
org.apache.commons.logging.LogFactory.getCachedFactory(LogFactory.java,
Compiled Code)
at 
org.apache.commons.logging.LogFactory.getFactory(LogFactory.java,
Compiled Code)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java,
Compiled Code)
at com.accor.util.logger.LogFactory.getLog(Unknown Source)

my  LogFactory  class


package com.accor.util.logger;

import org.apache.commons.discovery.tools.DiscoverSingleton;
import org.apache.commons.logging.Log;


/**
 * @author Olivier lamy
 */
public class LogFactory {
/**
 * permet de retrouver le logger dans le context
 */
private static final org.apache.commons.logging.LogFactory logFactory 
=
(org.apache.commons.logging.LogFactory)

DiscoverSingleton.find(org.apache.commons.logging.LogFactory.class,

org.apache.commons.logging.LogFactory.FACTORY_PROPERTIES,

org.apache.commons.logging.LogFactory.FACTORY_DEFAULT);

public static Log getLog(String name) {
return logFactory.getLog(name);
}
}





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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Scamp: Source Control Abstraction

[Richard Sitze]

Have you taken a look at how Eclipse handles this?

http://eclipse.org


***
Richard A. Sitze
IBM WebSphere WebServices Development


Following some interesting discussions on the Maven list, I'd like to
propose starting an SCM abstraction project, tentatively named Scamp. 

Proposed Goal:
Scamp is a Source Control Manager abstraction layer. It provides a 
standard
interface to SCM systems allowing common source control operations such as
checkin/checkout, labelling/tagging, reading changelogs and diffs.

Initial design goals:
-- expose a stable SCM interface contract for consuming applications 
(Maven,
Ant, etc).
-- provide extensible infrastructure for specific SCM implementations.
-- configuration driven implementations
-- file system independent
-- supports multiple projects, multiple/distributed source providers

Architecture:
My initial thoughts are to utilize a combination of AbstractSCMFactory and 
a
SourceControlManager interface with concrete implementations of both. We
might possible need some secondary classes representing projects,
connections, and filesystems, but I'm not sure on those yet.

0.1 Release Goals/Requirements:
-- First version of SCM Interface, focused on primary/core SCM operations
-- AbstractSCMFactory
-- Stubbed concrete factories for cvs/vss/vfs?
-- exception infrastructure

Any thoughts, feedback, requirements, design, existing code pointers, etc
very welcome. Potential participants more than welcome!!

Thanks, Lance


Lance Weber
Chief Architect
CareEnhance Services & Systems
McKesson Health Solutions


 
 
 
___
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 

for the sole use of the intended recipient(s) and may contain confidential 

and privileged information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 

contact the sender by reply e-mail and destroy all copies of the original 
message.

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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Logging: more classloader problems.

[Richard Sitze]

my comments below 

***
Richard A. Sitze[EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development



  costinm@covalent

  .net To:  Jakarta Commons
Developers List 

  06/06/2002 04:54 cc:

  PM   Subject: RE: Logging: more
classloader problems.
  Please respond

  to "Jakarta

  Commons

  Developers List"






On Thu, 6 Jun 2002, Richard Sitze wrote:

> I'm new this part of the game (classloaders), but I'm becoming more and
> more aware of the issues.  So, I'd like to add to your question some
bigger
> issues surrounding the placement of commons-logging & other apache
> utility/libraries in web application servers:

There is a simple answer: dump everything in rt.jar, and you'll have no
class loader problems :-) But we have to wait for JDK1.5 for that.

> 1.  How do we find & overload factories (I think this is the issue you
set
> forth below)?
> 2.  How do we find & overload resources in general (NLS
> messaging/properties files)?
> 3.  How do we configure (NOT System properties as we do today - that has
> global implications)?

For 2 - it is _essential_ to use the right ResourceBundle method ( the
one with a loader parameter ), and pass the thread class loader ( or the
loader for a class that is in the same .jar - same thing ). That doesn't
work if you want JDK1.1 compat, in which case all .properties must be in
the top loader.

For 1 - that's pretty much what JAXP and commons-logging is doing to
locate the factory. Or you can use an explicit setting - but make
sure you use the thread class loader for everything.

I don't understand 3, but in general System properties shouldn't be
used for anything but simple apps ( i.e. not in a server env ).
A simple config file ( .properties or xml ) should be used. Of course,
System props are a quick fix and are probably ok for special cases,
but don't expect them to scale.


> The fundamental problem I have is how do we sync classloader mechanisms
> with other algorithms in common use (including the logger):  try resource
> named "resource", then try resouce named "package.resource".  This last
one
> conflicts with classloader in application servers because what we get is:
>  1.  Classloader(s) look for "resource" in application context
>  2.  Classloader(s) look for "resource" in system context
>  3.  Classloader(s) look for "package.resource" in application
context
>  4.  Classloader(s) look for "package.resource" in system context

Not sure who is doing this - are you talking about resource bundles or
something else ? Most packages I know look for a single name.

To get a different behavior you must look explicitely in the class
loaders ( but remember that a child will ask the parent ).


It was my understanding that the logic now in LogFactoryImpl::loadClass was
doing just this.  Was this explained to me incorrectly?



Costin

>
> but what we want is:
>
>  1.  Classloader(s) look for "resource" in application context
>  2.  Classloader(s) look for "package.resource" in application
context
>  3.  Classloader(s) look for "resource" in system context
>  4.  Classloader(s) look for "package.resource" in system context
>
> I think we may need to design a solution, and - of course - provide an
> implementation as part of the commons project.  If there are answers out
> there, I'd like to see them in a developers guide (common-doc - general
> guidelines?)
> 
>
> ***
> Richard A. Sitze[EMAIL PROTECTED]
> CORBA Interoperability & WebServices
> IBM WebSphere Development
>
>
>
> [EMAIL PROTECTED]
> To:  Jakarta Commons Developers List <[EMAIL PROTECTED]>
> 06/06/2002 01:08
> cc:  List Tomcat-Dev <[EMAIL PROTECTED]> PM
> Subject: Logging: more classloader problems.
> Please respond to "Jakarta  Commons Developers List"
>
>
>
>
>
>
>
> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed in
> a child loader ( like WEB-INF/lib ).
>
> What happens:
> - the factory uses the thread class loader to check if the log4j (
> or any other impl. ) exists ( and it does ).
>
> - it creates an instance of the Logger adapter. This will be created
> using parent loader ( the one that loads commons-logging ).
>
> - the Logger instanc