31 August 2005

Classloader query framework

With the introduction of the new classloading framework, an advanced diagnostic capability has been added to allow runtime queries to be performed against the current classloader state.

A number of prebuilt-queries are provided.

The query framework can be accessed in two ways.

Command Line Access

From the command line using System properties to specify the query to execute and any parameters to pass to the query.

Try this to see the list of available queries:

>java -Doc4j.start.query=ListQueries+Exit -jar oc4j.jar

To see the current state of the classloader tree for the default application, try this:

>java -Doc4j.start.query=LoaderTree(default.root)+Exit -jar oc4j.jar

+- ascontrol.root:0.0.0
+- test-tl-import.root:0.0.0
| |
| +- test-tl-import.web.web-app-log4j:0.0.0
| |
| +- test-tl-import.web.web-app-log4j.jsp151:0.0.0
+- default.web.defaultWebApp:0.0.0
| +- default.web.defaultWebApp.jsp2152:0.0.0
+- default.web.jmsrouter_web:0.0.0

+- default.web.jmsrouter_web.jsp187:0.0.0

Application Server Control Classloading MBean

Classloading queries can be executed via the Classloading MBean accessible from the System MBean browser available in Application Server Control.

Access the MBean:

Fire up ASC and access the System MBean Browser from the Administration tab.

The ClassLoading > Singleton MBean has an operation called executeQuery.

There are two executeQuery operations. The operation with 2 parameters can be used from this browser MBean client.

Click executeQuery (2) access the invoke operation page.

Invoking the executeQuery operation:

The executeQuery operation page shows the parameters the MBean operation takes.

The first parameter is the fully qualified classname of the query to execute.

All queries are packaged within the oracle.oc4.query package. The actual classname is the name of the query shown with the help page.

The second parameter allows the entry of parameters to be supplied to the query.

To see the state of the current classloader tree for the Default application, and all of it's children use the following parameters

queryClassName: oracle.oc4j.query.LoaderTree
queryArguments: default.root

You can see the list of queries, with a description of each by executing a query using the following parameters.

queryClassName: oracle.oc4j.query.ListQueries

30 August 2005

Classloading in OC4J 10.1.3

Updated 13-Nov-2006:

1. Link to official classloading documentation for
2. Linked to classloading related how-to examples
The classloading implementation in OC4J 10g (10.1.3.x) has been entirely reworked. One of the general goals of the project was to cleanly separate the classloaders used by the OC4J runtime from the classloaders used by applications -- to ultimately provide applications with the freedom to use whatever libraries they require without effecting the overall OC4J runtime.

As part of the new framework, a number of new concepts have been introduced:

1. A new entity called a shared-libary has been added, which enables a set of libraries to be explicitly named and versioned. A named/versioned shared-library can subsequently be made available (imported) to a classloader (an created for an application) so the libraries can be accessed by the application.

2. All the new classloader implementation classes are capable of outputting detailed diagnostic information when classloading errors occur. The diagnostic included detailed such as the names of any missing classes which are attempted to be loaded, where the call was made from and the name/version of any shared-libraries in which the missing class is available.

3. A query mechanism which can be used to extract and display information from the classloaders that are in use. This for example allows the classloader tree to be displayed for a specific application, showing the path from which classes are loaded. The classloader tree also lists all of the code-sources associated with each loader.

A lot of the new classloading framework is documented in the OC4J 10g (10.1.3) Developer's Guide on OTN.

System status using opmnctl

An OracleAS installation contains the Oracle Process Management and Notification (OPMN) server. This server performns a specific task within an OracleAS environment -- it manages (starts/stops) and keeps watch on the processes that are part of OracleAS, performing remediary restart action required when a process experiences a failure.

The OPMN command line utility -- opmnctl -- has a flag which enables various actions to be performed. It also allows the status of the current system to be viewed.

Basic Status

The basic system status (up/down for each managed process) can be obtained using the simple command below.

$>opmnctl status

Processes in Instance: 050825_j2ee_red.duraace.au.oracle.com
ias-component | process-type | pid | status
OC4J | home | 3276 | Alive

