The top part is Java Class loader, which is Java class loader. WebSphere loads just enough to get itself bootstrapped and initialize WebSphere extension class loader.
The WebSphere extensions class loader is where WebSphere itself is loaded. In previous versions of WebSphere, the run time was loaded by this single class loader. However, beginning with WebSphere Application Server V6.1, WebSphere is now packaged as a set of OSGi bundles. Each OSGi bundle is loaded separately by its own class loader. This network of OSGi class loaders is then connected to the extensions class loader and the rest of the class loader hierarchy through an OSGi gateway class loader
In previous versions of WebSphere Application Server the WebSphere run time classes files were stored in the classes, lib, lib\ext, and installedChannels directories in the <was_home> directory. Because of the OSGi packaging, these directories no longer exist and the run time classes are now stored in the <was_home>\plugins directory.
Despite this architectural change in the internals of how WebSphere loads its own classes, there is no behavioral change as far as your applications are concerned. They still have the same visibility, and the same class loading options still exist for your application.
On the other hand, if you have developed Java applications that rely on the WebSphere JAR files that were previously in the <was_home>\lib directory, you will need to modify your application to retain compatibility. WebSphere Application Server V6.1 provides two thin client libraries designed specifically for such applications: one administrative client library and one Web services client library. These thin client libraries can be found in the <was_home>\runtimes directory:
- com.ibm.ws.admin.client_6.1.0.jar
- com.ibm.ws.webservices.thinclient_6.1.0.jar
These libraries provide everything your application might need for connecting to and working with WebSphere
The class path used by the extensions class loader is retrieved from the ws.ext.dirs system property, which is initially derived from the WAS_EXT_DIRS environment variable set in the setupCmdLine script file.
3 comments:
Plagiarize much? IBM might not like you copying verbatim out of their redbook: http://www.redbooks.ibm.com/redpapers/pdfs/redp4581.pdf
Sunil the copier.
Nice commentvertizement, loser company Prologic Corp... oh, and also what Anonymouses said above... not original content - plagiarized.
Post a Comment