On Nov 22, 2009, at 6:01 PM, Ivan wrote:
For a EJB/WAR, I could see what Bundle-ClassPath contains. But for
an EAR package, what does it contain, all the jar files in the
libraries, ejb jars and web related classes ? I am just thinking
what the classloader structure of an EE application, especially for
an EAR application. In the classic environment, for an EAR contains
libraries and webapplications, we usually create a parent
classloader for the EAR, and create a classloader for WAR package.
Then, in the OSGI environment, how should it be ?
If only a bundle classloader is created and the bundle-classpath
contains all the embedded jar files/classes, will it break the EE
rules ? How about dividing the ear package into more than one bundle ?
Thanks !
There are two issues I know of:
1. osgi allows only one level of nesting of jars, whereas ee allows 2
(jars inside rars and wars). This isn't really a problem for us since
we repackage the ear anyway so we can (continue to) unpack as many
nesting levels as we want (as we do now).
2. Currently wars are set up as semi-independent configurations. I
guess we will want to have them as additional bundles. I haven't
figured out a good plan for this yet. We've thought about deploying
ejb modules and rar modules as separate configurations also, perhaps
this will turn out to be an easy thing to do.
Right now I'm concentrating on getting a single war or rar to
deploy.... then we can think more about ears.
BTW at the moment I'm putting the osgi info into the Environment
object and generating the manifest from that.
thanks
david jencks
2009/11/21 David Jencks <[email protected]>
I've played with the welcome app servers a bit and found that the
next significant problem is that we aren't setting the Bundle-
ClassPath manifest header in our car bundles. This shouldn't be an
obstacle for ejb jars, but is for anything else.
My plan is to solve this as part of GERONIMO-4911 by storing all the
manifest info in the ConfigurationData. Perhaps this can replace
some of the info in the environment field, although that is also
used to figure out which plugins need to be started before the
current one.
comments welcome...
thanks
david jencks
--
Ivan
