Hi,

I downloaded the 3.3.2GA zip file from http://sourceforge.net/projects/hiberna ... ibernate3/ and included these files
antlr-2.7.6.jar
dom4j-1.6.1.jar
hibernate3.jar
jta-1.1.jar
commons-collections-3.1.jar
hibernate-annotations-3.3.0.jar
javassist-3.9.0.GA.jar
slf4j-api-1.5.8.jar

and i still get the exception


Caused by: java.lang.ClassNotFoundException: org.hibernate.ejb.HibernatePersistence
at com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:738)
at com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:628)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.sun.enterprise.server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java:137)
... 71 more

can anyone tell me what jar i am missing.

thanks

As of 3.5.4, that class definitely is in hibernate3.jar.
(I don't know what's in earlier versions, specifically I don't have 3.3.2.)

Possible causes that I can think of:
- the class wasn't in 3.3.2 at all, and the code that needs it is newer
- you accidentally installed an old hibernate3.jar
- your classpath accidentally includes an old hibernate3.jar

Yes the class is in 3.5.4. However i cant use 3.5 version since its supports JPA2.0 spec but we use glassfish V2 which only supports JPA1.0 thats the reason i chose 3.3.2 version. I downloaded 3.3.2GA from the website and i see it has hibernate3.jar in the downloaded zip file.

Just wondering what is wrong with my classpath.

you're missing the hibernate-entitymanager

how come when i download it is not part of the zip file? Is there any document which says what all jars i need to copy? Because i dont see in the hibernate reference document which is part of the downloaded zip file.

The entitymanager is optional to use hibernate, most users don't need it. You need it when you want to use EJB persistence as it is the implementation of JPA, using Hibernate core as real engine.
People don't usually "copy" all jars but use a dependency management tool, or follow documentation of the platform you use of which we don't have any idea.

It would be nice if the Hibernate docs stated what the dependencies are, and where to download them.
This information could even be autogenerated with the help of the dependency tools the Hibernate team is using, so this should not create a lifelong maintenance nightmare on you all.

Asking all Hibernate users to switch to Maven just to be able to identify the relevant jars seems a bit over the top. Imagine an engineer asking his superior to replace the entire build infrastructure just to test whether Hibernate will indeed solve some problems in the project, and guess what the superior's answer will be.

(Apart from such issues, Hibernate is generally quite nice, so please continue with the good work :-) )

Hi, it's not completely missing: http://docs.jboss.org/hibernate/entitym ... le/#d0e215
As I said above, it's not Hibernate Core which depends on the EntityManager but the EntityManager depending on Hibernate Core. Every EJB3 book will tell you that you need the EntityManager, as that's the basic API.
Please if you see how to improve this area of documentations, send us a patch, or point with suggestions to where you would have expected this hints.
All docs are maintained in docbook format in the sources.

About Maven, sorry I'm not implying you have to use it, just that when the "human language" is not clear enough or seems wrong, looking into the sourcecode's pom.xml the dependencies are clearly identified - also it's pretty easy to automatically fetch dependencies via other non-Maven build tools: both ANT/IVY and Gradle (other quite common build tools) know how to handle Maven artifacts.

Er... since I know next to nothing about Maven, those pom.xmls could as well be written in Greek.
E.g. just from looking at those xmls, I still don't know where to look the referenced files up, nor which of these files are referenced in what capacity, or how to identify the relevant version.

Just give us a break and have a script extract the pom.xml into some standardized language that lists the various files. If the pom.xml is easy to read, the script should be easy to do; if the pom.xml is hard to read, then don't expect us Maven non-experts to correctly interpret the pom.xml :-)



Okaaay... now my problem is: I'm barely familiar enough with Ant to set that up, and I know too little about Maven to make sure that it is even doing the Right Thing.
So: is there a page that explains the process?
Even better: would it be possible to place a link to such a page on any page that refers to a Maven pom.xml?

As things are today, it's really hard to get "into" the Hibernate ecosystem.
Of course, I guess things would be easier if one simply started with the JBoss suite, but then switching a team from another IDE setup (even an Eclipse-based one) to JBoss would require quite a lot of time that many projects simply can't afford. Not for experimenting with Hibernate anyway.

http://docs.jboss.org/hibernate/core/3.6/quickstart/en-US/html_single/
paragraph 1.1 states where to get the jars, and which ones you want on your classpath.
as mentioned above, if you could point out what specifically is not clear, that would help improve the docs.

Ah nice. I wasn't aware that it's listed there.

The problems I was having were actually finding the download link on the hibernate.org site, but it seems it has been restructured. I found the same directory from the main page with no trouble, so I retract all criticism there.
(I guess it was lingering gripes from, oh, one or two years ago, and ongoing gripes with the Hibernate Tools package which is still a bit hard to deal with.)

A few gripes that I had (not sure whether they're fixed now or not):
1) Inside the download package, it was unclear which directories held what artifacts, and what artifacts were needed for what task.
2) For some jars, it was difficult to find the sources. Or even to find the project where the sources originated from (that's useful in case of problems: look at the original site and see whether a newer release fixes your problem).
3) It's sometimes hard to determine which version of external packages will work with which versions of Hibernate. This is important in situations where Hibernate is not the only package with specific version requirements. (I know version testing sucks, but it would build a lot of confidence in using Hibernate.)

None of these points are serious issues, just areas where further improvement is possible and would be helpful.

Hope this helps.
And thanks for building and maintaining Hibernate :-)

thanks for the feedback.
Also, if you happen to find punctual things you would like to fix remember it's open source: patches to documentations are very welcome.
Soonish we'll provide a public web application to ease contributions from translators too.