The Problem
I'll say it here and I'll probably say it again -- I hate Hibernate. Nonetheless, several of the applications in my office implement the technology and we can't take it all out all at once. We deploy to an Oracle Application server and develop locally using Eclipse and OC4J.
One particular feature of Hibernate is HQL (Hibernate Query Language) which is for writing object-oriented SQL queries. One of my applications kept throwing errors with regard to Hibernate HQL-related sections. One error in particular that kept coming up was:
org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken
The errors were being thrown on my local OC4J server and our office's Oracle Application Server but not on my local Tomcat server. What could be the cause?
The Solution
In my case, the problem revolved around a conflicting versions of antlr.jar. Hibernate 3.2.1.ga depends uses version of antlr.jar (antlr 2.7.6 I believe) and Oracle Application Server (OC4J) has a conflicting version of antlr.jar enabled by default in its TopLink library for object-relational mapping.
To remove this conflict OC4J has to be told not to run its TopLink libraries. More can be read about configuring orion-application.xml here:
http://forums.oracle.com/forums/thread.jspa?messageID=2022327
Configuring orion-application.xml worked to solve my OC4J problems, but when it came to deploying to our full Oracle Application Server the orion-application.xml configurations weren't taking. For this I needed to set that configuration upon deployment. See this Oracle documentation link for details. Read the Example: Removing an Oracle Shared Library at Deployment Time for direction on how to configure the Oracle Application Server not to use the TopLink libraries.
Final Comments
Good grief! Writing straight SQL isn't that hard is it? :)
You know, as much as you hate hibernate, i hate oc4j.. and obviously for the same reasons, can't get out of it.. For each of our applications, we do a trial and error method of removing the libraries loaded from the parent application, so as not to have any conflicts.. Now we have a fair understanding of which error message means which jar to be removed.. LOL..
Thanks again..
Thanks for your comment. I'm no fan of OC4J either. Glassfish has a lot of interesting enterprise-level stuff and from what the Unix admins tell me has nice integration into Solaris. Unfortunately Oracle acquiring Sun made the exact position of that product uncertain. I'ver certainly switched all my local development to Tomcat/Glassfish and just test on OC4J before deploying.
It's been a while since I wrote this article. Only one Hibernate application left to write-out in my office. Then we'll be food ol' fashioned, boring, reliable CRUD. :)
Thanks for writing this up!
Billiant fix that work for us deploying our Hibernate app to OC4J.
Cheers