commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Wed, 15 Dec 2004 21:21:10 GMT
"Henning P. Schmiedehausen" <> wrote on 12/15/2004 
03:06:41 PM:

> robert burrell donkin <> 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 

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
>        +49 9131 50 654 0
> RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for 
>    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:
> For additional commands, e-mail:

Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message