Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
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?
Cocoon classloader is used first.
Yes, I understand this, but I'm not sure that this is the correct way for all
scenarios.
Ok, where do you want to use it? In your private code?
Not only there, the new spring stuff I'm currently developing is avalon
free but needs logging of course; I plan to make the portal avalon free etc.
Ok.
Unless extra ClassLoader is mandatory, I don't think we can use commons-logging
in Cocoon code, due to issue above.
Ok, so I'll go for log4j then
But in this case Cocoon would end up with two log files - one is regular
core.log (created, say, by good old LogKit) and another one from the log4j from
'new code'... I'd prefer commons-logging over log4j for reasons:
* it supports all of them - LogKit, Java logging, log4j;
* it seems to be already used in many (most?) libraries throughout Apache;
That is assuming that any class loading issues can be resolved.
Vadim
