Actually, just verified in code that libraries included in the ear are not automatically scanned for persistence annotations...
On Wed, May 2, 2012 at 2:17 PM, Julian Klappenbach <[email protected]> wrote: > I'm having a hard time deploying an ear. It contains two ejb modules, > and a library folder containing a jar file with annotated > entities. These entities need to be shared over several persistence > modules in several different ears, and for my reasons, it doesn't make > a lot of sense to package them up into an ejb that is shared on it's > own. Basically, the entities don't change, but the business logic > governing them does, depending on the context. > > ts-3.0 > ts-3.0/common-ejb-3.0.jar > ts-3.0/lib > ts-3.0/lib/common-jar-3.0.jar > ts-3.0/lib/jgroups-2.9.0.GA.jar > ts-3.0/META-INF > ts-3.0/META-INF/application.xml > ts-3.0/ts-ejb-3.0.jar > > I was going to use <jar-file> but it appears that all ear library > files are processed for annotations. Perhaps only <class> tags are > necessary. However, the processing of the library throws an issue at > AbstractCFMetaDataFactory (line 706 in 3.0b1). The URL that is > created for the library > file can not be found. > > I have something like: > > jar:bundleentry://475.fwk2002021820/../lib/common-jar.jar!/ > > Where in my file system, I have: > > ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/common-ejb-3.0.jar > ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/lib/common-jar-3.0.jar > ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/lib/jgroups-2.9.0.GA.jar > ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/ts-ejb-3.0.jar > > I know the ".." was from a previous bug fix, where paths are computed > from the root of the EJB, and not the EAR, making the reference. > However, it seems as though that convention does not translate to how > jars are processed and exploded under the bundle on the filesystem. > If I need additional meta-data, or if there's additional documentation > (an example build demonstrating the ability), I'm all ears. > > Otherwise, I'll deal with this from a dev perspective. > > -jjk
