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