juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Viens, Steve" <Stephen.Vi...@FMR.COM>
Subject RE: changes to build.xml/ commons-dbcp.jar
Date Wed, 07 Apr 2004 17:19:07 GMT
Got it, didn't think of that.

How about including the commons-dbcp.jar for now (quick fix) and look
into breaking the functionality out later?

Steve

-----Original Message-----
From: Andy Cutright [mailto:Andy.Cutright@borland.com] 
Sent: Wednesday, April 07, 2004 12:58 PM
To: juddi-dev@ws.apache.org
Subject: 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 

Mime
View raw message