On Oct 20, 2009, at 8:29 AM, Jarek Gawor wrote:
Actually, I think that we should restore the loadGBean(GBeanData,
ClassLoader) method and use BundleReference to get the Bundle for the
classloader. It would probably get things going a bit more and
probably just work in most cases. If it doesn't work then we can come
in and change the API to add additional methods to get the Bundle.
I haven't found that modifying gbean code to use Bundle instead of
ClassLoader for classloading is a significant amount of work. IMO if
we are going to orient ourselves towards osgi we should use the osgi
conventions wherever they are reasonably easy to adapt to. This case
is certainly one of them.
thanks
david jencks
Jarek
On Tue, Oct 20, 2009 at 7:58 AM, Rick McGuire <[email protected]>
wrote:
I just started taking a look at converting the Tomcat plugon to the
brave
new OSGi world, and immediately ran into a problem that's likely to
be a
fairly generic problem that other plugins might also have. In the
method
TomcatManagerImpl.getConnectorConfiguration(), there's the
following code
that causes a compilation error:
try {
kernel.loadGBean(gbeanData,
container.getClass().getClassLoader());
kernel.startGBean(name);
} catch (Exception e) {
log.error("Error when adding new tomcat connector" +
uniqueName,
e);
}
the loadGBean() method now takes a BundleContext rather than a
classloader,
so there's a signature error. The container is an object that
implements
the WebContainer interface (either the Tomcat or Jetty version).
The intent
here is to load some GBeans using the container object's
configuration
context via its classloader. In order for this to work now,
getConnectorConfiguration() will need to somehow obtain the
container's
BundleContext rather than a class loader. This is something that's
not
easily done at the moment. I see a couple of potential solutions:
1) Make the WebContainers context aware and add a
getBundleContext() method
to the WebContainer interface. 2) Use the BundleReference interface
introduced in the 4.2 OSGi framework to obtain the bundle from the
object's
defining classloader.
I suspect that 1) is the cleaner solution. 2) has a potential
downside that
it depends on the WebContainer implementation class being located
within
configuration bundle. A restructuring of the bundles to improve
modularity
could potentially cause this to fail, which would not really be a
solid
structure.
I think I've convinced myself that 1) is the correct approach, but
thought
this was something worthing of raising as a discussion point on the
dev
list.
Rick
