Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
On 10 May 2004, at 21:26, Stephen Colebourne wrote: This looks like a very neat solution to the problem to me. The Class.forName worries me a little though, as I believe that its not too happy in class loaders. it should probably try the context classloader first. note: it is *very* important to remember that beanutils is used indirectly by a *very* large user base. (think about the user base for strut and tomcat at the very least.) i'd be *very* likely to veto any changes that risk breaking a release without adequate time for testing. (it took a lot of work to make commons-logging work anywhere near reasonably in complex container environments.) i would definitely prefer a service release which would allow downstream developers to resolve any possible issues with collections 3.0 before moving on to looking at commons-logging. so, i'd strong suggest that any ideas for altering the way that logging works are committed into a branch. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
robert burrell donkin wrote:
On 10 May 2004, at 21:26, Stephen Colebourne wrote:
This looks like a very neat solution to the problem to me. The
Class.forName
worries me a little though, as I believe that its not too happy in class
loaders.
it should probably try the context classloader first.
note: it is *very* important to remember that beanutils is used
indirectly by a *very* large user base. (think about the user base for
strut and tomcat at the very least.) i'd be *very* likely to veto any
changes that risk breaking a release without adequate time for testing.
Hmm, Struts is bad example here because it's already using
commons-logging ;)
(it took a lot of work to make commons-logging work anywhere near
reasonably in complex container environments.)
And I'm worry that this will be the same process but code will be split
across different modules.
One more note - I don't know how many 'server applications' are not
using commons-logging, directly or not. Please, take a look at Gump
email and a list of projects depending on o.a.c.l. All of the projects
depending on those projects depends on o.a.c.l.
Also, some recent RIs from Sun using o.a.c.l.
And for them running 'wrapper' around o.a.c.l will be a waste of
force.
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
Just my 2cents,
Tomek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
Tomasz Pik wrote:
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
The fact that many servers already include commons-logging isn't the point.
I typically have at least 10 commons jars in my classpath at all times, but
it isn't fair to assume that everyone else does the same.
Also, I don't think any decision has been made to stop using
commons-logging.
All that is occurring is a conversion of the commons-logging dependency
from mandatory to optional.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
On 11 May 2004, at 21:57, Tomasz Pik wrote:
robert burrell donkin wrote:
On 10 May 2004, at 21:26, Stephen Colebourne wrote:
This looks like a very neat solution to the problem to me. The
Class.forName
worries me a little though, as I believe that its not too happy in
class
loaders.
it should probably try the context classloader first.
note: it is *very* important to remember that beanutils is used
indirectly by a *very* large user base. (think about the user base
for strut and tomcat at the very least.) i'd be *very* likely to veto
any changes that risk breaking a release without adequate time for
testing.
Hmm, Struts is bad example here because it's already using
commons-logging ;)
the point i was trying (but failed) to make was that both tomcat and
struts use beanutils. that's a lot of users.
(it took a lot of work to make commons-logging work anywhere near
reasonably in complex container environments.)
And I'm worry that this will be the same process but code will be split
across different modules.
i'd definitely agree with that.
that's why the key is keeping the bootstrap code very, very simple. all
the sophistication needs to be in the LogFactory implementation. this
may mean generating the bootstrap source from a common template.
One more note - I don't know how many 'server applications' are not
using commons-logging, directly or not. Please, take a look at Gump
email and a list of projects depending on o.a.c.l. All of the projects
depending on those projects depends on o.a.c.l.
Also, some recent RIs from Sun using o.a.c.l.
And for them running 'wrapper' around o.a.c.l will be a waste of
force.
true.
hopefully it wouldn't be a wrapper, just a bit of dependency magic...
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
i'm glad someone appreciates it. we went through (political) hell
creating it :)
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
This looks like a very neat solution to the problem to me. The Class.forName worries me a little though, as I believe that its not too happy in class loaders. Stephen - Original Message - From: Simon Kitching [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, May 10, 2004 6:37 AM Subject: Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections On Sun, 2004-05-09 at 06:16, matthew.hawthorne wrote: robert burrell donkin wrote: funnily enough, if commons logging was to be created again, i'd (with hindsight) consider something along those lines. the bridging implementations would be in a separate, optional jar and the two classes required in the public logging API would be copied over into each component (as part of the build). if the implementation jar is not present, error and fatal levels (only) would log to system.err. those users wanting logging would have to grab and drop in the implementation jar. Doh! Can I vote +2 on this :-) In fact I liked the idea so much, that attached is a proposed implementation. I suggest that the attached LogSource class, together with o.a.c.l.Log, be copied into every project. Of course all the LogFactory.getLog calls would need to be changed to LogSource.getLog calls too. The effect would be that users do not need to download commons-logging in order to use the libraries. If they want to enable logging, they just place commons-logging.jar in the classpath and then configure it as normal. Price: disk space for 1 interface and 1 trivial class, plus a trivial performance hit in the getLog method if they do enable logging. As BeanUtils and Digester are winding up for releases, I would love to get this in if people are happy with the idea. And the nice thing is, we wouldn't need to wait for a logging release to do this! The code deliberately discards all logging rather than writing to stderr; if output is being generated then there must be a configuration system to enable/disable it, which leads back towards commons-logging functionality. The point here is to provide something *so* simple that it *never* needs to change, and hence it is safe to copy the code into multiple places. By discarding log output, we behave exactly as if logging had never been used in the first place which I think is appropriate for an *optional logging* library. Note that this code doesn't try to do anything clever with classloaders. Any mucking about with context class loader, etc. is handled by LogFactory, *not* this class whose responsibility is only to hand off to commons-logging or do nothing. The mechanism Robert suggests for the build (auto copy from the logging jar or dir as part of the build) is nice, but the point is that Log and LogSource should never need updating, so just committing copies of them into the CVS repo for each project should also work, and be simpler. Does copying of classes sound scary? The comments in the LogSource.java file describe why I think this is not a problem. But here's another angle on it. If you compile an app with version 1.0.0 of a lib, then try to run with a version that has a different binary API, what happens? Boom - and you expect it. And if you run with multiple copies of a class and they are identical, what happens? Nothing - because they are all the same. So a problem only occurs when the ABI is the same, but the implementation is different (eg one lib has a bugfixed version, the other doesn't). And because LogSource is trivial this shouldn't occur. I certainly wouldn't recommend copying the complete commons-logging into each project because that code is not trivial. Question: what about situations where multiple libraries are running with different security policies? Might this cause problems when each lib contains its own copy of o.a.c.l.Log ? Would this be worse than if they didn't have their own copy? Here's my opinion on the best approach to logging for each component: Each component creates a simple interface for logging (which could just be a copy of o.a.c.l.Log copied into the components namespace, becoming, for example, o.a.c.beanutils.Log) The component also creates a LogFactory, which checks if commons logging is in the classpath. If it is, it returns an implementation which delegates to commons-logging. If it isn't, it just sends messages of the appropriate level to system.err (just like robert suggests). This may sound a bit complicated, but it's really not. To me, this is a good example of how to deal with optional dependencies. In this example, [beanutils] functions fine without commons-logging, but adding commons-logging to the classpath enhances the logging capabilities. The only problem would be that beanutils would have to invoke the commons-logging methods through reflection, since making
Re: [logging] eliminate dependencies on commons-logging [was [beanutils] PROPOSAL: eliminate core dependency on collections
On Mon, 2004-05-10 at 17:37, Simon Kitching wrote:
On Sun, 2004-05-09 at 06:16, matthew.hawthorne wrote:
[logging suggestion involving reflection]
Is this reasonable, or too much work?
Unfortunately, I think the delegation step is just too much overhead.
The log4j docs describe how much effort they went to to make calls fast
in the case where the message is not logged. But commons-logging adds
overhead to every call, and as far as I can see this approach would add
another level of calls, including **reflection** which has significant
overheads.
The approach I suggest only uses Method.invoke within the getLog method.
This solution is definitely cleaner, as it avoids having multiple
copies of the Log and LogSource class in multiple libraries. However by
hiding the o.a.c.l.Log interface behing a {component}.Log interface I
believe this forces indirect invocation (Method.invoke) on every
debug/info/warn/error call (filtered or not) which seems unacceptable to
me. If I've misunderstood you, please set me straight..
Maybe a bytecode generation implementation of this idea would work, ie
have a factory that generates custom classes to bridge between the local
component's Log interface and the commons-logging Log interface. But
that's a serious project!
I seem to remember sun introducing a class recently into the std
libraries which uses bytecode generation to create classes on the fly; I
think it was intended for use in swing apps to avoid too many anonymous
inner class declarations. Anyone remember what it was? [I'm not thinking
of java.lang.reflect.Proxy].
I've found the class I was trying to remember about. I was thinking of
java.beans.EventHandler, which was added in java 1.4 as part of the
long term persistence project. Unfortunately, it's just a wrapper
around java.lang.reflect.Proxy, so still uses reflection on one side
even though it generates bytecode to implement the appropriate
interface. Quite appropriate performance for GUI tasks, I think, but not
what I would look for in a logging library (see below).
On re-reading my earlier email, I thought I really should justify my
assumption that Method.invoke is too slow. So I created a test which
disables logging at info level, then logs 1,000,000 info messages
directly and via a wrapper that uses Method.invoke (note that
Class.findMethod is only used once, and the Method object cached).
Result: direct 80 msecs, indirect: 440 msecs.
So the Method.invoke wrapper makes the call around 5 times slower. I'm
not generally an optimise-at-all-costs guy, but this does sound a hefty
price to pay for breaking the explicit lib dependency.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was [beanutils] PROPOSAL: eliminate core dependency on collections
On Mon, 2004-05-10 at 17:37, Simon Kitching wrote: On Sun, 2004-05-09 at 06:16, matthew.hawthorne wrote: robert burrell donkin wrote: funnily enough, if commons logging was to be created again, i'd (with hindsight) consider something along those lines. the bridging implementations would be in a separate, optional jar and the two classes required in the public logging API would be copied over into each component (as part of the build). if the implementation jar is not present, error and fatal levels (only) would log to system.err. those users wanting logging would have to grab and drop in the implementation jar. Doh! Can I vote +2 on this :-) Doh! I forgot something very important... In fact I liked the idea so much, that attached is a proposed implementation. I suggest that the attached LogSource class, together with o.a.c.l.Log, be copied into every project. Of course all the LogFactory.getLog calls would need to be changed to LogSource.getLog calls too. Of course the proposed LogSource class can be renamed in the importing project. And probably should be. Only the o.a.c.l.Log interface needs to be distributed un-renamed, and therefore potentially duplicated when multiple libraries are then used together. And as it's an interface which will only change in major library upgrades, I don't see that the duplication causes any problems except *possibly* this security policy issue: Question: what about situations where multiple libraries are running with different security policies? Might this cause problems when each lib contains its own copy of o.a.c.l.Log ? Would this be worse than if they didn't have their own copy? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
