hibernate.properites being loaded across classloaders

Default of instance of JBoss 4.0.2 Final. Deployment directory contained 2 applications, both using Hibernate. 1 is deployed as a EAR file and contains a jar that represents all the hibernate classes, 2 hibernate config files (becuase this app needed to hit SQLServer and Oracle), and 1 hibernate.properties file.

The second application deploys as a war file on only contains 1 hibernate.cfg.xml file.

What we found was that when both applications were deployed in the same container, and were deployed by starting the instance (not a hot deployment) that the WAR based application would receive the following error.

15:37:50,287 INFO [TransactionFactoryFactory] Transaction strategy: net.sf.hibernate.transaction.JTATransactionFactory
15:37:50,291 INFO [NamingHelper] JNDI InitialContext properties:{}
15:37:50,293 INFO [TransactionManagerLookupFactory] instantiating TransactionManagerLookup: net.sf.hibernate.transaction.JBossTransactionManagerLookup
15:37:50,297 INFO [TransactionManagerLookupFactory] instantiated TransactionManagerLookup
15:37:50,297 INFO [NamingHelper] JNDI InitialContext properties:{}
15:37:50,305 WARN [RequestProcessor] Unhandled Exception thrown: class java.lang.ClassCastException
15:37:50,306 ERROR [[action]] Servlet.service() for servlet action threw exception
java.lang.ClassCastException
at net.sf.hibernate.transaction.JNDITransactionManagerLookup.getTransactionManager(JNDITransactionManagerLookup.java:23)
at net.sf.hibernate.transaction.JTATransactionFactory.configure(JTATransactionFactory.java:48)
at net.sf.hibernate.transaction.TransactionFactoryFactory.buildTransactionFactory(TransactionFactoryFactory.java:48)
at net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:77)
at net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1160)
at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:794)
at com.crlcorp.crm.domain.DataConn.getHibernateSession(DataConn.java:40)
at com.crlcorp.crm.admin.biz.LoginService.loginUser(LoginService.java:29)
at com.crlcorp.crm.admin.control.ProcessLoginAction.doExecute(ProcessLoginAction.java:29)
at com.crlcorp.crm.global.control.CRLAction.execute(CRLAction.java:46)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:534)

This error occured at the first hibernate query to be executed.

Here is the content of the WAR's hibernate.cfg.xml file

<property name="hibernate.transaction.factory_class">net.sf.hibernate.transaction.JDBCTransactionFactory</property>
<property name="dialect">net.sf.hibernate.dialect.Oracle9Dialect</property>
<property name="connection.datasource">java:IssueTrackerDB</property>
<property name="show_sql">true</property>

Everything else is references to mapping documents.

The Hibernate.properties file contained in the EAR deployment had this.

hibernate.cglib.use_reflection_optimizer false
hibernate.transaction.factory_class=net.sf.hibernate.transaction.JTATransactionFactory
hibernate.transaction.manager_lookup_class=net.sf.hibernate.transaction.JBossTransactionManagerLookup

In a effort to correct the problem, I removed these lines form the hibernate.properties, and added them to both hibernate.cfg.xml files used by the EAR.
as so:

<property name="hibernate.transaction.factory_class">net.sf.hibernate.transaction.JTATransactionFactory</property>
<property name="hibernate.cglib.use_reflection_optimizer">false</property>
<property name="hibernate.transaction.manager_lookup_class">net.sf.hibernate.transaction.JBossTransactionManagerLookup</property>

Upon adding these lines, and removing the hibernate.properties from the EAR file, I redeployed both applications, and restarted the container. Now everything starts and runs without error.

I think the problem is that the hibernate.properties file is getting loaded at a server instance level instead of being isolated to the application it is contained in. In this case the properties file is getting loaded globally. I haven't had a chance to test if these values can be expliticly overwritten by values in the cfg.xml files, but that is my next step.

If the intent is to allow for system or instance wide hibernate properties to be set in the hibernate properties file, then this file should be handled in the conf directory and treated in a similar fashion the log4j.xml