juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Cutright" <Andy.Cutri...@borland.com>
Subject RE: changes to build.xml/ commons-dbcp.jar
Date Wed, 07 Apr 2004 17:54:03 GMT
works for me.. i'll make those changes shortly, 


> -----Original Message-----
> From: Viens, Steve [mailto:Stephen.Viens@FMR.COM] 
> Sent: Wednesday, April 07, 2004 10:19 AM
> To: juddi-dev@ws.apache.org
> Subject: RE: changes to build.xml/ commons-dbcp.jar 
> 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 

View raw message