commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulo Gaspar <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sat, 11 Dec 2004 14:33:45 GMT
 Hi Noel,

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

We are simply trying to tune the original proposal to please a broader 
range of potential users - including us. To me, this is constructive work.

I believe that most of the requirements of the original proposal are 
quite valid. I would simply prefer that most of them would be developed 
as a layer on top of commons-logging (commons-logging-enterprise?) since 
many of us do not need them or do not need them most of the time.

Please remember that many of us develop software mostly for the internal 
use of some company and only on occasion we do it for the global market, 
and I believe that the developer should only have to carry what he/she 
uses. However, this does not mean I am against those features (except 
for the method logging ones) - I think those features (specially i18n 
related ones) should be implemented BUT packaged separatedly.

Also, in my POV, hidding behind some JSR as a justification to implement 
something is not a valid techical argument. Many JSRs were already 
proved less than good, isn't it?

*** On method logging: ***

On "method logging": sometimes I happen to use it (yes, without AOP), 
but it is the kind of thing I often do in different ways. Sometimes I 
want to display the passed parameters, sometimes I don't, sometimes I 
want to show the parameters one way, sometimes the other, and so on and 
so on.

I really don't see it as something that is convenient to standardize 
when even one single person (me) wants to do it differently even from 
one part of the same project to the other - my guess is that 2 different 
persons will want to do it differently too. Besides, implementing a 
couple of extra methods to simplify method logging is tipically a matter 
of minutes - meaning that the benefit does not pay the clutter.

=> I just believe that we SHOULD NOT include in a library logic to cover 
EVERYTHING that could possibly be done in its domain. Really simple 
stuff that does not need to be standardized should often just be left 
out of it.

*** AOP ***

I also want to regret that you "discount" AOP as "some IDE's tooling". 
The fact that you do not know about it does not mean it does not exist. 
Although you could not be bothered to Google for it, I still think you 
should inform yoursel a bit better about AOP. First of all AspectJ, 
despite having an Eclipse plugin and now being under the Eclipse 
umbrella, is much older than Eclipse, has Ant support and there are 
AspectJ plugins for several other IDEs (JBuilder, NetBeans, JDeveloper, 

AspectJ started here:

You can find a lot of information on AOP at:

including a list of  production grade tools:

and a huge list of research projects:

Besides AspectJ, there are many other Java AOP tools, like:

some are part of larger frameworks, like Spring:

some "proxy" based, like dynaop ( and even 
a project to support a common AOP Java API:

Additional info on AspectJ and its Ant-and-other-IDE's support can be 
found at:

Paulo Gaspar

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

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

View raw message