Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Using OSGi Metadata with a Standard Class Loader - David Kemper


Published on

OSGi DevCon 2008

OSGi defines metadata describing dependencies between software components and how together they form a consistent and loosely-coupled system. OSGi forms the basis of the Eclipse development environment which we use as our customer design-time environment. This talk explores how to use the OSGi descriptive metadata in non-OSGi runtimes. This includes some best practices for componentization, approaches to building software aggregates, validation of the build products, and troubleshooting any problems that arise.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Using OSGi Metadata with a Standard Class Loader - David Kemper

  1. 1. Using OSGi Metadata with a Standard Class Loader David Kemper Principal Architect TIBCO Software Inc.
  2. 2. © 2008 TIBCO Software Inc. All Rights Reserved. Why use OSGi metadata without an OSGi runtime? • Why not use an OSGi runtime? • Implementing a specific standard with its own class loader model (for example J2EE) • Simple use case like a command-line tool where OSGi is overkill • Required to use legacy runtime (for example based on a URLClassLoader) • But when you are not in OSGi… • Duplicate packages will collide • Un-exported packages are visible • You can’t run against multiple versions of a component • Fragments and singletons have no special meaning in the runtime • You often cannot use “packed” plugins (a jar-within-a-jar) • Why use OSGi metadata? • Rich description of the dependencies between jars • Co-located with the component itself, so easy to carry through to runtime • Tools can use the metadata for validation and runtime provisioning • Eclipse tooling supports the creation and management of this metadata 2
  3. 3. © 2008 TIBCO Software Inc. All Rights Reserved. How do you provision with OSGi metadata? • Given a store of plugins and features and a set of initial constraints, determine the optimum, minimal set of plugins that satisfy the constraints • It is helpful to define initial constraints using Eclipse features • Reuse Eclipse packaging infrastructure • Customers exposed to less detail • Use Equinox for the heavy lifting • Leverage infrastructure already available to the Eclipse design time; don’t reinvent the wheel • Equinox externalizes and supports its resolver APIs • Feature dependencies look like Require-Bundle constraints 3
  4. 4. © 2008 TIBCO Software Inc. All Rights Reserved. Examples 4 App Server WAR Store … Feature Plugin shared Equinox Resolver URLClassLoader or
  5. 5. © 2008 TIBCO Software Inc. All Rights Reserved. What are some of the challenges? • You’ll want to filter your inputs and outputs • You don’t want to resolve all metadata from your store because it doesn’t scale well and is overly constrained • Support for a shared class path or screening specific versions add complexity • Going from a set of plugins to a Java class path is more work • Java class path is not generated by the Equinox Resolver • You have to take fragments into account • Native library paths are available in version 3.4 • Interpreting Equinox Resolver errors is not straightforward • You have to dig for the root cause of an unresolved plugin and correlate it back to the input constraint 5
  6. 6. © 2008 TIBCO Software Inc. All Rights Reserved. Questions • David Kemper TIBCO Software Inc. 6