persistence@glassfish.java.net

Re: JPA packaging

From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Mon, 29 Jan 2007 14:47:17 -0800

Hi Peter,

On Jan 23, 2007, at 10:27 AM, Peter Krogh wrote:

> Hi,
>
> There is a packaging issue that some of us started talking about on
> the phone, and we agreed to bounce this around the alias.
>
> We have seen a problem when bundling Spring and TLE in a Tomcat web
> app, and using annotations on entity classes. If the weaver is
> being used (as it is by default) the deployment will run into a
> problem that is manifested by TopLink not recognizing any of the
> annotations. This is brought on because:
>
> - Web loaders check locally before they check in the parent loaders
> for classes

This is an optional feature for web classloaders. The user has the
option of checking parent classloaders before locally loading. A
general solution would allow for both check-parent and not check-
parent for classes.

> - TLE packages the JPA annotations in toplink-essentials.jar
> - The weaver uses the temporary class loader to look for entity
> classes
>
> The solution so far is to take toplink-essentials.jar out of the
> war and placing it on the Tomcat server classpath. Other (more
> intrusive) ways to resolve the problem are:
>
> - not use annotations
> - turn off weaving
> - not use the container-API, just the bootstrap API
> - delete the annotations from the toplink-essentials.jar and put
> them in a jar on the server classpath
>
> The solution of having to put the TopLink Essentials jar on the
> Tomcat server classpath is really not a very friendly answer.
>
> What would be involved in taking the annotations out of toplink-
> essentials.jar?

In order to have the temporary class loader use the same class
definition as the jar class loader, the annotations need to be in a
separate jar file that is available to the server. That is, put the
annotations into the Tomcat server class loader and leave the TopLink
Essentials code in its own jar file.

This should allow for these configurations:

1. Deploy the web app with its own version of TLE that is different
from Tomcat's version.
2. Deploy the web app with a version of TLE that is the same as
Tomcat's version.
3. Deploy the web app with TLE even if Tomcat doesn't ship TLE.
4. Deploy the web app without any TLE at all, if TLE is already in
Tomcat's server classpath.

But without changing the Tomcat web classloader implementation, it
will still be impossible to deploy a web app when the user specifies
"not check-parent" and the only TLE is in the web jar.

To implement the strategy, we need to create a persistence-only jar
and a TLE-only jar. It is still an option to continue to ship a TLE
+persistence jar that contains both.

Craig

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!