Browse Prior Art Database

A simple algorithm for determining the full set of visible resources on the classpath of an OSGi bundle Disclosure Number: IPCOM000192654D
Original Publication Date: 2010-Jan-27
Included in the Prior Art Database: 2010-Jan-27
Document File: 3 page(s) / 58K

Publishing Venue



There are many applications and libraries in Java that rely on being able to list the contents of a ClassLoader's Class Path. These libraries often fail when deployed in an OSGi framework due to the radically different ClassLoader hierarchy. This article outlines an algorithm for listing the complete set of resources accessible via an OSGi bundle's ClassLoader. This algorithm can be used to perform the equivalent of Class-Path scanning in a JSE or JEE environment, and can be used to provide the functionality expected in these libraries. This algorithm does not rely on provider specific interfaces, and can be implemented on any compliant OSGi framework.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 3

A simple algorithm for determining the full set of visible resources on the classpath of an OSGi bundle

When OSGi was originally architected great pains were taken to remove access to Java*ClassLoaders, abstracting them behind the org.osgi.framework.Bundle interface. This interface is the runtime representation of an OSGi module (typically known as a bundle), and has the ability to load classes and resources from the module's classpath. The visible resources include not only classes and resources contained within the module, but also resources that are expressed as dependencies. These dependencies can be expressed as a dependency on the whole of, or part of, another module.

    The Bundle interface also provides access for listing the contents of the bundle, this however is limited to the direct content of the bundle, and does not include any dependencies from other modules.

    There are typically many classes in an OSGi bundle, and there may be multiple classpath roots (for example jar files inside the bundle, or a directory path within the bundle). A common use case for enterprise middleware is to locate the classes in a module, and scan or manipulate them in some fashion (for example to search for classes containing Java annotations). In OSGi there exist simple APIs to list the content of a particular bundle, but there is no mechanism to list the resources that are visible via the bundle's classpath and dependencies.

    This places serious limitations on the scanning that is possible, for example there may be annotations present on dependencies which cannot be located through the standard API. There may also be additional configuration visible to the bundle pulled in as a dependency. Failure to read this configuration may lead to incorrect behaviour in the runtime. Further to this, the container may wish to perform some level of bytecode weaving or other Aspect Oriented Programming techniques. In order to perform this correctly it will be necessary to view the entire classpath, not

just the content of the bundle.

    SpringSource attempt to get around this problem by requiring configuration to list the classes or resources that need to be accessed. pp-ctx:osgi-resource

    This article proposes a recursive algorithm based on existing OSGi API calls that can be used to build up a full, or filtered, list of accessible resources.

    By following this algorithm the caller will generate a list of all resources visible to a resolved OSGi bunde (i.e. all resources that can be loaded by calls to Bundle.getResource()). This means that the bundle can accurately be scanned for annotations, configuration and byte-code weaving.

    Note that this algorithm correctly applies the OSGi search rules. Import-Package statements are searched first, then Require-Bundle statements, then the Bundle-Classpath. It also correctly applies package shadowin...