Saturday 7 June 2008

What has been happening....

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.

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.

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

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!

    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.

    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....

    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!