You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2009/10/20 13:58:22 UTC
Converting classloaders to BundleContexts
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
Re: Converting classloaders to BundleContexts
Posted by David Jencks <da...@yahoo.com>.
On Oct 20, 2009, at 9:43 AM, Rick McGuire wrote:
> David Jencks wrote:
>>
>> On Oct 20, 2009, at 5:08 AM, Rick McGuire wrote:
>>
>>> Rick McGuire 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.
>>> Ok, I immediately ran into another question while looking to
>>> implement this. Should the getBundleContext() method be pushed to
>>> the J2EEManagedObject interface so that this would be a
>>> requirement for all J2EEManagedObjects? These objects are already
>>> required to implement getObjectName(). It perhaps would make
>>> sense to also require getBundleContext(). Another possibility
>>> would be to have a kernel call that can return the BundleContext
>>> associated with a unique object name rather having each managed
>>> object implement the second method. For now, I'm going to proceed
>>> with the solution that adds getBundleContext() to the WebContainer
>>> interface and will adjust this if there is consensus on another
>>> option.
>>
>> I think what you are proposing is the best option. I don't like
>> the J2EEManagedObject stuff, I think its there to support jsr77 and
>> usually seems to me like a big nuisance. As you say (2) won't work
>> since you want the bundle the web server is deployed from, not the
>> bundle its classes come from.
> Just to be clear, which of the possibilities I described do you
> consider the best option?
Make the specific gbean bundle or bundle context aware, add a getter
to it, and avoid generalizing the solution more than necessary.
thanks
david jencks
>
> Rick
>
>
>>
>> thanks
>> david jencks
>>
>>>
>>> Rick
>>>
>>>>
>>>> Rick
>>>>
>>>
>>
>>
>
Re: Converting classloaders to BundleContexts
Posted by Rick McGuire <ri...@gmail.com>.
David Jencks wrote:
>
> On Oct 20, 2009, at 5:08 AM, Rick McGuire wrote:
>
>> Rick McGuire 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.
>> Ok, I immediately ran into another question while looking to
>> implement this. Should the getBundleContext() method be pushed to
>> the J2EEManagedObject interface so that this would be a requirement
>> for all J2EEManagedObjects? These objects are already required to
>> implement getObjectName(). It perhaps would make sense to also
>> require getBundleContext(). Another possibility would be to have a
>> kernel call that can return the BundleContext associated with a
>> unique object name rather having each managed object implement the
>> second method. For now, I'm going to proceed with the solution that
>> adds getBundleContext() to the WebContainer interface and will adjust
>> this if there is consensus on another option.
>
> I think what you are proposing is the best option. I don't like the
> J2EEManagedObject stuff, I think its there to support jsr77 and
> usually seems to me like a big nuisance. As you say (2) won't work
> since you want the bundle the web server is deployed from, not the
> bundle its classes come from.
Just to be clear, which of the possibilities I described do you consider
the best option?
Rick
>
> thanks
> david jencks
>
>>
>> Rick
>>
>>>
>>> Rick
>>>
>>
>
>
Re: Converting classloaders to BundleContexts
Posted by David Jencks <da...@yahoo.com>.
On Oct 20, 2009, at 5:08 AM, Rick McGuire wrote:
> Rick McGuire 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.
> Ok, I immediately ran into another question while looking to
> implement this. Should the getBundleContext() method be pushed to
> the J2EEManagedObject interface so that this would be a requirement
> for all J2EEManagedObjects? These objects are already required to
> implement getObjectName(). It perhaps would make sense to also
> require getBundleContext(). Another possibility would be to have a
> kernel call that can return the BundleContext associated with a
> unique object name rather having each managed object implement the
> second method. For now, I'm going to proceed with the solution that
> adds getBundleContext() to the WebContainer interface and will
> adjust this if there is consensus on another option.
I think what you are proposing is the best option. I don't like the
J2EEManagedObject stuff, I think its there to support jsr77 and
usually seems to me like a big nuisance. As you say (2) won't work
since you want the bundle the web server is deployed from, not the
bundle its classes come from.
thanks
david jencks
>
> Rick
>
>>
>> Rick
>>
>
Re: Converting classloaders to BundleContexts
Posted by Rick McGuire <ri...@gmail.com>.
Rick McGuire 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.
Ok, I immediately ran into another question while looking to implement
this. Should the getBundleContext() method be pushed to the
J2EEManagedObject interface so that this would be a requirement for all
J2EEManagedObjects? These objects are already required to implement
getObjectName(). It perhaps would make sense to also require
getBundleContext(). Another possibility would be to have a kernel call
that can return the BundleContext associated with a unique object name
rather having each managed object implement the second method. For now,
I'm going to proceed with the solution that adds getBundleContext() to
the WebContainer interface and will adjust this if there is consensus on
another option.
Rick
>
> Rick
>
Re: Converting classloaders to BundleContexts
Posted by David Jencks <da...@yahoo.com>.
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 <ri...@gmail.com>
> 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
>>
Re: Converting classloaders to BundleContexts
Posted by Jarek Gawor <jg...@gmail.com>.
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.
Jarek
On Tue, Oct 20, 2009 at 7:58 AM, Rick McGuire <ri...@gmail.com> 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
>