xbeans and OSGi

[Rick McGuire <ri...@gmail.com>]

I've been wrestling with some build problems involving xbeans and 
bundles since the middle of last week, and I've finally gotten the 
specific error I was working on to go away.  I'm not entirely happy with 
what I needed to do to fix this, so I think this needs a little 
discussion.  First, some specifics on what I've found.

1)  The problem.  This problem was showing up when trying to build the 
system-database plugin.  It was starting the connector-deployer-1_6 
plugin and getting a NullPointerException inside the xmlbeans runtime 
after calling getEnvironment() on the ConnectorDocument class.  This was 
happening because the xmlbeans runtime was unable to locate the type 
information for the environment property of the document.

2)  The cause.  This situation was occurring because the 
ConnectorDocument class uses property types defined in the 
geronimo-system-builder module.  At first, I thought this was due to 
some missing imports for the org.osgi.geronimo.deployment.xbeans.impl 
and org.osgi.geronimo.deployment.javabean.xbeans.impl packages.  I spent 
a couple days trying to get these imports correctly defined, but adding 
these did not clear up the NullPointerException on the getEnvironment() 
call. 

3)  Finally, after poking around in xmlbeans a little, I figured out the 
issue was not the implementation classes, but rather the .xsb files.  
The directories where these are contained also needed to be exported by 
the defining bundles and also imported by the using bundles. 

Item 3 is where the problems come in.  Because of the way xmlbeans 
generates the type information, there are lots of packages that need to 
be exported and imported to make things work.  Importing was fairly 
easy, since the bnd tool allows wildcards.  Importing is another matter 
entirely.  Since the referencing bundles don't contain any code 
references to these packages, the bnd tool is unable to generate this 
directly.  Any since there are a lot of directories involved that have 
very cryptic names, it really doesn't look practical to hand generate 
each of these either.

A solution that did work is to use Require-Bundle to have all of these 
packages get imported by the using bundle at runtime.  I'm not terribly 
happy with having to resort to this, but bnd doesn't have a capability 
of doing the static equivalent of a Require-Bundle when generating the 
manifest.  The combination of export all of those packages and using 
Require-Bundle finally made the NullPointerException go away.

In the course of fixing this, I also added a couple of enhancements to 
the car-maven-plugin to allow the manifest to be augmented by additional 
Import-Package and Require-Bundle information.  This looks like it is 
going to be additional metadata that we'll require in some of these 
dynamic classloading situations.

I'll update the wiki with the workarounds I've found for this problem 
once we're comfortable with the approach needed to fix this.

Rick

Re: xbeans and OSGi

[Ivan <xh...@gmail.com>]

Thanks, Rick, I got this issue too while trying to remove the classloader
plugins :-)
I guess that only those *-builder will need to import those xmlbeans
gernated classes, shall we use a tool to scan and generate the whole package
list, then add them to those pom files.
I remembered that long ago, there is a discussion about removing xmlbeans
from Geronimo, and use jaxb to parse and generate the plan file, Maybe we
could do it in 3.0.

2009/11/3 Rick McGuire <ri...@gmail.com>

> I've been wrestling with some build problems involving xbeans and bundles
> since the middle of last week, and I've finally gotten the specific error I
> was working on to go away.  I'm not entirely happy with what I needed to do
> to fix this, so I think this needs a little discussion.  First, some
> specifics on what I've found.
>
> 1)  The problem.  This problem was showing up when trying to build the
> system-database plugin.  It was starting the connector-deployer-1_6 plugin
> and getting a NullPointerException inside the xmlbeans runtime after calling
> getEnvironment() on the ConnectorDocument class.  This was happening because
> the xmlbeans runtime was unable to locate the type information for the
> environment property of the document.
>
> 2)  The cause.  This situation was occurring because the ConnectorDocument
> class uses property types defined in the geronimo-system-builder module.  At
> first, I thought this was due to some missing imports for the
> org.osgi.geronimo.deployment.xbeans.impl and
> org.osgi.geronimo.deployment.javabean.xbeans.impl packages.  I spent a
> couple days trying to get these imports correctly defined, but adding these
> did not clear up the NullPointerException on the getEnvironment() call.
> 3)  Finally, after poking around in xmlbeans a little, I figured out the
> issue was not the implementation classes, but rather the .xsb files.  The
> directories where these are contained also needed to be exported by the
> defining bundles and also imported by the using bundles.
> Item 3 is where the problems come in.  Because of the way xmlbeans
> generates the type information, there are lots of packages that need to be
> exported and imported to make things work.  Importing was fairly easy, since
> the bnd tool allows wildcards.  Importing is another matter entirely.  Since
> the referencing bundles don't contain any code references to these packages,
> the bnd tool is unable to generate this directly.  Any since there are a lot
> of directories involved that have very cryptic names, it really doesn't look
> practical to hand generate each of these either.
>
> A solution that did work is to use Require-Bundle to have all of these
> packages get imported by the using bundle at runtime.  I'm not terribly
> happy with having to resort to this, but bnd doesn't have a capability of
> doing the static equivalent of a Require-Bundle when generating the
> manifest.  The combination of export all of those packages and using
> Require-Bundle finally made the NullPointerException go away.
>
> In the course of fixing this, I also added a couple of enhancements to the
> car-maven-plugin to allow the manifest to be augmented by additional
> Import-Package and Require-Bundle information.  This looks like it is going
> to be additional metadata that we'll require in some of these dynamic
> classloading situations.
>
> I'll update the wiki with the workarounds I've found for this problem once
> we're comfortable with the approach needed to fix this.
>
> Rick
>



-- 
Ivan