[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| [jetty-users] 7.6.4: Switched to JNDI datasource instead of a ConnectionProvider, led to ClassLoader issues | 
Hi guys,
Environment: plain jetty 7.6.4 release on jdk7u3, with a webapp in 
webapps/MyWebapp.war and contexts/MyWebapp.xml.  Followed docs on 'plus' 
configuration, running Jetty with "java -jar start.jar OPTIONS=plus".
I've been working through an upgrade to Hibernate 4, which led to my 
DBCP connection provider breaking - the Hibernate API has changed and no 
new DBCP solution seems on offer anywhere.  In the process of fixing, 
I'm trying to move to the 'recommended' approach of using JNDI to define 
my data source.  This is the first time I've got JNDI working with 
Jetty.  I have a custom dialect class to deal with a couple of MySQL 
inconsistencies (e.g. 
http://stackoverflow.com/questions/8667965/found-bit-expected-boolean-after-hibernate-4-upgrade).
For some time I've run successfully with the Dialect .class file 
packaged in the webapp .war file along with the rest of my app.  My 
question is how to package this file when using a JNDI defined DataSource.
*Old setup*: Hibernate driven webapp with:
<property 
name="hibernate.connection.provider_class">ltd.mycompany.db.dbcp.DBCPConnectionProvider</property>
<property 
name="hibernate.dialect">ltd.mycompany.db.dialect.MyMySQLDialect</property>
The Hibernate session would use this connection provider to obtain each 
connection, so I think the ClassLoader being used for both the mysql 
driver and my MyMySQLDialect class were both the one used for the rest 
of the webapp.  Thus MyMySQLDialect was found within the webapp .war.
*New setup*: jetty-env.xml defining a JNDI resource which is a 
com.mchange.v2.c3p0.ComboPooledDataSource.
It failed saying it couldn't load MyMySQLDialog.class.  This seems to be 
because the ClassLoader being used is now one that cannot see the 
classes in my .war, because it's 'above' the one used for the .war in 
the ClassLoader hierarchy. If I create a little .jar with just 
ltd.mycompany.db.dialect.MyMySQLDialect.class in it, and drop it in 
$jetty_home/lib/ext, this problem goes away.
My question is, what's the best solution for making the Dialect class 
visible to the classloader, when using a JNDI datasource?
For now, it seems I must create a .jar to put in lib/ext just for this 
dialect class, which seems overkill and introduces deployment work that 
I'd like to avoid.
Any advice gratefully received :)  I'm going to go and try to get my 
embedded jetty working with this JNDI setup, which is a different story.
Nick