i didn't propose to reloacte here but just to take into account classloader issues.
JULI (tomcat) is not that bad in practise and will lead to less conflicting issues IMO. Do you think to other cases saying JUL is not adapted? My point about JDBC 4 features is we'll use JUL in all cases when upgrading so why not aligning on it right now. About eating our own food: it was consistent while there were no commonly used facade. It seems today apache frameworks like slf4j more than CL (at least the one i use commonly) so maybe time to change. To summarize my opinion: if you use slf4j i'll not fight but i think JUL is far enough for this case. *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/7/24 Mark Thomas <ma...@apache.org> > On 24/07/2013 11:44, Romain Manni-Bucau wrote: > > well what i don't get is you (understand as tomcat guy) are the first to > > relocate classes to avoid clashes with apps and here you don't want. > > Relocating classes here won't help. If a container and an app both try > to use a version of DBCP that uses a relocated Commons Logging both DBCP > and the relocated Commons Logging will clash. > > If relocation the preferred use case then the container has to relocate > DBCP and Logging. Relocating things in the library doesn't help. > > > we worked on tomee to limit the side effects but we can't guarantee it at > > 100% (typically one weird case is > > https://issues.apache.org/jira/browse/TOMEE-758) > > From the description it looks like relocation would fix that issue > although logging is usually sufficiently complex that there may well be > additional factors that mean relocation isn't a viable option. > > > I think i have 2 points for JUL: > > > > 1) logging is mainly for exceptions so no need to bring something for a > > case which shouldn't be that common > > > > 2) DBCP is highly linked to JDBC and JDBC uses JUL in its recent API > (java > > 7 IIRC) so maybe we should just align on it > > DBCP currently throws SQLFeatureNotSupportedException in all cases for > the one JDBC 4.1 method that uses JUL. I do not propose changing that. > > Reasons not to use JUL for DBCP: > - JUL is fundamentally broken in a container environment as it is not > class loader aware. > - The JUL to SLF4J bridge has performance issues. > - Other frameworks that seek to replace JUL would have the same > performance issues. JUL is a very poor choice for a facade. > > There are options for the logging facade. Commons Logging is one. SLF4J > is another. There are others but JUL is not one of them. Primarily from > an eating your own dog food PoV, Commons Logging is the option I'm > working with for DBCP. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