Extended Status

A more extended status can be obtained using the "-l" command.

$>opmnctl status -l

Processes in Instance: 050825_j2ee_red.duraace.au.oracle.com
ias-component | process-type | pid | status | uid | mem used | uptime | ports
OC4J | home | 3324 | Alive | 1888158126 | 49152 | 0:00:31 | jms:12601,default-web-site:8888,rmi:12401

Cluster Status

$>opmnctl @cluster status
$>opmnctl @cluster status -l

Processes in Instance: 050825_j2ee_red.duraace.au.oracle.com
ias-component | process-type | pid | status
OC4J | home | 3324 | Alive

Processes in Instance: 050825_j2ee_blue.duraace.au.oracle.com
ias-component | process-type | pid | status
OC4J | home | N/A | Down

Processes in Instance: 050825_http.duraace.au.oracle.com
ias-component | process-type | pid | status
HTTP_Server | HTTP_Server | 2140 | Alive

25 August 2005

The dynamic duo - mod_oc4j and OC4J

With the DP4 release, the mod_oc4j module in Oracle HTTP Server now uses a dynamic mapping approach to expose OC4J web applications.

In previous releases, each OC4J context-root that was to be exposed by OHS required a static entry to be made in the $ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file.

Oc4jMount /path ajp13://duraace.au.oracle.com

With the new dynamic model in 10.1.3 , OC4J broadcasts the list of context-root mappings it has to OHS which enables OHS to expose them as they are received.

As OC4Js instances start and stop, or as applications are deployed/undeployed, the mount points are added or removed from OHS with no user intervention required.

This reduces the amount of configuration steps required to deploy applications, and makes the architecure more agile as the mapping changes are done on the fly and don't require the OHS process to be bounced.

You can still use static mount points if you wish, or a combination of both.

The routing mode can specified within the mod_oc4j.conf file. It can specify whether to use only dynamic routing, only the older style static style routing or to do both and default to either dynamic or static in the case of conflicts. By default Dynamic is used.

Oc4jRoutingMode Dynamic (which is the implicit default value)


Oc4jRoutingMode StaticOverride (allows any static bindings to take precedence)

Its possible to configure OHS so that it will display in a HTML page what its current list of mount points are when operating in dynamic mode.

To do this, open up the $ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file and add the following bold text between the tags.

<IfModule mod_oc4j.c>
Oc4jSet StatusUri /oc4j-status
</IfModule mod_oc4j.c>

Restart OHS and then access the page using http://host:port/oc4j-status

The resulting page will list all of the mount points OHS currently has from the OC4J instances it is collaborating with.

mod_oc4j Global Configuration

hostname : duraace.au.oracle.com
local instance : 050823_http.duraace.au.oracle.com
select method : Round-Robin
select affinity : None
routing mode : Dynamic
routing ID : g_rt_id

OC4J Dynamic Routing

application : ascontrol
context : /em
process (Jgroup): 0

application : default
context : /jmsrouter, /j2ee
process (Jgroup): 0, 1

OC4J Process List

0 : duraace, 8888, ALIVE
1 : duraace, 8889, ALIVE

Admin user changes in OC4J DP4

Here are another couple of changes to be aware of with the OC4J 10g (10.1.3) Developer Preview release on OTN.

The default administrator username is now oc4jadmin.  In previous releases this was admin.  

The first time initialization routine that OC4J uses has changed so that on the very first startup of OC4J, you will be prompted to specify the password for the oc4jadmin user.  

We no longer ship the product with a password preset for the administrator of the product.  This password setting is only done on the very first startup of OC4J.

In previous releases you could just unzip the oc4j_extended.zip file and run OC4J as we supplied a default password for the admin user of welcome.  

To now change the password that has been set for the oc4jadmin user, you now need to use the j2ee/home/jazn.jar utility.

In previous releases, to change the password for the admin user, you would specify the –install option when starting OC4J, which would prompt you to enter a new password for the admin user.  The –install functionality has been removed from the product.

