[jira] [Created] (XBEAN-240) XBean Finder OSGi packaging

["Timothy Ward (JIRA)" <ji...@apache.org>]

Timothy Ward created XBEAN-240:
----------------------------------

             Summary: XBean Finder OSGi packaging
                 Key: XBEAN-240
                 URL: https://issues.apache.org/jira/browse/XBEAN-240
             Project: XBean
          Issue Type: Bug
          Components: finder
    Affects Versions: 3.12
         Environment: Felix 4.2.0, Java 1.6.26, 
            Reporter: Timothy Ward


I've been using XBean finder while putting together some test platforms, and I've found a couple of issues. The examples I'm giving are for the shaded finder, but they probably apply across multiple components.

The Import Specification for xbean-finder-shaded is:

Import-Package: org.apache.xbean.asm,org.apache.xbean.asm.commons;reso
 lution:=optional,org.apache.xbean.asm.signature;resolution:=optional,
 org.apache.xbean.osgi.bundle.util;resolution:=optional,org.osgi.frame
 work;resolution:=optional,org.osgi.service.packageadmin;resolution:=o
 ptional,org.slf4j;resolution:=optional

As you can see, all of the imports are optional, and have no version ranges. The version ranges should be fixed, but it's the optional part that's causing me issues. 

I'm obviously not deep enough in the details to know whether this bundle can work without ASM or not (optional SLF4J seems more likely), but I know that if you're scanning an OSGi bundle then the org.apache.xbean.osgi.bundle.util import is *not* optional.

At the moment this fails with a NoClassDefFoundError if the bundle utils bundle wasn't present when the finder bundle resolved. Ideally there will be two parts to this fix.

a) Add org.apache.xbean.osgi.bundle.util as a dynamic package import. This will remove the ordering dependency between installing/resolving the finder and bundle utils bundles. Doing this prevents me having to refresh all my bundles.

b) When running down the "bundle" scanning path then attempt to load the  Bundle Utils classes first (catching the potential exception) and log a nice error if it fails (rather than a NoClassDefFoundError). Once this lookup has succeeded once then you don't need to run the try/catch again.


It would also be a good idea to put version ranges on the package imports, although this isn't currently causing me a problem, it would if I tried to use XBean 3.12 at the same time as 3.11!

I hope this bug report doesn't sound overly negative. Aside from this issue it was really easy to get XBean up and running in OSGi, and I'm very pleased with the results!

Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira