Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
The question now is, what do we use for logging in an avalon free
environment? Spring itself directly uses commons logging.
Please note, that I don't want to change all components we have to the
new mechanism now; but I would like to have our standard way of logging
for all new things which do not use avalon anymore.
One problem with Tomcat/commons-logging combination is that you can have your
logging configuration on per ClassLoader level, and tomcat's (IIRC)
WebApplicationContext shares ClassLoader with all the servlets deployed within
context. So any change to commons-logging configuration (e.g., set
commons-logging factory to LogKit) affects logging of Tomcat component(s)
itself, which is not desirable.
Only way to fix it, I think, is to setup extra ClassLoader which then can have
any needed commons-logging configuration. So that probably means that if we use
commons-logging, it means Cocoon must always set up own ClassLoader.
Yes, this was one of the main reasons to implement the shielded class
loading for 2.2.
Well in this case it does not have to shield anything, it only have to be
present :)
I'm also somewhat skeptical about shielding ClassLoader - I've not thought all
the ramifications of it myself, and not sure it will work in all deployment
configurations. E.g., what is the course of action when library is present in
both parent ClassLoader and Cocoon ClassLoader?
Anyway, I think we should not do any such changes for Cocoon 2.2 - it is better
suited for Cocoon 2.3.
I don't want to change 2.2 as I tried to outline above; I want to have a
way for using a new mechanism *today* if I don't use Avalon. If we can't
come up with a better solution, we could use commons-logging anyway.
Ok, where do you want to use it? In your private code?
Unless extra ClassLoader is mandatory, I don't think we can use commons-logging
in Cocoon code, due to issue above.
Vadim
