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
