Shapira, Yoav wrote, On 18/06/2003 18.06:
Howdy, I don't have time to comment on everything in depth, but a quick comment on the first issue:
A problem with logging libraries, is that even if I only use the app without needing *any* logging, I still have to include the jar of the logging library. And as small as it may be, it's still something I'd like to not distribute.
Why are you using the logging the library if you don't need "*any* logging?"
As a developer, I do. Most users don't. I can't count how many have said POI was not working, and it was because the logging lib was not there. And when it was there it clashed with their version.
Basically, users don't need to have logging in libraries. At least they donět have to need that it's needed to run that darn library.
Finally, there is the speed issue. As fast as an if.isDebugEnabled()
may
be, we have seen that some places need a logging statement in a "close loop", and this makes performance degrade.
What is a "close loop?" Can you give an example where a logger.isDebugEnabled is not possible but logging is still needed?
SAX pipe in Cocoon code (Xalan). @see recent mail on it.
runtime removal of debug statements ------------------------------------------------------------ IE: I need to not include all the logging statements in my code
Possible solution: have the class files be preprocessed to remove all logging statements.
Sample: the class files are preprocessed by BCEL to remove these method calls
Another possible solution is to modify the .java files prior to compilation as part of the build process. You can write an Ant task to do this (the copy task's filtering code does nearly everything you want) or a perl script, or something else. I usually prefer this to bytecode manipulation.
Ok, that's what I think about now. So that at compile time we can decide what to include. But all the jar has to be recompiled.
Basically what I was thinking is a mixture of this and the "include stub in every jar" one.
In this way, if I get a jar that has log4j as a dependency, and I don't want to log at all, or use my library, I could run it through the tool and have it transparently use my logging or none at all.
This 3rd point is a doozy.
hehehe
Comments?
What makes you concerned about this now? I agree the status quo is not ideal, but have you run into an insurmountable problem?
To remain short: I'm sick of people asking me what logging library to use, some complaining they want to use another, others that hate J-C logging, others that don't want any... I really want to find a solution that can finally make all happy. My basic needs are to b able to switch library easily, and not require to bundle a logging-stuff jar.
Basically: I distribute the jar, if (and only if) the user wants logging he can add any logger to the classpath and have logging.
In practice it requires the library to add a logging class inside or to us a JDK interface (no other jar needed).
But to make things simpler for the coder we can use "Ant" filtering on comments (normal plain compilers can still compile).
Class rewriting afterwards as I proposed really feels tacky, so maybe it's just not the way. Not that sure still though...
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
