Well, it has been busy...
A RedBook that includes a lot of this "Under The Hood" information is about to appear and an Enterprise Deployment Case Study RedPaper. I also presented this material at IBM Bedfont Lakes with the IBM WebSphere CTO in attendance (which was interesting...).
Currently, I am looking at what is necessary to produce a generic Linux deployment for a piece of Open Source comms code I am working on. I am beginning to think that source and autoconf is the only real option.
Saturday, 7 June 2008
Tuesday, 18 December 2007
Where have I been...
Well, I have neglected this blog for a while. I've been busy on some investigations into WAS 6.1 Internals that I hope to post on this site soon, but they are being published in IBM Systems Magazine. More publications are on their way, but enough of that for now.
One thing I have been doing is trying to create a means of testing a WAS7-like environment. Basically, take an AIX 5.3 environment and upgrade it to AIX 6.1 (adding support for WPARs). Then clone the WAS 6.1 directory structure, replacing the Java 5 JVM by a Java 6 JVM. This allows shared classes to use memory mapped files and to share across WPARs. Then upgrade Eclipse 3.1.2 in the WAS 6.1 plugins directory to Eclipse 3.3 - changing the configuration files and startup as you go. Finally, add the WAS EJB3 feature pack which is based on Apache OpenJPA. This is the starting point for what I believe WAS7 will look like. To do all this the platform specific properties and config files inside com.ibm.ws.runtime_6.1.0.jar have to edited and replaced to support the new command line, but after all it is just a big zip file so it isn't too hard. So far the Eclipse classloaders complain but I am getting closer.....
At work I am dealing with broken applications again.
One is from a lack of understanding from business architects and IT management as to the difference between the logical "ideal" world and the real world. If you have to go to the same system 14 times to get the data you need for a single screen from "logical services" then the latency caused by the infrastructure limitation of the "speed of light" is going to inhibit performance. Most technical people did point out that the real world has these limitations so wrapping services on the same platform to provide application specific services is often needed to achieve usable performance.
The next problem area are a couple of package vendors. The architecture from both is very legacy and still seems to emphasize the legacy rather than coming into the modern JavaEE based age. Poor vendor management and a lack of architecture vision and drive leads to the legacy spinning out of control and getting harder and harder to replace. So, these vendors are going to end up requiring multiple DBMS's to keep their product around as they are replacing the original legacy architectural components on a like-for-like piecemeal basis, rather than looking at the big picture and simplifying. I think this might be a subject for the next conference we host, i.e. "Replacing legacy - the good, the bad, and the ugly", The vendors should know they are in trouble - and so should the customers - when they can't even write an installation document for their own product...... Vendors I am working with will probably look at this and feel victimised, but sadly this description applies to two major products I am working with so there are two sets of vendors at the very least who should be ashamed and this is just the tip of the iceberg. Remember that the Titanic was sunk by an iceberg.
So, I finish my time for this year in the office tomorrow. I think we will refer to it as Rome. I had a public run in with Jupiter last week who likes to assure us all that there are no problems. Still, if we can't fix the problems in Rome where deafness reigns then we will try to fix them in the outside world where everyone benefits.
Be happy! I'll update soon with more details on the innards of WAS.
Well, enough for now.
One thing I have been doing is trying to create a means of testing a WAS7-like environment. Basically, take an AIX 5.3 environment and upgrade it to AIX 6.1 (adding support for WPARs). Then clone the WAS 6.1 directory structure, replacing the Java 5 JVM by a Java 6 JVM. This allows shared classes to use memory mapped files and to share across WPARs. Then upgrade Eclipse 3.1.2 in the WAS 6.1 plugins directory to Eclipse 3.3 - changing the configuration files and startup as you go. Finally, add the WAS EJB3 feature pack which is based on Apache OpenJPA. This is the starting point for what I believe WAS7 will look like. To do all this the platform specific properties and config files inside com.ibm.ws.runtime_6.1.0.jar have to edited and replaced to support the new command line, but after all it is just a big zip file so it isn't too hard. So far the Eclipse classloaders complain but I am getting closer.....
At work I am dealing with broken applications again.
One is from a lack of understanding from business architects and IT management as to the difference between the logical "ideal" world and the real world. If you have to go to the same system 14 times to get the data you need for a single screen from "logical services" then the latency caused by the infrastructure limitation of the "speed of light" is going to inhibit performance. Most technical people did point out that the real world has these limitations so wrapping services on the same platform to provide application specific services is often needed to achieve usable performance.
The next problem area are a couple of package vendors. The architecture from both is very legacy and still seems to emphasize the legacy rather than coming into the modern JavaEE based age. Poor vendor management and a lack of architecture vision and drive leads to the legacy spinning out of control and getting harder and harder to replace. So, these vendors are going to end up requiring multiple DBMS's to keep their product around as they are replacing the original legacy architectural components on a like-for-like piecemeal basis, rather than looking at the big picture and simplifying. I think this might be a subject for the next conference we host, i.e. "Replacing legacy - the good, the bad, and the ugly", The vendors should know they are in trouble - and so should the customers - when they can't even write an installation document for their own product...... Vendors I am working with will probably look at this and feel victimised, but sadly this description applies to two major products I am working with so there are two sets of vendors at the very least who should be ashamed and this is just the tip of the iceberg. Remember that the Titanic was sunk by an iceberg.
So, I finish my time for this year in the office tomorrow. I think we will refer to it as Rome. I had a public run in with Jupiter last week who likes to assure us all that there are no problems. Still, if we can't fix the problems in Rome where deafness reigns then we will try to fix them in the outside world where everyone benefits.
Be happy! I'll update soon with more details on the innards of WAS.
Well, enough for now.
Sunday, 27 May 2007
pSeries, AIX, WAS and the JVM
I've been swamped at work so have had little time for this blog, but have still spent some time digging into how WAS works.
Some articles on how the Java5 JVM works clarify some of my earlier findings. See
http://www.ibm.com/developerworks/java/library/j-ibmjava4/
and
http://www.ibm.com/developerworks/java/library/j-ibmjava1.html
I have used this information to investigate WAS and how it uses the com.ibm.cds_1.0.0.jar classloader from the Eclipse plugins to work with shared classes. I will publish some results here soon.
Note also that the Java6 JVMs are ow on their way from IBM:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/ibm/java6/index.shtml
In digging into how the JVM works I unjarred (jar xvf) core.jar and src.jar that come with the Java5 JVM shipped with WAS. Within core.jar there is a class called ProcessorCapacityNotification that it appears looks out for the changes in capacity that would be seen with dynamic LPAR'ing. The next challenge is to work out if it does this effectively, and then to find out if WAS responds to this information.
See you soon!
Colin
Some articles on how the Java5 JVM works clarify some of my earlier findings. See
http://www.ibm.com/developerworks/java/library/j-ibmjava4/
and
http://www.ibm.com/developerworks/java/library/j-ibmjava1.html
I have used this information to investigate WAS and how it uses the com.ibm.cds_1.0.0.jar classloader from the Eclipse plugins to work with shared classes. I will publish some results here soon.
Note also that the Java6 JVMs are ow on their way from IBM:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/ibm/java6/index.shtml
In digging into how the JVM works I unjarred (jar xvf) core.jar and src.jar that come with the Java5 JVM shipped with WAS. Within core.jar there is a class called ProcessorCapacityNotification that it appears looks out for the changes in capacity that would be seen with dynamic LPAR'ing. The next challenge is to work out if it does this effectively, and then to find out if WAS responds to this information.
See you soon!
Colin
Saturday, 19 May 2007
WAS Startup and Eclipse/OSGI
I couldn't update the blog last night because I was working late - a distinct lack of Java programmers in a building of 1200 people!
To really understand what goes on with the WAS internals and how Eclipse/OSGI fits in we have to examine the startup. So, lets look first at startServer.sh in /usr/IBM/WebSphere/AppServer. In here we will find references to com.ibm.wsspi.bootstrap.wsLauncher, which used to be wsBootstrap in earlier was implementations:
...
"$JAVA_HOME"/bin/java \
"$OSGI_INSTALL" "$OSGI_CFG" \
$X_ARGS \
$WAS_DEBUG \
$CONSOLE_ENCODING \
$D_ARGS \
-classpath "$WAS_CLASSPATH" \
$USER_INSTALL_PROP \
$JVM_EXTRA_CMD_ARGS \
com.ibm.ws.bootstrap.WSLauncher \
$SHELL "$CONFIG_ROOT" "$WAS_CELL" "$WAS_NODE" "$@" $WORKSPACE_ROOT_PROP
...
The $SHELL variable refers to the management tools, (JMX?) that we will look at one another day i.e.
# Bootstrap values ...
SHELL=com.ibm.ws.management.tools.WsServerLauncher
The other environment variables refer to the configuration for the given profiles, i.e. the XML files (server.xml, serverindex.xml, etc).
In the past the bootstrap class used to check for license information, setup platform specific configuration for iSeries and zOS, and then used to load the WAS runtime, but the key change now is the relationship with OSGI/Eclipse.
To explore further just jar the file that contains the plug for com.ibm.ws.bootstrap.WSLauncher, i.e. go to the plugins directory and open up com.ibm.ws.bootstrap_6.1.0.jar. Look at the structure created and open up plugin.xml.
created: META-INF/
extracted: META-INF/MANIFEST.MF
created: com/
created: com/ibm/
created: com/ibm/ws/
created: com/ibm/ws/bootstrap/
created: com/ibm/ws/extension/
created: com/ibm/ws/extension/thinregistry/
created: com/ibm/ws/runtime/
created: com/ibm/ws/runtime/service/
created: com/ibm/ws/runtime/service/impl/
created: com/ibm/wsspi/
created: com/ibm/wsspi/bootstrap/
created: com/ibm/wsspi/bootstrap/osgi/
created: com/ibm/wsspi/extension/
created: com/ibm/wsspi/runtime/
created: com/ibm/wsspi/runtime/service/
created: schema/
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway$1.class
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway$2.class
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway$3.class
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway.class
inflated: com/ibm/ws/bootstrap/ProtectionMetaData.class
inflated: com/ibm/ws/extension/ExtensionRegistryFactoryImpl.class
inflated: com/ibm/ws/extension/thinregistry/ConfigurationElement.class
inflated: com/ibm/ws/extension/thinregistry/ConfigurationProperty.class
inflated: com/ibm/ws/extension/thinregistry/Constants.class
inflated: com/ibm/ws/extension/thinregistry/Extension.class
inflated: com/ibm/ws/extension/thinregistry/ExtensionPoint.class
inflated: com/ibm/ws/extension/thinregistry/ExtensionRegistry.class
inflated: com/ibm/ws/extension/thinregistry/PluginDescriptor.class
inflated: com/ibm/ws/extension/thinregistry/PluginModelObject.class
inflated: com/ibm/ws/extension/thinregistry/PluginParser.class
inflated: com/ibm/ws/extension/thinregistry/RegistryLoader$1.class
inflated: com/ibm/ws/extension/thinregistry/RegistryLoader.class
inflated: com/ibm/ws/extension/thinregistry/RegistryResolver.class
inflated: com/ibm/ws/extension/thinregistry/ResourceHelper.class
inflated: com/ibm/ws/extension/thinregistry/Status.class
inflated: com/ibm/ws/runtime/service/impl/BundleContextMap.class
inflated: com/ibm/wsspi/bootstrap/InvocationHandler.class
inflated: com/ibm/wsspi/bootstrap/WSLauncher.class
inflated: com/ibm/wsspi/bootstrap/osgi/WsBundleActivator.class
inflated: com/ibm/wsspi/extension/ExtensionRegistryFactory$Implementation.class
inflated: com/ibm/wsspi/extension/ExtensionRegistryFactory.class
inflated: com/ibm/wsspi/runtime/service/WsServiceRegistry$1.class
inflated: com/ibm/wsspi/runtime/service/WsServiceRegistry$2.class
inflated: com/ibm/wsspi/runtime/service/WsServiceRegistry.class
inflated: plugin.xml
inflated: schema/applications.exsd
inflated: schema/invocationHandler.exsd
The directory structure shows classnames that relate to a lightweight Eclipse Extension Registry manager and an Eclipse OSGI application, particularly the WsBundleActivator that provides the OSGI start and stop methods as in Eclipse RCP applications, the Service registry for registering services as for OSGI, and the Extension, ExtensionPoint, ExtensionRegistry, and RegistryLoader classes. So, starting with plugin.xml:
...
<extension
id="WSLauncher"
point="org.eclipse.core.runtime.applications">
<application>
<run class="com.ibm.wsspi.bootstrap.WSLauncher"/>
</application>
</extension>
<extension-point id="applications" name="applications" schema="schema/applications.exsd"/>
<extension-point id="invocationHandlers" name="InvocationHandlers" schema="schema/invocationHandler.exsd"/>
<extension-point id="manual-bundle-start" name="Manual Bundle Starter"/>
<extension-point id="resource-file" name="Resource File"/>
...
Yes, WAS is basically like an RCP application in that extends org.eclipse.core.runtime.applications. The class that extends this is com.ibm.wsspi.bootstrap.osgi.WsBundleActivator, and like all "plugins"/RCP applications that extend this and implement the BundleActivator interface the class must provide start() and stop() methods that receive BundleContext objects to interoperate with the Eclipse/OSGI runtime. These methods in the world of OSGI are usually used to initiate the registration and running of services, which is where the WSServiceRegistry classes we unzipped above come in. Ahh, but we've jumped ahead..... This is how it works in the case of an Eclipse RCP or OSGI application as outlined in books like "Eclipse Rich Client Platform", but what loads the Eclipse/OSGI runtime and how do we get to the WsBundleActivator from WSLauncher? Well, the WSLauncher class has a main method, that does all of the argument and license checking functions of earlier releases of WAS, but then checks to see if it is running inside an Eclipse runtime, and if it isn't it creates its own thin, lightweight runtime and runs its extensions and plugins upon it. It then offers up its own extension points as seen in the plugin.xml file.
So, it seems to me that WAS is essentially similar to an Eclipse RCP/OSGI application, but if has both a full Eclipse 3.1.2 runtime and a lightweight one, and applications can use JNDI to provide further plugin services that extend the exposed extesnion points. This new implementaion allows IBM to easily extend WAS and to even support multiple versions. Its a nice architecture...
To get a better understanding read the following books:
The Java Developers Guide to Eclipse - D'Anjou et al
Eclipse Rich Client Platform - McAffer et al
Eclipse: Building Commercial Quality Plugins - Clayberg et al
Official Eclipse 3.0 FAQs - Barry etc al
They are all good books! However, play with code and write something with it. Just even using the wizards to create a simple osgi plugin is useful, as code can be put into the start() and stop() methods of your BundleActivator class and with a simple change to the config.ini and a start clause and you can have the WAS startup outlined above load your own code as an extension of WAS! This is really powerful and can be used to extend WAS even into the base OS!
Well, goodnight for now. I'll cover more soon in the next installment!
To really understand what goes on with the WAS internals and how Eclipse/OSGI fits in we have to examine the startup. So, lets look first at startServer.sh in /usr/IBM/WebSphere/AppServer. In here we will find references to com.ibm.wsspi.bootstrap.wsLauncher, which used to be wsBootstrap in earlier was implementations:
...
"$JAVA_HOME"/bin/java \
"$OSGI_INSTALL" "$OSGI_CFG" \
$X_ARGS \
$WAS_DEBUG \
$CONSOLE_ENCODING \
$D_ARGS \
-classpath "$WAS_CLASSPATH" \
$USER_INSTALL_PROP \
$JVM_EXTRA_CMD_ARGS \
com.ibm.ws.bootstrap.WSLauncher \
$SHELL "$CONFIG_ROOT" "$WAS_CELL" "$WAS_NODE" "$@" $WORKSPACE_ROOT_PROP
...
The $SHELL variable refers to the management tools, (JMX?) that we will look at one another day i.e.
# Bootstrap values ...
SHELL=com.ibm.ws.management.tools.WsServerLauncher
The other environment variables refer to the configuration for the given profiles, i.e. the XML files (server.xml, serverindex.xml, etc).
In the past the bootstrap class used to check for license information, setup platform specific configuration for iSeries and zOS, and then used to load the WAS runtime, but the key change now is the relationship with OSGI/Eclipse.
To explore further just jar the file that contains the plug for com.ibm.ws.bootstrap.WSLauncher, i.e. go to the plugins directory and open up com.ibm.ws.bootstrap_6.1.0.jar. Look at the structure created and open up plugin.xml.
created: META-INF/
extracted: META-INF/MANIFEST.MF
created: com/
created: com/ibm/
created: com/ibm/ws/
created: com/ibm/ws/bootstrap/
created: com/ibm/ws/extension/
created: com/ibm/ws/extension/thinregistry/
created: com/ibm/ws/runtime/
created: com/ibm/ws/runtime/service/
created: com/ibm/ws/runtime/service/impl/
created: com/ibm/wsspi/
created: com/ibm/wsspi/bootstrap/
created: com/ibm/wsspi/bootstrap/osgi/
created: com/ibm/wsspi/extension/
created: com/ibm/wsspi/runtime/
created: com/ibm/wsspi/runtime/service/
created: schema/
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway$1.class
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway$2.class
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway$3.class
inflated: com/ibm/ws/bootstrap/ClassLoaderGateway.class
inflated: com/ibm/ws/bootstrap/ProtectionMetaData.class
inflated: com/ibm/ws/extension/ExtensionRegistryFactoryImpl.class
inflated: com/ibm/ws/extension/thinregistry/ConfigurationElement.class
inflated: com/ibm/ws/extension/thinregistry/ConfigurationProperty.class
inflated: com/ibm/ws/extension/thinregistry/Constants.class
inflated: com/ibm/ws/extension/thinregistry/Extension.class
inflated: com/ibm/ws/extension/thinregistry/ExtensionPoint.class
inflated: com/ibm/ws/extension/thinregistry/ExtensionRegistry.class
inflated: com/ibm/ws/extension/thinregistry/PluginDescriptor.class
inflated: com/ibm/ws/extension/thinregistry/PluginModelObject.class
inflated: com/ibm/ws/extension/thinregistry/PluginParser.class
inflated: com/ibm/ws/extension/thinregistry/RegistryLoader$1.class
inflated: com/ibm/ws/extension/thinregistry/RegistryLoader.class
inflated: com/ibm/ws/extension/thinregistry/RegistryResolver.class
inflated: com/ibm/ws/extension/thinregistry/ResourceHelper.class
inflated: com/ibm/ws/extension/thinregistry/Status.class
inflated: com/ibm/ws/runtime/service/impl/BundleContextMap.class
inflated: com/ibm/wsspi/bootstrap/InvocationHandler.class
inflated: com/ibm/wsspi/bootstrap/WSLauncher.class
inflated: com/ibm/wsspi/bootstrap/osgi/WsBundleActivator.class
inflated: com/ibm/wsspi/extension/ExtensionRegistryFactory$Implementation.class
inflated: com/ibm/wsspi/extension/ExtensionRegistryFactory.class
inflated: com/ibm/wsspi/runtime/service/WsServiceRegistry$1.class
inflated: com/ibm/wsspi/runtime/service/WsServiceRegistry$2.class
inflated: com/ibm/wsspi/runtime/service/WsServiceRegistry.class
inflated: plugin.xml
inflated: schema/applications.exsd
inflated: schema/invocationHandler.exsd
The directory structure shows classnames that relate to a lightweight Eclipse Extension Registry manager and an Eclipse OSGI application, particularly the WsBundleActivator that provides the OSGI start and stop methods as in Eclipse RCP applications, the Service registry for registering services as for OSGI, and the Extension, ExtensionPoint, ExtensionRegistry, and RegistryLoader classes. So, starting with plugin.xml:
...
<extension
id="WSLauncher"
point="org.eclipse.core.runtime.applications">
<application>
<run class="com.ibm.wsspi.bootstrap.WSLauncher"/>
</application>
</extension>
<extension-point id="applications" name="applications" schema="schema/applications.exsd"/>
<extension-point id="invocationHandlers" name="InvocationHandlers" schema="schema/invocationHandler.exsd"/>
<extension-point id="manual-bundle-start" name="Manual Bundle Starter"/>
<extension-point id="resource-file" name="Resource File"/>
...
Yes, WAS is basically like an RCP application in that extends org.eclipse.core.runtime.applications. The class that extends this is com.ibm.wsspi.bootstrap.osgi.WsBundleActivator, and like all "plugins"/RCP applications that extend this and implement the BundleActivator interface the class must provide start() and stop() methods that receive BundleContext objects to interoperate with the Eclipse/OSGI runtime. These methods in the world of OSGI are usually used to initiate the registration and running of services, which is where the WSServiceRegistry classes we unzipped above come in. Ahh, but we've jumped ahead..... This is how it works in the case of an Eclipse RCP or OSGI application as outlined in books like "Eclipse Rich Client Platform", but what loads the Eclipse/OSGI runtime and how do we get to the WsBundleActivator from WSLauncher? Well, the WSLauncher class has a main method, that does all of the argument and license checking functions of earlier releases of WAS, but then checks to see if it is running inside an Eclipse runtime, and if it isn't it creates its own thin, lightweight runtime and runs its extensions and plugins upon it. It then offers up its own extension points as seen in the plugin.xml file.
So, it seems to me that WAS is essentially similar to an Eclipse RCP/OSGI application, but if has both a full Eclipse 3.1.2 runtime and a lightweight one, and applications can use JNDI to provide further plugin services that extend the exposed extesnion points. This new implementaion allows IBM to easily extend WAS and to even support multiple versions. Its a nice architecture...
To get a better understanding read the following books:
They are all good books! However, play with code and write something with it. Just even using the wizards to create a simple osgi plugin is useful, as code can be put into the start() and stop() methods of your BundleActivator class and with a simple change to the config.ini and a start clause and you can have the WAS startup outlined above load your own code as an extension of WAS! This is really powerful and can be used to extend WAS even into the base OS!
Well, goodnight for now. I'll cover more soon in the next installment!
Thursday, 17 May 2007
A bit more digging
For the next stage of our explanation take one of the plugins from the /usr/IBM/WebSphere/AppServer/plugins directory and jar xvf it to open it up. There is a lot of variation, but in most you will find a plugin.xml (or some variant), the use of the OSGI importing, exporting, etc mechanism in the META-INF/MANIFEST.MF, and in the plugin.xml you will see the use of Eclipse extensions and extension points. Take the webcontainer plugin for example. I don't want to show this due to various licensing issues, but this shows the use of extension points in com.ibm.wsspi.extension for
server-components
server-startup
applicationserver-startup
webcontainer-startup
mbean-provider
These are not extension point types that are normally seen in Eclipse, but define certain behaviours and their related components and classes as used within WAS.
These are not extension point types that are normally seen in Eclipse, but define certain behaviours and their related components and classes as used within WAS.
Wednesday, 16 May 2007
More on WAS
You can learn a lot about how things work by really delving into the documentation for WAS. How to use the Eclipse Extension support is all documented, i.e. use JNDI to get access to the EclipseRegistry.
However, looking at the XML, config and manifest files is also telling. There is also a reason why an OSGIConsole script is supplied with WAS now. If you jar xvf some of the plugins, like the main com.ibm.ws.runtime_6.1.0.jar you can learn a lot by looking at the MANIFEST.MF file that follows an Eclipse/OSGI pattern, i.e.
Bundle-Activator: com.ibm.ws.runtime.component.RuntimeBundleActivator
Bundle-Localization: plugin
Bundle-ManifestVersion: 2
Bundle-Name: WS_Server
Bundle-SymbolicName: com.ibm.ws.runtime; singleton:=true
Bundle-Vendor: IBM
Bundle-Version: 6.1.0
Eclipse-AutoStart: false
J2EE-DeploymentFactory-Implementation-Class: com.ibm.ws.management.app
lication.j2ee.deploy.spi.factories.DeploymentFactoryImpl
Manifest-Version: 1.0
Require-Bundle: com.ibm.ws.bootstrap; visibility:=reexport,
org.eclipse.jdt.core
DynamicImport-Package: com.ibm.etools.application,
com.ibm.etools.application.impl,
com.ibm.etools.application.util,
com.ibm.etools.client,
com.ibm.etools.client.impl,
com.ibm.etools.client.util,
...
Import-Package: com.ibm.ejs.models.base.bindings,
com.ibm.ejs.models.base.bindings.applicationbnd,
com.ibm.ejs.models.base.bindings.applicationbnd.impl,
com.ibm.ejs.models.base.bindings.applicationbnd.util,
com.ibm.ejs.models.base.bindings.clientbnd,
com.ibm.ejs.models.base.bindings.clientbnd.impl,
com.ibm.ejs.models.base.bindings.clientbnd.util,
...
org.eclipse.xsd.util,
org.osgi.framework,
org.osgi.service.condpermadmin,
org.osgi.service.packageadmin,
org.osgi.service.permissionadmin,
org.osgi.service.startlevel,
org.osgi.service.url,
org.osgi.util.tracker
Export-Package: com.ibm.CBUtils; x-internal:=true,
com.ibm.CORBA.services.redirector; x-internal:=true,
com.ibm.CORBA.services; x-internal:=true,
com.ibm.CSIv2Security; x-internal:=true,
...
Note that BundleActivator. Note also that the bootstrap is re-exported, most other underlying library services are also re-exported, and that the main underlying runtime is a singleton. I believe it works like this....
The Eclipse 3.1.2 runtime starts up and loads com.ibm.ws.runtime plugin after the updater has been loaded. This runtime provides the base services used by the rest of the app server, and is monolithic but well architected to provide true runtime services for use of the web container, ejb container, etc. Each of the rest of functional components and containers then sit on top of this runtime.
Containers such as the SIP container are true plugins that make use of the com.ibm.ws.runtime extension points and services. This container even has an OSGI Activator of its own that subclasses the WsBundleActivator.
All of this would make sense in allowing the feature packs and future extensions to be just added on top of the original code. This is really extensible.
Still, I will continue digging and add to this blog....
However, looking at the XML, config and manifest files is also telling. There is also a reason why an OSGIConsole script is supplied with WAS now. If you jar xvf some of the plugins, like the main com.ibm.ws.runtime_6.1.0.jar you can learn a lot by looking at the MANIFEST.MF file that follows an Eclipse/OSGI pattern, i.e.
Bundle-Activator: com.ibm.ws.runtime.component.RuntimeBundleActivator
Bundle-Localization: plugin
Bundle-ManifestVersion: 2
Bundle-Name: WS_Server
Bundle-SymbolicName: com.ibm.ws.runtime; singleton:=true
Bundle-Vendor: IBM
Bundle-Version: 6.1.0
Eclipse-AutoStart: false
J2EE-DeploymentFactory-Implementation-Class: com.ibm.ws.management.app
lication.j2ee.deploy.spi.factories.DeploymentFactoryImpl
Manifest-Version: 1.0
Require-Bundle: com.ibm.ws.bootstrap; visibility:=reexport,
org.eclipse.jdt.core
DynamicImport-Package: com.ibm.etools.application,
com.ibm.etools.application.impl,
com.ibm.etools.application.util,
com.ibm.etools.client,
com.ibm.etools.client.impl,
com.ibm.etools.client.util,
...
Import-Package: com.ibm.ejs.models.base.bindings,
com.ibm.ejs.models.base.bindings.applicationbnd,
com.ibm.ejs.models.base.bindings.applicationbnd.impl,
com.ibm.ejs.models.base.bindings.applicationbnd.util,
com.ibm.ejs.models.base.bindings.clientbnd,
com.ibm.ejs.models.base.bindings.clientbnd.impl,
com.ibm.ejs.models.base.bindings.clientbnd.util,
...
org.eclipse.xsd.util,
org.osgi.framework,
org.osgi.service.condpermadmin,
org.osgi.service.packageadmin,
org.osgi.service.permissionadmin,
org.osgi.service.startlevel,
org.osgi.service.url,
org.osgi.util.tracker
Export-Package: com.ibm.CBUtils; x-internal:=true,
com.ibm.CORBA.services.redirector; x-internal:=true,
com.ibm.CORBA.services; x-internal:=true,
com.ibm.CSIv2Security; x-internal:=true,
...
Note that BundleActivator. Note also that the bootstrap is re-exported, most other underlying library services are also re-exported, and that the main underlying runtime is a singleton. I believe it works like this....
The Eclipse 3.1.2 runtime starts up and loads com.ibm.ws.runtime plugin after the updater has been loaded. This runtime provides the base services used by the rest of the app server, and is monolithic but well architected to provide true runtime services for use of the web container, ejb container, etc. Each of the rest of functional components and containers then sit on top of this runtime.
Containers such as the SIP container are true plugins that make use of the com.ibm.ws.runtime extension points and services. This container even has an OSGI Activator of its own that subclasses the WsBundleActivator.
All of this would make sense in allowing the feature packs and future extensions to be just added on top of the original code. This is really extensible.
Still, I will continue digging and add to this blog....
Tuesday, 15 May 2007
Java and WebSphere Application Server on AIX Internals - Part 1
Well, as I need to keep my brain functioning, I am going to start outlining how Java and the WebSphere Application Server work on this blog. Over the next few days I will cover a few of the internals and things to loook out for.
Firstly, the JVM (J9) from IBM is a sophisticated and powerful JVM. The advanced heuristics in the Just In Time (JIT) compiler have been fairly well covered in the past elsewhere, but in outline the JVM compiles each class and keeps tabs on its usage. When it is compiled it weighs up the resource cost of compilation with optimisation against the cost of execution "as is", and if there is a benefit of optimising then optimisation is performed. As that class is used more and more there are greater benefits of optimisation so JIT compiler may recompiler and optimise the class in the background; replacing the native code implementation in the native code library when the recompile completes. As the code is executed more further iterations of the optimisation may be performed.
In addition to the optimisation, the JVM attempts to share native code across Java instances, using shared memory to communicate between the JVM process instances. A set of controls can be found in /tmp/javasharedresources. Note that the current implementation only shared native code implementions within an LPAR.
Secondly, one of the key differences between WAS 6.0 and WAS 6.1 was the adoption of the OSGI infrastructure and its object model. The Eclipse 3.1.2 implementatiion is used as the base, which is why much of the WAS functionality can be found in Eclipse plugins under the /usr/IBM/WebSphere/AppServer/plugins directory. Like other plugins the Eclipse runtime can preload the OSGI bundles/plugins under the control of the config.ini in the /configuration directory. A simple test of this is to create an OSGI bundle adhering to Eclipse 3.1 and put it in the plugins directory and add it with a "@4:start" entry to config.ini. Note that org.eclipse.core.runtime starts first and then the org.eclipse.update.configurator. Having this new plugin enumerate the plugins, extensions, and extension points it sees via the extension registry gives something like this:
Registry is: org.eclipse.core.internal.registry.ExtensionRegistry@5f075f07
ID: com.ibm.wsspi.extension.server-startup
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.configservice-metadata
-->Extension:com.ibm.ws.runtime.admin_jmx_configservice-metadata
-->Extension:com.ibm.events.client.cei_configservice-metadata
ID: com.ibm.wsspi.extension.webservices
-->Extension:com.ibm.ws.runtime.wsaddressing_impl-webservices
-->Extension:com.ibm.ws.runtime.dynacache-webservices
-->Extension:com.ibm.ws.runtime.pmi_rm-webservices
-->Extension:com.ibm.ws.runtime.security_wssecurity-webservices
-->Extension:com.ibm.ws.runtime.webservices-webservices
-->Extension:com.ibm.ws.runtime.i18n-webservices
-->Extension:com.ibm.ws.runtime.transaction_impl-webservices
-->Extension:null
ID: com.ibm.wsspi.extension.hamanager-startup
-->Extension:null
ID: org.eclipse.core.resources.builders
-->Extension:org.eclipse.jdt.core.javabuilder
ID: org.eclipse.core.runtime.products
-->Extension:org.eclipse.update.configurator.updateConfiguratorProductProvider
ID: com.ibm.wsspi.extension.extension-checker
ID: org.eclipse.team.core.projectSets
ID: org.eclipse.team.core.repository
ID: org.eclipse.core.resources.moveDeleteHook
-->Extension:org.eclipse.team.core.MoveDeleteHook
ID: com.ibm.wsspi.extension.channel-framework-channel-factory-type
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.rrd.rrd-emf-packages
-->Extension:null
ID: com.ibm.wsspi.extension.customBindingProvider
-->Extension:com.ibm.ws.runtime.wsaddressing-customBindingProvider
-->Extension:com.ibm.ws.runtime.transaction-customBindingProvider
-->Extension:com.ibm.ws.sib.server.wsnotification-customBindingProvider
ID: com.ibm.wsspi.extension.webcontainer-startup
-->Extension:null
-->Extension:null
ID: org.eclipse.core.variables.valueVariables
ID: com.ibm.wsspi.extension.taglibcacheconfig-xml
-->Extension:null
ID: com.ibm.wsspi.extension.server-recovery-mode-components
ID: org.eclipse.core.runtime.applications
-->Extension:com.ibm.ws.bootstrap.WSLauncher
-->Extension:com.ibm.ws.debug.osgi.StartConsole
-->Extension:com.ibm.ws.debug.osgi.Noop
-->Extension:com.ibm.ws.runtime.startWsServer
-->Extension:org.eclipse.ant.core.antRunner
ID: com.ibm.wsspi.extension.logger-properties
ID: com.ibm.ws.portletcontainer.portlet-document-filter-config
ID: com.ibm.wsspi.extension.server-components
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.resource-binders
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.app-depl-providers
-->Extension:com.ibm.ws.migration.Migration-app-depl-provider
-->Extension:com.ibm.ws.runtime.appprofile_impl-app-depl-providers
-->Extension:com.ibm.ws.runtime.security_impl-app-depl-providers
-->Extension:com.ibm.ws.runtime.prereq_amwas-app-depl-provider
-->Extension:com.ibm.ws.runtime.security_wssecurity-app-depl-providers
-->Extension:com.ibm.ws.runtime.webservices_app-depl-providers
-->Extension:null
-->Extension:null
-->Extension:com.ibm.ws.sip.container.WARToSARListener-app-depl-providers
-->Extension:com.ibm.ws.sip.container.SARToEARWrapperProvider-app-depl-providers
ID: com.ibm.ws.bootstrap.manual-bundle-start
-->Extension:null
ID: com.ibm.wsspi.extension.server-control-region-components
ID: com.ibm.wsspi.extension.server-model-init
-->Extension:com.ibm.ws.wccmbase.base_model_init
-->Extension:com.ibm.events.client.cei_model_init
-->Extension:com.ibm.ws.sib.wccm.sib_model_init
-->Extension:com.ibm.ws.sib.wccm.sib_resource_model_init
-->Extension:com.ibm.ws.sib.wccm.wsn_model_init
ID: org.eclipse.jdt.core.classpathContainerInitializer
-->Extension:null
ID: com.ibm.ws.bootstrap.applications
-->Extension:com.ibm.ws.migration.WASPreUpgrade
-->Extension:com.ibm.ws.migration.WASPostUpgrade
-->Extension:com.ibm.ws.migration.ConvertScriptCompatibility
-->Extension:com.ibm.ws.migration.ClientUpgrade
-->Extension:com.ibm.ws.runtime.RetrieveSigners
-->Extension:com.ibm.ws.runtime.WsAdmin
-->Extension:com.ibm.ws.runtime.CollectManagedObjectMetadata
-->Extension:com.ibm.ws.runtime.WsServerLauncher
-->Extension:com.ibm.ws.runtime.WsServer
-->Extension:com.ibm.ws.runtime.WsServerStop
-->Extension:com.ibm.ws.runtime.ServerStatus
-->Extension:com.ibm.ws.runtime.LaunchBatchCompiler
-->Extension:com.ibm.ws.runtime.LaunchWSAnt
-->Extension:com.ibm.ws.runtime.BackupConfigUtility
-->Extension:com.ibm.ws.runtime.RestoreConfigUtility
-->Extension:com.ibm.ws.runtime.FindEJBTimersCommand
-->Extension:com.ibm.ws.runtime.CancelEJBTimersCommand
-->Extension:com.ibm.ws.runtime.LaunchClient
-->Extension:com.ibm.ws.runtime.LaunchClientApi
-->Extension:com.ibm.ws.runtime.NodeFederationUtility
-->Extension:com.ibm.ws.runtime.NodeUninstallPrep
-->Extension:com.ibm.ws.runtime.NodeCleanupUtility
-->Extension:com.ibm.ws.runtime.NodeRemovalUtility
-->Extension:com.ibm.ws.runtime.NodeSyncUtility
-->Extension:com.ibm.ws.runtime.NodeRenameUtility
-->Extension:com.ibm.ws.runtime.DumpExtensionRegistry
-->Extension:com.ibm.ws.runtime.WsProfile
-->Extension:com.ibm.ws.runtime.WsProfileAdminListener
-->Extension:com.ibm.uddi.UDDIValueSet
ID: com.ibm.wsspi.rrd.generators
-->Extension:null
ID: org.eclipse.jdt.core.codeFormatter
ID: org.eclipse.jdt.core.classpathVariableInitializer
ID: org.eclipse.core.resources.teamHook
-->Extension:org.eclipse.team.core.TeamHook
ID: com.ibm.wsspi.extension.protectedclasses-policy
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.serializable
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.ws.portletcontainer.collaborator-config
-->Extension:null
ID: org.eclipse.team.core.fileTypes
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.cache-resourcemgr-config
-->Extension:null
ID: com.ibm.wsspi.extension.managed-object-metadata-collector
-->Extension:com.ibm.ws.runtime.admin_jmx_managed-object-metadata-collector
-->Extension:null
ID: org.eclipse.core.variables.dynamicVariables
ID: com.ibm.wsspi.extension.ejbcontainer-startup
-->Extension:null
ID: com.ibm.wsspi.extension.soap-request-monitor
-->Extension:com.ibm.ws.runtime.transaction_impl-soap-request-monitor
ID: com.ibm.wsspi.extension.server-config
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.pmiJmxMapperExtension
ID: org.eclipse.ant.core.antProperties
-->Extension:null
ID: com.ibm.wsspi.extension.channel-framework-channel-type
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.syswebservices
-->Extension:com.ibm.ws.runtime.wsaddressing_impl-syswebservices
-->Extension:com.ibm.ws.runtime.webservices-syswebservices
ID: org.eclipse.core.runtime.adapters
-->Extension:org.eclipse.core.resources.org.eclipse.core.resources.resourceMappingAdapters
ID: org.eclipse.team.core.ignore
ID: com.ibm.wsspi.extension.client-components
ID: com.ibm.wsspi.extension.service-provider
-->Extension:com.ibm.ws.runtime.webservices-service-provider
-->Extension:com.ibm.ws.sib.server.sib-service-provider
ID: com.ibm.ws.bootstrap.resource-file
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.scheduler-startup
-->Extension:null
ID: org.eclipse.core.resources.refreshProviders
ID: org.eclipse.ant.core.antTypes
ID: com.ibm.wsspi.extension.admin-command-def
-->Extension:com.ibm.ws.runtime.Runtime
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:com.ibm.ws.s
Note how much of the WAS internals in the core runtime (com.ibm.ws.runtime.....) and what sits upon it are now based on Eclipse plugins/OSGI bundles and extensions, services, and extension points.
Over the next few weeks I will add more to this.
Note that the platform.xml file in the org.eclipse.update directory under configuiration directory is updated each startup by the org.eclipse.update.configurator plugin and controls which WAS features are installed. This can be played with (at least will be when IBM have done more) to reduce the footprint of WAS. This is also likely to be used for the feature packs coming out now.
<?xml version="1.0" encoding="UTF-8"?>
<config date="1176138175560" transient="false" version="3.0">
<site enabled="true" policy="USER-EXCLUDE" updateable="true" url="platform:/base/">
<feature id="com.ibm.ws.uddi" url="features/com.ibm.ws.uddi_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.wsgateway" url="features/com.ibm.ws.wsgateway_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.base" url="features/com.ibm.ws.base_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.events.service" url="features/com.ibm.events.service_6.1.0.0/" version="6.1.0.0">
</feature>
<feature id="com.ibm.ws.express" url="features/com.ibm.ws.express_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.j2ee" url="features/com.ibm.ws.j2ee_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.taskmanagement" url="features/com.ibm.ws.taskmanagement_6.1.0.0/" version="6.1.0.0">
</feature>
<feature id="com.ibm.ws.nd" url="features/com.ibm.ws.nd_6.0.0.0/" version="6.0.0.0">
</feature>
</site>
</config>
</quote>
The OSGI infrastructure had some issues with the JVM shared native code across JVMs so some modifications have been included.
Other tools for poking around are the dumpExtensionRegistry.sh script which is run against a server config to get a picture of what is going on:
ADMU0116I: Tool information is being logged in file
/usr/IBM/WebSphere/AppServer/profiles/sandpit/logs/server1/ExtensionRegistry.log
ADMU0128I: Starting tool with the sandpit profile
ADMU0506I: Server name: server1
==============================================================================
Beginning of Extension Registry Dump
==============================================================================
Plug-in: com.ibm.ws.isc [1.0.0] (active)
Name: WS_Server
Provider: IBM
Location: file:/usr/IBM/WebSphere/AppServer/systemApps/isclite.ear/isclite.war/WEB-INF/plugin.xml
1 Extension(s);
Extension: ibmautogeneratedidentifier1 (active)
Target ExtensionPoint: com.ibm.ws.portletcontainer.collaborator-config
No Extension Points defined
Plug-in: com.ibm.ws.portletcontainer [2.0.0] (active)
Name: WS_Server
Provider: IBM
Location: jar:file:/usr/IBM/WebSphere/AppServer/lib/pc-appext.jar!/plugin.xml
No Extensions defined
2 Extension Point(s);
ExtensionPoint: collaborator-config (active)
Name: Portlet Container Collaborator Extension Point
Schema: null
1 Extension(s) attached;
com.ibm.ws.isc.ibmautogeneratedidentifier1 [1.0.0]
ExtensionPoint: portlet-document-filter-config (active)
Name: Portlet Document Filter Extension Point
Schema: null
No Extensions attached
Plug-in: com.ibm.wsspi.rrd [6.1.0] (active)
Name: WS_RemoteRequestDispatcher
Provider: IBM
Location: jar:file:/usr/IBM/WebSphere/AppServer/lib/rrd-appext.jar!/plugin.xml
No Extensions defined
4 Extension Point(s);
ExtensionPoint: generators (active)
Name: RemoteRequestDispatcher Extension Generator Extension Point
Schema: null
No Extensions attached
ExtensionPoint: handlers (active)
Name: RemoteRequestDispatcher Extension Handler Extension Point
Schema: null
No Extensions attached
ExtensionPoint: rrd-emf-packages (active)
Name: RRD EMF Package Initialization Extension Point
Schema: null
No Extensions attached
ExtensionPoint: rrd-extension-delegator (active)
Name: RemoteRequestDispatcher Extension Delegator Extension Point
Schema: null
No Extensions attached
Plug-in: org.eclipse.extensionregistry [1.0.0] (active)
Name: Extension Registry Core
Provider: IBM
Location: bundleresource://13/app-plugin.xml
No Extensions defined
2 Extension Point(s);
ExtensionPoint: RegistryFilter (active)
Name:
Schema: schema/RegistryFilter.exsd
No Extensions attached
ExtensionPoint: RegistryInstance (active)
Name:
Schema: schema/RegistryInstance.exsd
No Extensions attached
==============================================================================
End of Extension Registry Dump
==============================================================================
Interesting, isn't it?
As for all plugins, the MANIFEST.MF or plugin.xml files give information as to what extensions are in use and what the extension points are. For your own applications on top of WAS IBM recommend using JNDI to get access to the Extension Registry, so it is supported!
At some point I'll go through the different plugin configs in each of the runtime bundles/plugins, starting with the com.ibm.ws.runtime that underpins all of WAS.
Enjoy and I hope this helps!
Night, night!
Firstly, the JVM (J9) from IBM is a sophisticated and powerful JVM. The advanced heuristics in the Just In Time (JIT) compiler have been fairly well covered in the past elsewhere, but in outline the JVM compiles each class and keeps tabs on its usage. When it is compiled it weighs up the resource cost of compilation with optimisation against the cost of execution "as is", and if there is a benefit of optimising then optimisation is performed. As that class is used more and more there are greater benefits of optimisation so JIT compiler may recompiler and optimise the class in the background; replacing the native code implementation in the native code library when the recompile completes. As the code is executed more further iterations of the optimisation may be performed.
In addition to the optimisation, the JVM attempts to share native code across Java instances, using shared memory to communicate between the JVM process instances. A set of controls can be found in /tmp/javasharedresources. Note that the current implementation only shared native code implementions within an LPAR.
Secondly, one of the key differences between WAS 6.0 and WAS 6.1 was the adoption of the OSGI infrastructure and its object model. The Eclipse 3.1.2 implementatiion is used as the base, which is why much of the WAS functionality can be found in Eclipse plugins under the /usr/IBM/WebSphere/AppServer/plugins directory. Like other plugins the Eclipse runtime can preload the OSGI bundles/plugins under the control of the config.ini in the /configuration directory. A simple test of this is to create an OSGI bundle adhering to Eclipse 3.1 and put it in the plugins directory and add it with a "@4:start" entry to config.ini. Note that org.eclipse.core.runtime starts first and then the org.eclipse.update.configurator. Having this new plugin enumerate the plugins, extensions, and extension points it sees via the extension registry gives something like this:
Registry is: org.eclipse.core.internal.registry.ExtensionRegistry@5f075f07
ID: com.ibm.wsspi.extension.server-startup
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.configservice-metadata
-->Extension:com.ibm.ws.runtime.admin_jmx_configservice-metadata
-->Extension:com.ibm.events.client.cei_configservice-metadata
ID: com.ibm.wsspi.extension.webservices
-->Extension:com.ibm.ws.runtime.wsaddressing_impl-webservices
-->Extension:com.ibm.ws.runtime.dynacache-webservices
-->Extension:com.ibm.ws.runtime.pmi_rm-webservices
-->Extension:com.ibm.ws.runtime.security_wssecurity-webservices
-->Extension:com.ibm.ws.runtime.webservices-webservices
-->Extension:com.ibm.ws.runtime.i18n-webservices
-->Extension:com.ibm.ws.runtime.transaction_impl-webservices
-->Extension:null
ID: com.ibm.wsspi.extension.hamanager-startup
-->Extension:null
ID: org.eclipse.core.resources.builders
-->Extension:org.eclipse.jdt.core.javabuilder
ID: org.eclipse.core.runtime.products
-->Extension:org.eclipse.update.configurator.updateConfiguratorProductProvider
ID: com.ibm.wsspi.extension.extension-checker
ID: org.eclipse.team.core.projectSets
ID: org.eclipse.team.core.repository
ID: org.eclipse.core.resources.moveDeleteHook
-->Extension:org.eclipse.team.core.MoveDeleteHook
ID: com.ibm.wsspi.extension.channel-framework-channel-factory-type
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.rrd.rrd-emf-packages
-->Extension:null
ID: com.ibm.wsspi.extension.customBindingProvider
-->Extension:com.ibm.ws.runtime.wsaddressing-customBindingProvider
-->Extension:com.ibm.ws.runtime.transaction-customBindingProvider
-->Extension:com.ibm.ws.sib.server.wsnotification-customBindingProvider
ID: com.ibm.wsspi.extension.webcontainer-startup
-->Extension:null
-->Extension:null
ID: org.eclipse.core.variables.valueVariables
ID: com.ibm.wsspi.extension.taglibcacheconfig-xml
-->Extension:null
ID: com.ibm.wsspi.extension.server-recovery-mode-components
ID: org.eclipse.core.runtime.applications
-->Extension:com.ibm.ws.bootstrap.WSLauncher
-->Extension:com.ibm.ws.debug.osgi.StartConsole
-->Extension:com.ibm.ws.debug.osgi.Noop
-->Extension:com.ibm.ws.runtime.startWsServer
-->Extension:org.eclipse.ant.core.antRunner
ID: com.ibm.wsspi.extension.logger-properties
ID: com.ibm.ws.portletcontainer.portlet-document-filter-config
ID: com.ibm.wsspi.extension.server-components
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.resource-binders
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.app-depl-providers
-->Extension:com.ibm.ws.migration.Migration-app-depl-provider
-->Extension:com.ibm.ws.runtime.appprofile_impl-app-depl-providers
-->Extension:com.ibm.ws.runtime.security_impl-app-depl-providers
-->Extension:com.ibm.ws.runtime.prereq_amwas-app-depl-provider
-->Extension:com.ibm.ws.runtime.security_wssecurity-app-depl-providers
-->Extension:com.ibm.ws.runtime.webservices_app-depl-providers
-->Extension:null
-->Extension:null
-->Extension:com.ibm.ws.sip.container.WARToSARListener-app-depl-providers
-->Extension:com.ibm.ws.sip.container.SARToEARWrapperProvider-app-depl-providers
ID: com.ibm.ws.bootstrap.manual-bundle-start
-->Extension:null
ID: com.ibm.wsspi.extension.server-control-region-components
ID: com.ibm.wsspi.extension.server-model-init
-->Extension:com.ibm.ws.wccmbase.base_model_init
-->Extension:com.ibm.events.client.cei_model_init
-->Extension:com.ibm.ws.sib.wccm.sib_model_init
-->Extension:com.ibm.ws.sib.wccm.sib_resource_model_init
-->Extension:com.ibm.ws.sib.wccm.wsn_model_init
ID: org.eclipse.jdt.core.classpathContainerInitializer
-->Extension:null
ID: com.ibm.ws.bootstrap.applications
-->Extension:com.ibm.ws.migration.WASPreUpgrade
-->Extension:com.ibm.ws.migration.WASPostUpgrade
-->Extension:com.ibm.ws.migration.ConvertScriptCompatibility
-->Extension:com.ibm.ws.migration.ClientUpgrade
-->Extension:com.ibm.ws.runtime.RetrieveSigners
-->Extension:com.ibm.ws.runtime.WsAdmin
-->Extension:com.ibm.ws.runtime.CollectManagedObjectMetadata
-->Extension:com.ibm.ws.runtime.WsServerLauncher
-->Extension:com.ibm.ws.runtime.WsServer
-->Extension:com.ibm.ws.runtime.WsServerStop
-->Extension:com.ibm.ws.runtime.ServerStatus
-->Extension:com.ibm.ws.runtime.LaunchBatchCompiler
-->Extension:com.ibm.ws.runtime.LaunchWSAnt
-->Extension:com.ibm.ws.runtime.BackupConfigUtility
-->Extension:com.ibm.ws.runtime.RestoreConfigUtility
-->Extension:com.ibm.ws.runtime.FindEJBTimersCommand
-->Extension:com.ibm.ws.runtime.CancelEJBTimersCommand
-->Extension:com.ibm.ws.runtime.LaunchClient
-->Extension:com.ibm.ws.runtime.LaunchClientApi
-->Extension:com.ibm.ws.runtime.NodeFederationUtility
-->Extension:com.ibm.ws.runtime.NodeUninstallPrep
-->Extension:com.ibm.ws.runtime.NodeCleanupUtility
-->Extension:com.ibm.ws.runtime.NodeRemovalUtility
-->Extension:com.ibm.ws.runtime.NodeSyncUtility
-->Extension:com.ibm.ws.runtime.NodeRenameUtility
-->Extension:com.ibm.ws.runtime.DumpExtensionRegistry
-->Extension:com.ibm.ws.runtime.WsProfile
-->Extension:com.ibm.ws.runtime.WsProfileAdminListener
-->Extension:com.ibm.uddi.UDDIValueSet
ID: com.ibm.wsspi.rrd.generators
-->Extension:null
ID: org.eclipse.jdt.core.codeFormatter
ID: org.eclipse.jdt.core.classpathVariableInitializer
ID: org.eclipse.core.resources.teamHook
-->Extension:org.eclipse.team.core.TeamHook
ID: com.ibm.wsspi.extension.protectedclasses-policy
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.serializable
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.ws.portletcontainer.collaborator-config
-->Extension:null
ID: org.eclipse.team.core.fileTypes
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.cache-resourcemgr-config
-->Extension:null
ID: com.ibm.wsspi.extension.managed-object-metadata-collector
-->Extension:com.ibm.ws.runtime.admin_jmx_managed-object-metadata-collector
-->Extension:null
ID: org.eclipse.core.variables.dynamicVariables
ID: com.ibm.wsspi.extension.ejbcontainer-startup
-->Extension:null
ID: com.ibm.wsspi.extension.soap-request-monitor
-->Extension:com.ibm.ws.runtime.transaction_impl-soap-request-monitor
ID: com.ibm.wsspi.extension.server-config
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.pmiJmxMapperExtension
ID: org.eclipse.ant.core.antProperties
-->Extension:null
ID: com.ibm.wsspi.extension.channel-framework-channel-type
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.syswebservices
-->Extension:com.ibm.ws.runtime.wsaddressing_impl-syswebservices
-->Extension:com.ibm.ws.runtime.webservices-syswebservices
ID: org.eclipse.core.runtime.adapters
-->Extension:org.eclipse.core.resources.org.eclipse.core.resources.resourceMappingAdapters
ID: org.eclipse.team.core.ignore
ID: com.ibm.wsspi.extension.client-components
ID: com.ibm.wsspi.extension.service-provider
-->Extension:com.ibm.ws.runtime.webservices-service-provider
-->Extension:com.ibm.ws.sib.server.sib-service-provider
ID: com.ibm.ws.bootstrap.resource-file
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:null
ID: com.ibm.wsspi.extension.scheduler-startup
-->Extension:null
ID: org.eclipse.core.resources.refreshProviders
ID: org.eclipse.ant.core.antTypes
ID: com.ibm.wsspi.extension.admin-command-def
-->Extension:com.ibm.ws.runtime.Runtime
-->Extension:null
-->Extension:null
-->Extension:null
-->Extension:com.ibm.ws.s
Note how much of the WAS internals in the core runtime (com.ibm.ws.runtime.....) and what sits upon it are now based on Eclipse plugins/OSGI bundles and extensions, services, and extension points.
Over the next few weeks I will add more to this.
Note that the platform.xml file in the org.eclipse.update directory under configuiration directory is updated each startup by the org.eclipse.update.configurator plugin and controls which WAS features are installed. This can be played with (at least will be when IBM have done more) to reduce the footprint of WAS. This is also likely to be used for the feature packs coming out now.
<?xml version="1.0" encoding="UTF-8"?>
<config date="1176138175560" transient="false" version="3.0">
<site enabled="true" policy="USER-EXCLUDE" updateable="true" url="platform:/base/">
<feature id="com.ibm.ws.uddi" url="features/com.ibm.ws.uddi_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.wsgateway" url="features/com.ibm.ws.wsgateway_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.base" url="features/com.ibm.ws.base_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.events.service" url="features/com.ibm.events.service_6.1.0.0/" version="6.1.0.0">
</feature>
<feature id="com.ibm.ws.express" url="features/com.ibm.ws.express_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.j2ee" url="features/com.ibm.ws.j2ee_6.0.0.0/" version="6.0.0.0">
</feature>
<feature id="com.ibm.ws.taskmanagement" url="features/com.ibm.ws.taskmanagement_6.1.0.0/" version="6.1.0.0">
</feature>
<feature id="com.ibm.ws.nd" url="features/com.ibm.ws.nd_6.0.0.0/" version="6.0.0.0">
</feature>
</site>
</config>
</quote>
The OSGI infrastructure had some issues with the JVM shared native code across JVMs so some modifications have been included.
Other tools for poking around are the dumpExtensionRegistry.sh script which is run against a server config to get a picture of what is going on:
ADMU0116I: Tool information is being logged in file
/usr/IBM/WebSphere/AppServer/profiles/sandpit/logs/server1/ExtensionRegistry.log
ADMU0128I: Starting tool with the sandpit profile
ADMU0506I: Server name: server1
==============================================================================
Beginning of Extension Registry Dump
==============================================================================
Plug-in: com.ibm.ws.isc [1.0.0] (active)
Name: WS_Server
Provider: IBM
Location: file:/usr/IBM/WebSphere/AppServer/systemApps/isclite.ear/isclite.war/WEB-INF/plugin.xml
1 Extension(s);
Extension: ibmautogeneratedidentifier1 (active)
Target ExtensionPoint: com.ibm.ws.portletcontainer.collaborator-config
No Extension Points defined
Plug-in: com.ibm.ws.portletcontainer [2.0.0] (active)
Name: WS_Server
Provider: IBM
Location: jar:file:/usr/IBM/WebSphere/AppServer/lib/pc-appext.jar!/plugin.xml
No Extensions defined
2 Extension Point(s);
ExtensionPoint: collaborator-config (active)
Name: Portlet Container Collaborator Extension Point
Schema: null
1 Extension(s) attached;
com.ibm.ws.isc.ibmautogeneratedidentifier1 [1.0.0]
ExtensionPoint: portlet-document-filter-config (active)
Name: Portlet Document Filter Extension Point
Schema: null
No Extensions attached
Plug-in: com.ibm.wsspi.rrd [6.1.0] (active)
Name: WS_RemoteRequestDispatcher
Provider: IBM
Location: jar:file:/usr/IBM/WebSphere/AppServer/lib/rrd-appext.jar!/plugin.xml
No Extensions defined
4 Extension Point(s);
ExtensionPoint: generators (active)
Name: RemoteRequestDispatcher Extension Generator Extension Point
Schema: null
No Extensions attached
ExtensionPoint: handlers (active)
Name: RemoteRequestDispatcher Extension Handler Extension Point
Schema: null
No Extensions attached
ExtensionPoint: rrd-emf-packages (active)
Name: RRD EMF Package Initialization Extension Point
Schema: null
No Extensions attached
ExtensionPoint: rrd-extension-delegator (active)
Name: RemoteRequestDispatcher Extension Delegator Extension Point
Schema: null
No Extensions attached
Plug-in: org.eclipse.extensionregistry [1.0.0] (active)
Name: Extension Registry Core
Provider: IBM
Location: bundleresource://13/app-plugin.xml
No Extensions defined
2 Extension Point(s);
ExtensionPoint: RegistryFilter (active)
Name:
Schema: schema/RegistryFilter.exsd
No Extensions attached
ExtensionPoint: RegistryInstance (active)
Name:
Schema: schema/RegistryInstance.exsd
No Extensions attached
==============================================================================
End of Extension Registry Dump
==============================================================================
Interesting, isn't it?
As for all plugins, the MANIFEST.MF or plugin.xml files give information as to what extensions are in use and what the extension points are. For your own applications on top of WAS IBM recommend using JNDI to get access to the Extension Registry, so it is supported!
At some point I'll go through the different plugin configs in each of the runtime bundles/plugins, starting with the com.ibm.ws.runtime that underpins all of WAS.
Enjoy and I hope this helps!
Night, night!
Subscribe to:
Posts (Atom)
