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, etc.).
AspectJ started here: http://www.parc.com/research/csl/projects/aspectj/default.html
You can find a lot of information on AOP at: http://aosd.net/
including a list of production grade tools: http://aosd.net/technology/practitioners.php
and a huge list of research projects: http://aosd.net/technology/research.php
Besides AspectJ, there are many other Java AOP tools, like:
http://aspectwerkz.codehaus.org/
http://nanning.codehaus.org/
http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop
some are part of larger frameworks, like Spring: http://www.springframework.org/
some "proxy" based, like dynaop (https://dynaop.dev.java.net/) and even a project to support a common AOP Java API:
http://aopalliance.sourceforge.net/
Additional info on AspectJ and its Ant-and-other-IDE's support can be found at:
http://eclipse.org/aspectj/
http://aspectj4jbuildr.sourceforge.net/
http://aspectj4netbean.sourceforge.net/
https://jdeveloperaop.dev.java.net/
http://aspectj4emacs.sourceforge.net/
Regards, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
