<snip>
No one has yet described for me a use case where the current commons-logging classloading strategy is necessary or even correct. Whereas I have described a use case where it clearly fails, and have implemented a code change that fixes the problem for my use case.
i believe that the strategy is correct for at least one version of the servlet specification provided that the specification is correctly followed (see remy's comments earlier). craig and remy are experts.
As far as I can tell, commons-logging is just plain broken. But I have a lot of respect for the developers here, and clearly they have thought about this issue a lot. So I'm left wondering what I'm missing.
IMHO j2ee classloading has been broken (in various different ways) from the time that specification was first rolled out. solving classloading issues is an art rather than a science. the exact classloading rules depend on the particular environment (whether servlet container or application container), the version of the specification. the particular application container on which the code runs and the deployment configuration. this makes it very difficult to create a library component that will 'just run' correctly given all these different variables.
the classloading issue has been raised so many times that it'd be nice to sit down and work for the weeks that it would take to comprehensively address this issue. is there any volunteer with the energy to do this?
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
