We have:
- JSFTemplating (which is a repackaged OSGi bundle) uses the
context classloader to reflectively invoke Java code in "plugin"
bundles. (Plugin bundles are OSGi bundles which provide a @Service
implementation as a marker interface. The code being invoked does not
implement any interface, although it is annotated w/ JSFTemplating's
@Handler annotation.)
- JSFTemplating uses a custom classloader which finds the correct
plugin bundle and searches it for resources (.jsf pages, images,
etc.). It also does this for locating configuration files when it
initializes itself.
- JSF searches for faces-config.xml files which may exist in
multiple places (WEB-INF/faces-config.xml, META-INF, inside a jar in
the WEB-INF/lib, or inside a plugin OSGi bundle).
- JSF invokes code (via context classloader, I think) to
instantiate managed beans defined in any of the same locations JSF
supports the faces-config.xml files (web app, or OSGi plugins).
- Plugins may invoke code defined in other plugins or OSGi bundles
-- this is easy as they can depend on OSGi imports for this. (They
typically depend on JSFTemplating which invokes other code on their
behalf -- see above.)
- The web-application invokes code in OSGi bundles directly
(JSFTemplating, amx, GF-api, etc.). I think the number of different
OSGi bundles will be decreasing as this responsibility gets pushed to
individual plugin bundles. However, JSFTemplating will remain and
likely a few others.
I think that's it...
I'll look for your earlier thread on this topic. Although I don't
understand how our web application can import bundles without
configuring it somewhere. The Glassfish-require-services is unique in
that we can import all bundles which implement a particular HK2
@Contract -- not sure how we can do without that as we don't know what
to import when we build our web application (we have to import all
plugins that may be implemented in the future).
Thanks!
Ken
Sahoo wrote:
Ken,
I am assuming most of your code uses Thread's context class loader,
which in your case is WebAppClassLoader, to load classes. With my
latest changes to application class loading hierarchy (see an earlier
to dev@ on similar subject), most of your problems should go away even
when you don't use HK2-Import-Bundles and GlassFish-require-services
headers. I strongly recommend limited use of them as the classloading
does not follow a well defined delegation policy in the presence of
those entries, so there can be hard to debug ClassCastExceptions in
webapp. They are OK as far as resource finding goes. I once tried
running admingui without those entries in my local workspace, and it
did not work because JSF could not find faces-config.xml from two other
bundles that your admingui depends on. I did not pursue further. But,
if that is the only problem, then it should JSF's responsibility to
solve this issue in an OSGi environment using some kind of extender.
What other classloading requirements do you have?
Thanks,
Sahoo
Ken Paulsen wrote:
Hi Sahoo,
I've had the Class.forName issue in the back of my mind for a while
now. Web framework code does this a lot (JSF does, jsftemplating does,
woodstock does). Are the fixes Jerome provided
(Glassfish-require-services & HK2-Import-Bundles) enough to work
around all the problems? I haven't seen any issues come up, but I
haven't been deploying multiple applications which use these OSGi
bundles concurrently.
I'll look for the ant bnd plugin, that's exactly what I need...
Ken
Sahoo wrote:
Ken Paulsen wrote:
Hi,
In GF v3 just about everything is an OSGi bundle. This including all
our plugins to our admin console as well any code those plugins rely
on. This means, in order to use the Woodstock UIComponents (or any
other woodstock code) from a plugin, then woodstock needs to be
packaged as an OSGi bundle.
We can either repackage the webui.jar (and potentially others -- I'm
already doing dataprovider.jar) as an OSGi bundle during our build
process. However, doing that does not help anyone else that wants
Woodstock as an OSGi bundle. It would be very nice if you added the
MANIFEST.MF entries necessary to use your jar files in an OSGi
environment. Nothing else would need to change, just the MANIFEST.MF
file.
Without looking at the code, I can't say that. If it does Class.forName
or META-INF/services lookup, then in order to be used in pure OSGi
environment, those code have to be revisited.
I'm not sure how to best automate this using ant (Sahoo, do you
know?). Although I can show you how this can be done using the maven
bnd plugin. Either way, this would be better than creating/maintaining
the MANIFEST entries by hand.
Yes, there is an Ant plugin to bnd as well. Just search for it; I don't
have the link handy.
Thanks,
Sahoo
If you want help doing this, I'm willing to do the work.
Thanks!
Ken