You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/08/26 22:46:07 UTC
[general] logging
(probably flamebait)
Why do so many of our components require logging of some form or another?
(usually commons-logging).
I can see why a micro-framework like Digester might be nice to have
debugging statements, and might want an error system better than
Exceptions as the rules can be tricky to write sometimes, but for a simple
component-library like beanutils it seems like overkill. Even if we were
using java.util.logging, it would still seem like overkill for a library
to require logging.
The following all depend on logging. Seems like a lot:
beanutils
betwixt
chain
configuration
digester
el
httpclient
jexl
jxpath
latka
launcher
math
modeler
validator
(sandbox)
cli
messenger
periodicity
resources
scaffold
sql
threadpool
vfs
xo
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 30 Aug 2004, at 23:10, Simon Kitching wrote:
> On Mon, 2004-08-30 at 21:22, robert burrell donkin wrote:
>> i am suspect that it would be possible to use byte-code engineering to
>> wire up alternative implementations. the logging code wouldn't be
>> stripped but rather a new implementation would be wired in. of course,
>> the problem with this is that users would need to re-enhance the
>> library rather than reconfigure if they wanted to change targets.
>
> I also think that dynamically generating the logging "bridge" would be
> worth experimenting with. And it would be a cool project! I've had this
> in the back of my mind for a while, and hope to look into this
> sometime,
> but it won't be in the next few months.
yep same with me :)
so many cool projects i'd like to kickstart but only so much energy...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-08-30 at 21:22, robert burrell donkin wrote:
> i am suspect that it would be possible to use byte-code engineering to
> wire up alternative implementations. the logging code wouldn't be
> stripped but rather a new implementation would be wired in. of course,
> the problem with this is that users would need to re-enhance the
> library rather than reconfigure if they wanted to change targets.
I also think that dynamically generating the logging "bridge" would be
worth experimenting with. And it would be a cool project! I've had this
in the back of my mind for a while, and hope to look into this sometime,
but it won't be in the next few months.
And while this might help with classloader issues, it will not remove
the need for a commons-logging library.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 27 Aug 2004, at 21:17, Henri Yandell wrote:
> +1. I don't see any advantage to the commons-monitor approach as it
> would
> still involve a dependency and would probably be harder to code than
> simple logging.
>
> Is there an easy way to produce a jar stripped of its logging parts?
> Any
> of the bytecode-manip/aspect systems that could do it?
depends on what you mean by stripped. i'm not sure that this is the
angle to approach the problem from. i'd like to say a few words on
classloading issues before moving on to the way i'd approach the
problem.
the main reason why there are lots of classloader issues reported seems
to be that there are a lot of folks out there who are used to modern
containers taking all the pain out of classloading. a generation or two
ago, you needed to have an understanding of classloader issues. modern
containers are much better. most of the classloader issues reported are
easily solved by tinkering with the classpath. given the complexity of
the problem and the fact that commons-logging is used by many
containers, it does a reasonable job and i'd be very surprised if a
better general solution could be found. (i would prefer the option to
be able to switch off reporting configuration exceptions (at the
command line) since i (now) agree with ceki that a failure in the
logging framework should not stop a library working.)
the way i'd approach the problem is that the real cause of problems is
that commons-logging is too big and too general. with hindsight, a much
more minimal library (2 public classes only) together with an optional
jar of implementations would have been better.
what is really needed are a variety of implementations for different
circumstances. for example:
1 a minimal footprint implementation logging
2 a J2SE implementation without the tricky J2EE classloader stuff
3 a no-logging implementation
4 a monitor-adapted implementation
5 single logging system only implementations
using replacement, binary compatible jars containing re-implementation
have been advocated many times but don't seem very popular. one
possible reason for this is the fact that this approach requires users
to solve their own classloader issues.
i am suspect that it would be possible to use byte-code engineering to
wire up alternative implementations. the logging code wouldn't be
stripped but rather a new implementation would be wired in. of course,
the problem with this is that users would need to re-enhance the
library rather than reconfigure if they wanted to change targets.
anyone interested in pursuing this idea?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Henri Yandell <ba...@generationjava.com>.
+1. I don't see any advantage to the commons-monitor approach as it would
still involve a dependency and would probably be harder to code than
simple logging.
Is there an easy way to produce a jar stripped of its logging parts? Any
of the bytecode-manip/aspect systems that could do it?
Hen
On Fri, 27 Aug 2004, matthew.hawthorne wrote:
> Craig McClanahan wrote:
> > On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <ao...@bellsouth.net> wrote:
> >
> >>However I think this issue is one we can resolve if we generalize the
> >>problem using monitors and event notification. Logging is just a
> >>specific application for a monitor. Paul Hammant described this in the
> >>NoLogging wiki here:
> >>
> >>http://wiki.apache.org/avalon/AvalonNoLogging
> >>
> > The problem I have with this general approach is that it trades a
> > dependency on a logging adapter for a requirement to create code that
> > responds to the individual event handling interface for every single
> > library I'm using.
>
> This is only a requirement if you have a need to get details about what
> the library is doing. In most cases, I don't -- but I obviously can't
> speak for
> everyone else.
>
> Logging (via commons-logging) has become pretty much a standard part
> of development for me. But for those for which this is not the case,
> I don't see implementing a simple monitor interface to handle events
> as much harder than putting log4j into the classpath, setting up
> the config file to log for the desired class, etc. Either way requires
> some extra work.
>
>
> > The primary benefit of having all the libraries
> > conform to a common logging API (whatever it is) is *precisely* the
> > fact that I, as an application developer, don't have to go through
> > that kind of pain -- I just configure the logging levels and
> > destinations, using my favorite logging implementation (using a single
> > log for everything, separate logs for functional areas, requesting the
> > appropriate amount of detail on a global or local level, or whatever
> > else I want), and it just works.
>
> I guess I always saw the primary benefit and purpose of commons-logging
> to be
> a bit simpler than this. I thought it was to allow libraries to log,
> while allowing the user
> to choose which logging library is used -- nothing more.
>
> However, what you've said may indeed be true -- the issue is whether
> what works best
> for you works best for everyone else. I'm fine with everything using
> commons-logging,
> but that's because I use it in pretty much every project I'm on anyway.
> For others,
> it may cause more of an inconvenience, although I'm not quite sure how.
> Too many jars, maybe.
>
>
> > My concern can be dealt with by implementing a commone event monitor
> > API that all the libraries use, so that I can still implement a
> > generic event listening framework ... but isn't that, in spirit
> > (although not in the proposed implementation manner), exactly what
> > commons-logging already does?
>
> Very true -- but I don't think this is what anyone was proposing.
> If this was the idea, then, just as you've said, I think commons-logging
> does the job fine.
>
> No need for commons-monitor or anything weird like that...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by "matthew.hawthorne" <ma...@apache.org>.
Craig McClanahan wrote:
> On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <ao...@bellsouth.net> wrote:
>
>>However I think this issue is one we can resolve if we generalize the
>>problem using monitors and event notification. Logging is just a
>>specific application for a monitor. Paul Hammant described this in the
>>NoLogging wiki here:
>>
>>http://wiki.apache.org/avalon/AvalonNoLogging
>>
> The problem I have with this general approach is that it trades a
> dependency on a logging adapter for a requirement to create code that
> responds to the individual event handling interface for every single
> library I'm using.
This is only a requirement if you have a need to get details about what
the library is doing. In most cases, I don't -- but I obviously can't
speak for
everyone else.
Logging (via commons-logging) has become pretty much a standard part
of development for me. But for those for which this is not the case,
I don't see implementing a simple monitor interface to handle events
as much harder than putting log4j into the classpath, setting up
the config file to log for the desired class, etc. Either way requires
some extra work.
> The primary benefit of having all the libraries
> conform to a common logging API (whatever it is) is *precisely* the
> fact that I, as an application developer, don't have to go through
> that kind of pain -- I just configure the logging levels and
> destinations, using my favorite logging implementation (using a single
> log for everything, separate logs for functional areas, requesting the
> appropriate amount of detail on a global or local level, or whatever
> else I want), and it just works.
I guess I always saw the primary benefit and purpose of commons-logging
to be
a bit simpler than this. I thought it was to allow libraries to log,
while allowing the user
to choose which logging library is used -- nothing more.
However, what you've said may indeed be true -- the issue is whether
what works best
for you works best for everyone else. I'm fine with everything using
commons-logging,
but that's because I use it in pretty much every project I'm on anyway.
For others,
it may cause more of an inconvenience, although I'm not quite sure how.
Too many jars, maybe.
> My concern can be dealt with by implementing a commone event monitor
> API that all the libraries use, so that I can still implement a
> generic event listening framework ... but isn't that, in spirit
> (although not in the proposed implementation manner), exactly what
> commons-logging already does?
Very true -- but I don't think this is what anyone was proposing.
If this was the idea, then, just as you've said, I think commons-logging
does the job fine.
No need for commons-monitor or anything weird like that...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 27 Aug 2004 20:53:41 -0400, Alex Karasulu <ao...@bellsouth.net> wrote:
> On Fri, 2004-08-27 at 15:13, Craig McClanahan wrote:
<snip/>
> > My concern can be dealt with by implementing a commone event monitor
> > API that all the libraries use, so that I can still implement a
> > generic event listening framework ... but isn't that, in spirit
> > (although not in the proposed implementation manner), exactly what
> > commons-logging already does?
>
> I disagree but I see where you're comming from. The fact that you're
> logging makes you specific to a particular monitoring implementation so
> this is not a "generic event listening framework". Furthermore I'm not
> recommending we DO have a "generic event listening framework." Each
> monitor is specific to the library. I'm just saying let libraries
> publish/expose the notable events that external systems can respond to.
> The monitor interface for any library, component etcetera accomplishes
> that. What the user does with that is their business. Also while
> exposing that monitor interface give the user interested in logging a
> head start by offing a logging monitor based on C-L outside of your core
> jar.
If there isn't a standard way of doing this, doesn't that mean that
each component (library) will end up doing it slightly differently?
That, in turn, means that each component will have its own (optional)
additional library that needs to be included just to add logging for
that library. This seems like it would result in an explosion of jars
- much worse than everyone just using Commons Logging, which is now so
ubiquitous in any case.
It also means that, if we decide to migrate a class from one component
to another, the logging (sorry, monitoring ;) scheme needs to change
to adhere to the conventions of the new component.
Finally - and perhaps my biggest worry - performance would be
negatively impacted by the additional calls, and by the lack of any
ability to check the logging level before actually logging. (You can't
have methods like isDebugEnabled() in a general purpose monitoring
interface, after all.)
IMHO, logging should be easy and cheap, so that developers put it
wherever it could be useful. I can't tell you how many times I've
wished that 3rd party code had more logging in it so that I could
figure out why things weren't working as I expected.
--
Martin Cooper
>
> Regards,
> Alex
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Alex Karasulu <ao...@bellsouth.net>.
On Fri, 2004-08-27 at 15:13, Craig McClanahan wrote:
> On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <ao...@bellsouth.net> wrote:
> >
> > However I think this issue is one we can resolve if we generalize the
> > problem using monitors and event notification. Logging is just a
> > specific application for a monitor. Paul Hammant described this in the
> > NoLogging wiki here:
> >
> > http://wiki.apache.org/avalon/AvalonNoLogging
> >
>
> The problem I have with this general approach is that it trades a
> dependency on a logging adapter for a requirement to create code that
> responds to the individual event handling interface for every single
> library I'm using. The primary benefit of having all the libraries
Actually the logging monitor implementation would still be implemented
by the library developer as an optional peice. The user would not have
to write a logging implementation for the monitor interface. Say for
example the library is the dbcp library. It might expose the following
interface as part of the library:
public interface DBCPMonitor
{
connectionAcquired( ConnectionPool pool, Connection conn );
connectionReleased( ConnectionPool pool, Connection conn );
}
Obviously this is a very simplistic example so please bear with me. The
library developer would have a setMonitor(DBCPMonitor) or even an
addMonitor(DBCPMonitor) method on the connection pool class for example
to set the monitor used. The developer might implement a do-nothing
monitor adapter for the default monitor to use. When these events occur
in the connection pool the methods are called instead of handling
logging.
Outside of the distribution jar the developer might include several
monitor implementations one of which can be a C-L based logging monitor
which is dependent on C-L obviously. So the user does not have to
implement the logger at all.
Someone (possibly James Strachan) actually used this pattern in the
ThreadPool package within the Jakarta Commons Sandbox here:
http://jakarta.apache.org/commons/sandbox/threadpool/apidocs/index.html
Take a look at the ThreadPoolMonitor interface and the
NullThreadPoolMonitor. I don't think the author actually implemented a
logging monitor here but they could have and not included it with the
core classes going into the jar.
> conform to a common logging API (whatever it is) is *precisely* the
> fact that I, as an application developer, don't have to go through
> that kind of pain -- I just configure the logging levels and
> destinations, using my favorite logging implementation (using a single
> log for everything, separate logs for functional areas, requesting the
> appropriate amount of detail on a global or local level, or whatever
> else I want), and it just works.
Yes it does work but not everyone wants the dependency. This is the
core problem. I personally don't mind having the commons-logging
dependency. Just making a recommendation to solve a recurring topic on
this list.
> My concern can be dealt with by implementing a commone event monitor
> API that all the libraries use, so that I can still implement a
> generic event listening framework ... but isn't that, in spirit
> (although not in the proposed implementation manner), exactly what
> commons-logging already does?
I disagree but I see where you're comming from. The fact that you're
logging makes you specific to a particular monitoring implementation so
this is not a "generic event listening framework". Furthermore I'm not
recommending we DO have a "generic event listening framework." Each
monitor is specific to the library. I'm just saying let libraries
publish/expose the notable events that external systems can respond to.
The monitor interface for any library, component etcetera accomplishes
that. What the user does with that is their business. Also while
exposing that monitor interface give the user interested in logging a
head start by offing a logging monitor based on C-L outside of your core
jar.
Regards,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <ao...@bellsouth.net> wrote:
>
> However I think this issue is one we can resolve if we generalize the
> problem using monitors and event notification. Logging is just a
> specific application for a monitor. Paul Hammant described this in the
> NoLogging wiki here:
>
> http://wiki.apache.org/avalon/AvalonNoLogging
>
The problem I have with this general approach is that it trades a
dependency on a logging adapter for a requirement to create code that
responds to the individual event handling interface for every single
library I'm using. The primary benefit of having all the libraries
conform to a common logging API (whatever it is) is *precisely* the
fact that I, as an application developer, don't have to go through
that kind of pain -- I just configure the logging levels and
destinations, using my favorite logging implementation (using a single
log for everything, separate logs for functional areas, requesting the
appropriate amount of detail on a global or local level, or whatever
else I want), and it just works.
My concern can be dealt with by implementing a commone event monitor
API that all the libraries use, so that I can still implement a
generic event listening framework ... but isn't that, in spirit
(although not in the proposed implementation manner), exactly what
commons-logging already does?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Alex Karasulu <ao...@bellsouth.net>.
Hiya,
BTW before I begin I wanted to say that C-L is simple and costs
relatively little. It does not tie a library to a logging
implementation and IMHO it gets far too much criticism for the
convenience it affords us. Its really an **adapter** for other logging
implementations and that's it (as Craig pointed out below). Perhaps its
the fact that this is a dependency on another jar that causes this issue
to come up repeatedly as opposed to logging itself. In the end I don't
know exactly why it is such a hot topic of debate.
However I think this issue is one we can resolve if we generalize the
problem using monitors and event notification. Logging is just a
specific application for a monitor. Paul Hammant described this in the
NoLogging wiki here:
http://wiki.apache.org/avalon/AvalonNoLogging
I think I brought this up before and forgive me for doing it again. If
this is annoying anyone I will not discuss it again. Perhaps I need the
cons against it once more. However I still do believe that this is the
best solution for now.
All a library needs to do is expose a monitor interface to publish the
notible events that may occur while the library is doing its thang. How
the monitor responds to events by logging them or otherwise is a matter
of implementation. A default do-nothing monitor adapter may be packaged
with the library instead of the dependency on C-L. Other monitor
interface implementations, not packaged with the core, can have a C-L
based logging monitor implementation (hence C-L dependency) that can be
used out of the box if desired. Dependencies are minimized, ugly
logging code is isolated away and all the parties concerned are happy.
Is this too idealistic a viewpoint? Perhaps. I guess I'm offering up
this approach yet again for others to correct me.
On Thu, 2004-08-26 at 17:17, Craig McClanahan wrote:
> You are asking two separate but related quesitons here, so they should
> be addressed separately.
>
> (1) Should libraries depend on *any* logging library?
I believe there should be no dependency at all although I'm comfortable
with a dep on C-L. People just get too passionate about dependencies
now adays. So why not get rid of the argument by solving all these
concerns. The use of a callback monitor interface exposed by these
libraries would solve the need for any C-L or other dependencies. Plus
by generalizing the problem we open the door for many more use cases.
> (2) If so, what logging library should be used?
I don't think (1) has to be the case but if it were C-L IMO would be the
absolute best choice for the reasons you've stated below:
>
> * Log4J -- but this would force all downstream users of the
> library to use Log4J, even if the applications themseves
> use something else.
>
> * JDK 1.4 -- but this would force all downstream users of
> the library to run on JDK 1.4, and also doesn't obey the
> "single logging configuration" desire if they are using
> something like Log4J
>
> * The same basic issue will apply to any other individual
> logging implementation you might like -- the selection
> of a particular logging API by a commonly reused library
> *forces* applications using that library to support that
> logging API, even if the app is using something different.
>
> Indeed, this issue was the motivation for creating Commons Logging in
> the first place -- instead of being a logging *implementation* it was
> deliberately designed as an *adapter* to whatever underlying
> implementation you want to use.
Yes this has been said over and over again and I don't understand why
the debate re-emerges. Again I can only suspect that its the required
jar dependecy that is causing most of the concern out there.
> So, what is it that you are suggesting?
I would like to add to this. Is the root of our concerns really the
fact that we have a dependency on another library or is the issue here
about a dependency on a logging implemenation?
If the answer to this Q is yes, the concern is the additional dependency
and not on a logging adapter or implementation, then using monitors is
the way to go. It will do away with the dependency. Meanwhile it will
still allow for these libraries to notify users of significant events
occuring in the library. If users choose they can then wire up the
library to a specific logging monitor. The user still gets to decide in
the end.
To help demonstrate the application of this NoLogging approach I'm
volunteering myself to any commons project to convert their C-L
dependency into a monitor with an associated adapter and other logging
implementations. We can make the changes in a branch. When complete we
can take a step back to look and see if this approach is worth it. If
not we can scratch the idea.
WDYT?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 26 Aug 2004, Craig McClanahan wrote:
> You are asking two separate but related quesitons here, so they should
> be addressed separately.
>
> (1) Should libraries depend on *any* logging library?
This is all I'm really asking. I'm happy that if logging is needed that
commons-logging is a good choice (though I hear a lot of classloading
complaints, but I don't think that is all commons-logging's fault).
Well, nicest would be to offer java.util.logging as a separate jar, but
licensing prevents that I assume. I wonder what the deal was with
lumberjack.sf.net.
> It seems obvious to me that libraries would benefit from having
> logging embedded. It's not just for the library developers to debug;
> it is also for the library *user*. Digester is actually a classic
> example of this use case ... debugging your matching rules is MUCH
> easier when you can turn on trace level debugging to see which rules
> are actually getting matched, and what order the rules are being fired
> in.
Digester is an example where I think logging is borderline. It needs to be
able to warn about rules that appear wrong.
It's the ones that are less of a micro-framework that worry me. Beanutils
and Math are the ones that jump out first. They both seem to be
static-librarylike; no need for warnings, errors should be Exceptions and
debug seems like overkill. For something with such a simple lifecycle,
dragging the logging dependency around feels very painful and it seems a
lot less likely that the debugging will be of use to the user.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 31 Aug 2004 14:10:05 +1200, Simon Kitching
<si...@ecnetwork.co.nz> wrote:
> On Tue, 2004-08-31 at 13:27, Henri Yandell wrote:
> > On Thu, 26 Aug 2004, Craig McClanahan wrote:
> >
> > > You are asking two separate but related quesitons here, so they should
> > > be addressed separately.
> > >
> > > (1) Should libraries depend on *any* logging library?
> > >
> > > It seems obvious to me that libraries would benefit from having
> > > logging embedded. It's not just for the library developers to debug;
> > > it is also for the library *user*. Digester is actually a classic
> > > example of this use case ... debugging your matching rules is MUCH
> > > easier when you can turn on trace level debugging to see which rules
> > > are actually getting matched, and what order the rules are being fired
> > > in.
> >
> > Just to bring up another thought on this question, what happens in other
> > languages/techs?
> >
> > Does glibc contain lots of debug statements (I assume to syslog?). Does
> > Swing contain lots of debug statements? Do libraries contain their own
> > plugins to the -w flag in Perl? (Might do for all I know).
>
> Well, the sshd application contains logs of debug statements to syslog,
> and these can be absolutely vital in tracking down login problems.
>
> The DB2 database has diagnostic logs that can be tuned to generate
> various amounts of data. Actually, the diagnostic output is next to
> useless, but the principle is there.
>
> I would guess that J2EE app servers have diagnostic output available
> (others may be able to give details).
They do, and I couldn't live without it. It's absolutely crucial to
understanding how things are (not) working when you're trying to
diagnose a problem. When you have a large complex app running on a
full-blown app server, being restricted to only your own debugging
output would be worse than working in the dark.
> > I'll happily agree that debugging statements in code is very useful
> > (despite the arguments of the IDE debuggers), but I'm unconvinced that
> > released stable binaries should contain the debugging etc. It seems
> > unlikely to be of a lot of use to direct users, and definitely of less use
> > for third-hand users (think developers of Struts trying to navigate
> > through Digester debugging statements).
>
> I vigorously disagree with this statement.
>
> The ability to turn on logging in an application which is deployed in
> production is extremely important. You can't always duplicate problems
> in test enviroments (particularly when the problem is occurring at a
> customer site). And you certainly can't run code in a production
> environment under debugger control. And going through the paperwork to
> deploy specially-compiled versions of apps with debugging enabled can be
> a *major* hassle. Of course enabling logging does have a performance
> impact (which is why it is important that the logging system have the
> ability to carefully select subsets of messages relevant to the
> problem), but it is much easier to get agreement to tweak such settings
> than to deploy new executables. If the logging can be reconfigured
> without restarting the application concerned, that is even better.
>
> As a developer of software deployed in large commercial sites, I *love*
> the ability to leave logging statements in production code, and
> enable/disable them as required.
+1 to all of that.
> In your example of Struts users, yes they *can* understand what the
> digester log statements mean. And if they can't, they can post such logs
> to the appropriate email list and get advice on what the problem is.
This is, in fact, one of the precise cases I had in mind when I
commented on logging being essential in an earlier message. It's
exactly because Digester has good logging output that people are able
to diagnose problems with their Struts config files.
> When library functions are so simple that their return codes or
> exception objects *completely* describe the problem which occured, then
> logging within the library may not be necessary because the calling code
> has all the necessary info to generate good error messages to the user
> (potentially via logging). This description may well apply to the
> majority of glibc functions. And may well apply to most of o.a.c.lang or
> o.a.c.collections. But this description does *not* fit well with many
> other commons libraries, digester being a prime example.
>
> Digester has loads of "state", so the true cause of a problem may be
> related to a method call well-removed from the point at which the error
> occurred. And logging is a very good way to track these issues down. I
> expect that "configuration" has similar issues, and maybe other commons
> libraries.
Again, +1 from me.
--
Martin Cooper
>
> Regards,
>
> Simon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 31 Aug 2004, Michael Becke wrote:
>
> On Aug 30, 2004, at 11:36 PM, Henri Yandell wrote:
> >
> > Yes, I walked into this one stupidly, especially as my original email's
> > example specifically was not trying to target Digester as a place I
> > disagreed, but the simpler library of BeanUtils.
> >
> > Apologies for a bad example, I wasn't thinking.
> >
> > BeanUtils (lots of debugging, but very low level class), HttpClient (6
> > debug lines), Configuration are some that leap out in my view.
>
> Just to chime in on HttpClient's behalf... Debug logging in
> HttpClient is quite critical. Its primary use is as a configurable
> "wire" log of all HTTP requests. We would have little hope of
> resolving many user problems without logging.
Ah, so Wire is a facade for the logging :) That explains why there seems
to be so little logging in httpclient.
Thanks,
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Michael Becke <be...@u.washington.edu>.
On Aug 30, 2004, at 11:36 PM, Henri Yandell wrote:
>
> Yes, I walked into this one stupidly, especially as my original email's
> example specifically was not trying to target Digester as a place I
> disagreed, but the simpler library of BeanUtils.
>
> Apologies for a bad example, I wasn't thinking.
>
> BeanUtils (lots of debugging, but very low level class), HttpClient (6
> debug lines), Configuration are some that leap out in my view.
Just to chime in on HttpClient's behalf... Debug logging in
HttpClient is quite critical. Its primary use is as a configurable
"wire" log of all HTTP requests. We would have little hope of
resolving many user problems without logging.
There have also been some similar discussions of commons-logging on the
HttpClient dev list lately. In particular a HttpClient user has
recently posted an Ant script for changing all HttpClient
commons-logging statements to log4j. My preference would be for
different commons-logging jars that are statically compiled against
various logging implementations. That way a user could pick the jar
that is most appropriate while we develop against a single interface.
I believe this is what Robert suggested earlier.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 31 Aug 2004, Simon Kitching wrote:
> On Tue, 2004-08-31 at 13:27, Henri Yandell wrote:
>
> > I'll happily agree that debugging statements in code is very useful
> > (despite the arguments of the IDE debuggers), but I'm unconvinced that
> > released stable binaries should contain the debugging etc. It seems
> > unlikely to be of a lot of use to direct users, and definitely of less use
> > for third-hand users (think developers of Struts trying to navigate
> > through Digester debugging statements).
>
> I vigorously disagree with this statement.
Yes, I walked into this one stupidly, especially as my original email's
example specifically was not trying to target Digester as a place I
disagreed, but the simpler library of BeanUtils.
Apologies for a bad example, I wasn't thinking.
BeanUtils (lots of debugging, but very low level class), HttpClient (6
debug lines), Configuration are some that leap out in my view.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Tue, 2004-08-31 at 13:27, Henri Yandell wrote:
> On Thu, 26 Aug 2004, Craig McClanahan wrote:
>
> > You are asking two separate but related quesitons here, so they should
> > be addressed separately.
> >
> > (1) Should libraries depend on *any* logging library?
> >
> > It seems obvious to me that libraries would benefit from having
> > logging embedded. It's not just for the library developers to debug;
> > it is also for the library *user*. Digester is actually a classic
> > example of this use case ... debugging your matching rules is MUCH
> > easier when you can turn on trace level debugging to see which rules
> > are actually getting matched, and what order the rules are being fired
> > in.
>
> Just to bring up another thought on this question, what happens in other
> languages/techs?
>
> Does glibc contain lots of debug statements (I assume to syslog?). Does
> Swing contain lots of debug statements? Do libraries contain their own
> plugins to the -w flag in Perl? (Might do for all I know).
Well, the sshd application contains logs of debug statements to syslog,
and these can be absolutely vital in tracking down login problems.
The DB2 database has diagnostic logs that can be tuned to generate
various amounts of data. Actually, the diagnostic output is next to
useless, but the principle is there.
I would guess that J2EE app servers have diagnostic output available
(others may be able to give details).
>
> I'll happily agree that debugging statements in code is very useful
> (despite the arguments of the IDE debuggers), but I'm unconvinced that
> released stable binaries should contain the debugging etc. It seems
> unlikely to be of a lot of use to direct users, and definitely of less use
> for third-hand users (think developers of Struts trying to navigate
> through Digester debugging statements).
I vigorously disagree with this statement.
The ability to turn on logging in an application which is deployed in
production is extremely important. You can't always duplicate problems
in test enviroments (particularly when the problem is occurring at a
customer site). And you certainly can't run code in a production
environment under debugger control. And going through the paperwork to
deploy specially-compiled versions of apps with debugging enabled can be
a *major* hassle. Of course enabling logging does have a performance
impact (which is why it is important that the logging system have the
ability to carefully select subsets of messages relevant to the
problem), but it is much easier to get agreement to tweak such settings
than to deploy new executables. If the logging can be reconfigured
without restarting the application concerned, that is even better.
As a developer of software deployed in large commercial sites, I *love*
the ability to leave logging statements in production code, and
enable/disable them as required.
In your example of Struts users, yes they *can* understand what the
digester log statements mean. And if they can't, they can post such logs
to the appropriate email list and get advice on what the problem is.
When library functions are so simple that their return codes or
exception objects *completely* describe the problem which occured, then
logging within the library may not be necessary because the calling code
has all the necessary info to generate good error messages to the user
(potentially via logging). This description may well apply to the
majority of glibc functions. And may well apply to most of o.a.c.lang or
o.a.c.collections. But this description does *not* fit well with many
other commons libraries, digester being a prime example.
Digester has loads of "state", so the true cause of a problem may be
related to a method call well-removed from the point at which the error
occurred. And logging is a very good way to track these issues down. I
expect that "configuration" has similar issues, and maybe other commons
libraries.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 26 Aug 2004, Craig McClanahan wrote:
> You are asking two separate but related quesitons here, so they should
> be addressed separately.
>
> (1) Should libraries depend on *any* logging library?
>
> It seems obvious to me that libraries would benefit from having
> logging embedded. It's not just for the library developers to debug;
> it is also for the library *user*. Digester is actually a classic
> example of this use case ... debugging your matching rules is MUCH
> easier when you can turn on trace level debugging to see which rules
> are actually getting matched, and what order the rules are being fired
> in.
Just to bring up another thought on this question, what happens in other
languages/techs?
Does glibc contain lots of debug statements (I assume to syslog?). Does
Swing contain lots of debug statements? Do libraries contain their own
plugins to the -w flag in Perl? (Might do for all I know).
I'll happily agree that debugging statements in code is very useful
(despite the arguments of the IDE debuggers), but I'm unconvinced that
released stable binaries should contain the debugging etc. It seems
unlikely to be of a lot of use to direct users, and definitely of less use
for third-hand users (think developers of Struts trying to navigate
through Digester debugging statements).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by Craig McClanahan <cr...@gmail.com>.
You are asking two separate but related quesitons here, so they should
be addressed separately.
(1) Should libraries depend on *any* logging library?
It seems obvious to me that libraries would benefit from having
logging embedded. It's not just for the library developers to debug;
it is also for the library *user*. Digester is actually a classic
example of this use case ... debugging your matching rules is MUCH
easier when you can turn on trace level debugging to see which rules
are actually getting matched, and what order the rules are being fired
in.
(2) If so, what logging library should be used?
It also seems obvious to me that, if it's appropriate for libraries to
support logging, then the user of these libraries would prefer to only
need to configure ONE logging system, instead of one logging system
per library. If that assumption is agreed to, then, what single
logging system should be selected? A couple of possibilities
obviously come to mind:
* Log4J -- but this would force all downstream users of the
library to use Log4J, even if the applications themseves
use something else.
* JDK 1.4 -- but this would force all downstream users of
the library to run on JDK 1.4, and also doesn't obey the
"single logging configuration" desire if they are using
something like Log4J
* The same basic issue will apply to any other individual
logging implementation you might like -- the selection
of a particular logging API by a commonly reused library
*forces* applications using that library to support that
logging API, even if the app is using something different.
Indeed, this issue was the motivation for creating Commons Logging in
the first place -- instead of being a logging *implementation* it was
deliberately designed as an *adapter* to whatever underlying
implementation you want to use. The actual configuration of the
underlying logging system chosen by the applicaton doesn't change
(except for the potential addition of a few extra logging level
setting). Thus, the commons libraries that do their logging to C-L do
*not* impose any requirements on the applications that use those
libraries. What alternative do you suggest that would be less
invasive than that?
It does not appear, to me at least, that these motivations and issues
have changed. Indeed, if these arguments are compelling, one could
only conclude that there are too *few* libraries relying on C-L (if
they do logging at all) rather than to *many*.
So, what is it that you are suggesting?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] logging
Posted by David Graham <gr...@yahoo.com>.
DbUtils intentionally does not use logging but it is rather small and
doesn't really need it. Validator has very little logging usage and that
dependency could probably be removed. Most of what it used to log was
better handled by throwing an exception out to the framework to the users.
I like the fact that DbUtils is distributed as just a single dbutils.jar
but that's not a requirement I would place on other commons components.
David
--- Henri Yandell <ba...@generationjava.com> wrote:
>
> (probably flamebait)
>
> Why do so many of our components require logging of some form or
> another?
> (usually commons-logging).
>
> I can see why a micro-framework like Digester might be nice to have
> debugging statements, and might want an error system better than
> Exceptions as the rules can be tricky to write sometimes, but for a
> simple
> component-library like beanutils it seems like overkill. Even if we were
> using java.util.logging, it would still seem like overkill for a library
> to require logging.
>
> The following all depend on logging. Seems like a lot:
>
> beanutils
> betwixt
> chain
> configuration
> digester
> el
> httpclient
> jexl
> jxpath
> latka
> launcher
> math
> modeler
> validator
>
> (sandbox)
> cli
> messenger
> periodicity
> resources
> scaffold
> sql
> threadpool
> vfs
> xo
>
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org