geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject xbeans and OSGi
Date Mon, 02 Nov 2009 16:38:56 GMT
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

Mime
View raw message