Description Michael OBrien 2011-01-14 09:51:23 EST

>Issue: Updating the bundle modules in GlassFish V 3.0.1 fails if the bnd jar is in the trunk dir root
The following ant target that generates modules has 2 issues in GlassFish
trunk>ant dev-package-bundles
1) it rebuilds bundles that have modified code only - this is normal and good but GlassFish seems to use the File date as comparison on whether to update bundles (fix is to wipe the felix osgi_cache off your domain - after a server stop)
2) the bundles that are generated using a local trunk [bnd-0.0.384.jar] fail to get recognized by GlassFish (the default manifests or another bnd jar should be used)

>Scope:
GlassFish 3.0.1 ships with EclipseLink 2.1 rev # 6600.
Users and developers may want to upgrade their version of the 6 EclipseLink bundles and the javax.persistence.jar shipped with GlassFish.
>Need to verify that this also occurs in 2.3 trunk - and not just 2.2

With the bnd jar in trunk we see the following when we attempt to use the updated EclipseLink bundles in GlassFish if a JTA JPA EAR is predeployed on server start.

Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.eclipse.persistence.jpa.PersistenceProvider
	at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:155)
	at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:96)
	at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:121)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:644)
	at org.glassfish.javaee.full.deployment.EarDeployer.prepareBundle(EarDeployer.java:269)
	at org.glassfish.javaee.full.deployment.EarDeployer.access$200(EarDeployer.java:79)
	at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:131)
	at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:129)
	at org.glassfish.javaee.full.deployment.EarDeployer.doOnBundles(EarDeployer.java:197)
	at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllTypedBundles(EarDeployer.java:206)
	at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllBundles(EarDeployer.java:232)
	at org.glassfish.javaee.full.deployment.EarDeployer.prepare(EarDeployer.java:129)
	... 28 more
Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.jpa.PersistenceProvider
	at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:736)
	at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:626)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:149)
	... 39 more
|#]
>Analysis:
I moved from an i7 machine that had no previous issues to a new XP machine - but for some reason copied bnd to my 2.2 trunk

I spent about 3 hours trying to update GlassFish and had the help of Tom and Mitesh - in the end I used the bundles from my 2.3 trunk build which just happened not to have bnd in its trunk - this worked.

>Fix: remove bnd from the trunk directory

>Note: when building and replacing the 6 EclipseLink bundles - observe the following (worked out with Mitesh)
- The bnd jar should not be in the root of your SVN view - or the manifest files will not be generated correctly and GlassFish felix will not properly update the bundles
bnd-0.0.384.jar
- The file date (not the date in the manifest) - should be later than the file date of the bundle you are replacing or...
- Remove the felix cache off the osgi-cache on the domain (so the new bundles will override the previous ones)