You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Andy Cutright <An...@borland.com> on 2004/04/07 18:57:33 UTC

changes to build.xml/ commons-dbcp.jar

hi steve, 

i see you've removed the commons-dbcp.jar from the .war target in
build.xml. i've run into a VM implementation issue. the loader wants to
find classes from that package (or one of its dependencies) when
ConnectionManager.aquireConnection() is invoked by the JDBC factory
code. the VM is throwing a noClassDefFound exception. i'm using JNDI so
my code line only transits through ConnectionManager.lookupDataSource,
not through ConnectionManager.createDataSource(). since the
commons-dbcp.jar isn't included with the .war, the VM can't find the
dependent classes, even though they're not strictly necessary. 

i've checked with our class loader gurus and looked over the language
spec. there's no clear requirement about when or whether classes will or
will not be loaded that are referenced by the codebase. if we're
compling against the code, and it's in a class we're using, it looks
perfectly legal for the loader to try to find those classes, even if the
code line doesn't ever actually need access to the classes. 

i'm thinking we can either put back the commons-dbcp.jar, remove the
code dependency, or abstract the connection manager and make a JNDI
connection manager and a dbcp based connection manager. 

thoughts? 

cheers,
andy