Space: Apache Tuscany Docs 2.x (http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x) Page: Classloading (http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Classloading)
Added by Simon Laws: --------------------------------------------------------------------- Need to detail the various ways the Tuscany runtime loads classes and the issues involved. Here are some notes to kick of this document h1. Classloading Objectives The runtime must work in both OSGi and non-OSGI environments. I.e. we can't rely on the OSGi service registry for extensibility The runtime must not be genberally environment specific. I.e. no buddy classloading ... h1. General Patterns h2. Extension loading - JSE tuscany-extensibility Tuscany finds extensions by looking for META-INF/services files on the classpath. h2. Extension loading - OSGi tuscany-extensibility-equinox It's a bit more complicated here. The extensibility-equinox bundle is given the entire OSGi context at start up and from there is looks in all of the loaded bundles looking for META-INF/services files. It caches them against the bundle in which they are found. The tuscany-extensibility-equinox bundle also has a dynamic import DynamicImport-Package: org.apache.tuscany.sca.extensibility.equinox, javax.transaction;version="1.1", javax.transaction.xa;version="1.1", Which allows it to generally load any classes in the runtime h2. Split Packages h2. Third-party libraries - JSE TBD h2. Third-party libraries - OSGI Third-party libraries often rely on TCCL to load implementation classes in an extensible way. For example, the SDO API loads the HelperContext implementation in this way. In an OSGi environment there will not be a static dependency between the api bundle and the impl bundle so we need to fake it. Typically we do this by setting up the TCCL appropriately before the library us called. See ClassLoaderContext which help us to set up a multi-classloader configurations. Typically in OSGi one of the classloaders we pass in here will be the extensibiliy-equinox bundle classloader (the ServiceDiscoverer) as this bundles has a dynamic import which allows it to load any class in the runtime. h2. Tuscany Node API - JSE TBD h2. Tuscany Node API - OSGi There are a small number of Tuscany Jars you need to use in the app launcher in the OSGi environment tuscany-sca-api tuscany-node-api tuscany-node-launcher-equinox The node API has to load the node implementation and has a dynamic import in its manifest DynamicImport-Package: org.apache.tuscany.sca.node.impl,org.apache.tuscany.sca.extensibility h2. SCA Client API - JSE Factory finder impl is injected into the API class by the implementation h2. SCA Client API - OSGi NodeFactory maintains a NodeProxy inner class that supports cross-classloader calls. The calling client api will have been loaded by the app classloader but the underlying node will have been loaded by a bundle classloader. We need to bridge that gap. Change your notification preferences: http://cwiki.apache.org/confluence/users/viewnotifications.action
