If you specify <jar-file>xxx</jar-file> in your persistence.xml, your file will be located to
new File(new URL("file://"+xxx).getFile())
As getFile() return an absolute URL, your xxx jar must be an absolute path (or a path relative to the current system root, e.g. C:/). The documentation is not clear about that and what you describe as
I cannot user jar-file definitionshould be simply that the persistence provider cannot find the given JAR.
Thus, you can locate your xxx jar outside the WAR, e.g. in the JEE server library directory. We used <jar-file>/myDir/xxx.jar</jar-file> to access the JAR file located at c:/myDir/xxx.jar.
At first, we wanted to use this solution to package entities from our home-made framework to the new applications developped using Seam. But this was not possible because of conflicts when the home-made framework entities are the same as the entities defined in the new Seam project (for example, an entity field is first mapped with its Long foreign key, then the other mapping maps to the foreign object directly).
We found simpler to share the mappings by using the seam-gen.reveng.xml file: the mappings from the home-made framework seam-gen.reveng.xml are copied into the new Seam project seam-gen.reveng.xml. Thus, the home-made framework JAR does not contain entities: they are all mapped by the new Seam project.
The only constraint of our solution is that you will need to keep the JAR and the seam-gen.reveng.xml consistent. To do so, we develop the home-made framework using its own mappings in seam-gen.reveng.xml, then build the JAR without the entities but with the seam-gen.reveng.xml (it will stay inert in the JAR, i.e. will not be used as deployment descriptor, but programmers that are using the JAR can find the corresponding mappings easily: they just need to copy/paste the mappings in their own seam-gen.reveng.xml file).
Thanks Julien for your input,
Using an absolute path in jar-file is out of the question. Using a relative path fails, I tried:
All miserably failed so I don't know exactly where JBoss 4.2/Seam 2.0.1 is trying to resolve jar-file (what is the current dir being used?)
I agree, using absolute paths in this situation is really nasty, especially if the app is deployed to different environments. The only real solution is to fix this.
There is a bug in hibernate when you use a WAR to package your web app, with a WEB-INF/lib/persistence-unit.jar containing a /META-INF/persistence.xml and using <jar-file> to refer to other jar files in the WAR's WEB-INF/lib directory which contain your Entity classes See: http://opensource.atlassian.com/projects/hibernate/browse/EJB-374
Instead of using a path relative to the persistence unit root (as per JSR220 spec) hibernate tries to load the <jar-file> relative to where your jboss app server was started (something like C:\LocalDev\jboss-4.2.2.GA\bin). This is an acknowledged bug and a patch is provided for hibernate-entitymanager in the link above. I have applied this patch to hibernate-entitymanager-3.3.2.GA and had it successfully work with relative paths. The biggest hurdle for me was to upgrade hibernate in my web app to hibernate-3.2.6.GA and hibernate-entitymanager-3.3.2.GA, but the instructions for that can be found here: http://jaitechwriteups.blogspot.com/2008/08/how-to-upgrade-hibernate-in-jboss.html
Hopefully this bug will be fixed in the next release of hibernate. You should vote for this at http://opensource.atlassian.com/projects/hibernate/browse/EJB-374