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

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!

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.

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

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!

The start of another week in the office

Well, it was the start of another difficult working week. We have over a thousand people in our building but the actual "doers" (Java coders, etc) number in their handfuls. Every project is delayed due to lack of resources. Go figure!

I am continuing with my actual sentient existence outside of work, and I am continuing to try to understand the use of Eclipse 3.1.2 / OSGI to underpin the WebSphere Application Server 6.1 infrastructure. I was asked to write an Atom/RSS Reader so I have done this as an Eclipse RCP application that uses a ROME plugin. The ROME plugin can also be used with WAS to publish RSS and Atom feeds.

Well, I have to prepare myself for another day in the office tomorrow. Almost every day I feel sick before going in. I acted under orders last year and am suffering for it this year. C'est la vie. I guess it is time to move on to another company...

Another day...

Well, this is my first blog entry on this site, rather than on my own machines. Today it's what most people would call a "Church" day.....