Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by LeeSurprenant: http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java/Classloader_Architecture The comment on the change is: Summary of classloader architecture from note by Jeremy Boynes New page: Tuscany's SCA Java implementation provides a fairly sophisticated classloader structure. The current structure involves two fairly simple trees with a common root. This common root is the "host" classloader supplied by the host environment. * In the standalone case, this is the system classloader created to run launcher.jar. The classpath for this classloader includes the JVM classes, launcher.jar, and the contents of the manifest classpath in launcher.jar. * In the webapp case, the host classloader is the classloader supplied by the web container for the web application. Explicitly, this is the thread context classloader in place when the runtime is initialized, which by J2EE rules is the classloader used to load the webapp (including the contents of WEB-INF/classes and WEB-INF/lib/*). This classloader is to contain classes that we expect to be shared between the application and the runtime such as the SCA API and the Tuscany proprietary API (but not their implementations). === The SCA Assembly Model === To boot the Tuscany runtime we need the classes that implement it. This is done by creating a classloader that is a child of the host classloader and which contains the "boot" classes loaded from the "boot" directory. These are the embedded core classes such as -spi and -core. Next, we boot the system composite ("tuscany.system") as a composite under this classloader. As a composite, tuscany.system has its own classloader. In fact, all composites include their own classloader whose parent classloader is that of the parent composite. This allows us to support composites that contain additional Java resources (e.g. a composite packaged as a jar file). We also allow a composite to extend the classpath of its classloader through <dependency> elements in the composite's scdl. The extension deployers are components that are part of the "tuscany.system" composite that add additional children to it (the extensions). In this way, each component of the "tuscany.system" composite is implemented by a composite and as such contain another child classloader. === The Client and Implementation Model === On the application side, we deploy the "default" application as a composite on the application side of the component tree. As a composite it also has its own classloader, one whose classpath is that of the application. In the case of a webapp environment, the entire "default" application is contained within the host environment (e.g. the host classloader contains the JSPs, Servlets, etc that are part of the webapp). The default application composite's classloader is then a child of this webapp classloader and thus has a classpath that is all the application code and additionally includes any <dependency> specified in the composite scdl. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