24 August 2005

Using OracleAS 10.1.3 DP4

There are a couple of changes with the DP4 release which may catch you out .... unless you read the release notes that go along with it of course.

  • The Application Server Control (ASC) console is now mapped to the default-website with a context-root of "/em".

    In the previous DP3 release, ASC was mapped to a separate website and used a context-root of "/asc".

  • We've made the configurations more consistent between the standalone OC4J and the OracleAS OC4J. The most obvious change is that standalone OC4J now uses the "default-web-site.xml" file as its default website.

    Previous releases of standalone have used a different file -- http-web-site.xml.

  • If you download and use the installable version of Oracle Application Server, and perform the "J2EE Server" installation type, you will ultimately get an OPMN managed OC4J instance. This OC4J instance is configured out of the box to run its request listener using HTTP -- so it can be used immediately and without requiring an OHS instance to sit in front of it (although we recommend that and it can be done very easily).

    The gotcha here is that the default URL to access this instance will be


    Note that the port in use here is allocated at install time. It will be "8888" unless the installer detects that it in use, whereupon it will search for another free port to use instead. The end of install text will show you the port that was used.

  • To see all the active ports in use, you can use the opmnctl utility

    $ORACLE_HOME/opmn/bin/opmnctl status –l

    Processes in Instance: test_j2ee


    ias-component| process-type| status|ports

    OC4J | home | Alive |http:8888,jms:12601,rmi:12401

Wiring OHS and OC4J together

With the recent Oracle Application Server 10g (10.1.3) Developer Preview 4 (what a mouthful!) release we put on OTN, it's possible to perform installations which lay down just Oracle HTTP Server or just Oracle Containers for J2EE (OC4J). This provides a finer grained install model than in previous releases, allowing boxes to be dedicated to servicing HTTP requests, and other boxes to be dedicated to hosting J2EE applications and services.

Once you have these two separate installations done, the question is -- how do you wire them together so that the OHS instance can route requests for J2EE applications to the OC4J instance which is hosting them?

Configuration Steps:

Well it's pretty simple really, here's the quick and dirty commands to do it.

OHS Server (or installation if on same box)

Within the OHS server installation directory, execute the following command:

>cd $ORACLE_HOME/opmn/bin
>opmnctl config topology update discover="*"

OC4J Server** (or installation directory if on same box)

Within the OC4J server installation directory, execute the following commands:

>cd $ORACLE_HOME/opmn/bin
>opmnctl config topology update discover="*"
>opmnctl config port update ias-component=OC4J process-type=home portid=default-web-site protocol="AJP"

** do this for each OC4J installation you want to include within this shared group of instances. The single OHS instance can front end multiple OC4J installations.

Brief Explanation:

So what do these commands do?

>opmnctl config topology update discover="*"

What this command will do is to configure the OPMN infrastructure with a common discovery address, enabling the separate installations to discover and communicate with one another. You will note that we execute the exact same command within both installations, with the exact same address. If the address is different, then the two installations will not be able to discover each other.

>opmnctl config port update ias-component=OC4J process-type=home portid=default-web-site protocol="AJP"

On the OC4J installation, this additional command is performed. What this does it to switch the protocol the OC4J instance is using to listen from requests to the AJP protocol, which is used by mod_oc4j to dispatch requests to an OC4J instance. The out of the box OC4J installation will be configured to use the HTTP protocol, enabling it to be accessed and used directly from a browser.

Whenever you want OHS to sit in front of the OC4J instance, you just need to switch the protocol.

Any of the apps which you've deployed and bound to a context-root within your OC4J instance will then be accessible via the OHS URL.

Arrived on blogspot

Trying to revive my old blog out of its deep coma, I discovered that my registration with radio.weblogs had expired and needed renewing.

I hate filing expense reports at the best of times, so after a bit of a hunt around, I established a new home at buttso.blogspot.com.

The old blog postings are still active at http://radio.weblogs.com/0132383 but this site is where any new thoughts will be posted. Beware :-)