20 November 2008

Dependency Injection in Taglibs

Helping with some migration material recently for OC4J --> WLS, a question was asked about whether OC4J 10.1.3.x supported dependency injection with its Tag library implementation.

It's known that OC4J supports dependency injection in the Web container as described here, but the specifics of whether that extended to tag librarieswas not mentioned.

A subsequent quick test verified that dependency injection does indeed work for tags using the  SimpleTag (SimpleTagSupport) and BodyTag (BodyTagSupport).
package sab.testdi.tag;

import java.io.*;
import java.io.PrintWriter;
import javax.ejb.EJB;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
import sab.testdi.ejb.CalcLocal;

public class CalcAdd extends SimpleTagSupport {

CalcLocal calc;

int v1 = 0;
int v2 = 0;

public void setV1(int v1) {
this.v1 = v1;

public void setV2(int v2) {
this.v2 = v2;

public void doTag() throws JspException, IOException {
PrintWriter out = new PrintWriter(this.getJspContext().getOut());
out.printf("<div style='font-family: courier'>");
if(calc != null) {
out.printf("%s+%s=%s", v1, v2, calc.add(v1, v2));
} else {
out.printf("bugger, calc is null!");

The taglib.tld file defines the tag:
<?xml version = '1.0' encoding = 'windows-1252'?>
<taglib xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<description>A short description...</description>
<example><calc:add v1="100" v2="25"/></example>
And finally, a JSP can use it by importing the JAR file containing the tag libraru into the WEB-INF/lib directory (where it is nicely auto-discovered) and making a call to the <calc:add .../> tag.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
<%@ page contentType="text/html;charset=windows-1252"%>
<%@ taglib uri="/webapp/calc" prefix="calc"%>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"/>
<body style="font-family: arial">
<h2>Testing Taglib Dependency Injection</h2>
<calc:add v1="12" v2="12"/></p>

When the JSP is accessed it successfully displays 12+12=24 which is rendered by the tag library after being calculated via the injected EJB reference.

18 November 2008

Configuring shared-libraries settings post deployment

With the introduction of the shared-library mechanism in OC4J 10.1.3.x, it is possible to configure the set of libraries that an application has access to. This is done at the application level using the tag to include a named shared-library, or its counterpart, to remove a library from the view of the application.

These settings are made in the OC4J specific orion-application.xml deployment descriptor for the application, typically either as a hard-coded entry in the packaged EAR file that is being deployed, or they are set during the deployment process using the Class Loading Task in the ASC console.

In the current releases, there are no ways to easily change these settings once the application has been deployed. One approach that has been used is to perform a redeployment operation of the application and make the change via the ASC console. Obviously this requires a redeployment to be performed. While you can also manually edit the resulting orion-application.xml file to add/remove/change the settings, this provides no validation that the settings are correct.

To address this, for the next patch release of OC4J ( we are looking to add a couple of new shared-library commands to the admin_client.jar utility to operate on existing, deployed applications. These commands will allow you to perform add or delete operations on either of the or configuration elements.

As an example, lets say you have an application in which you wish to use the Apache Xerces parser instead of the Oracle XML parser. This change can be performed during deployment as described here: http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-swapxmlparser/doc/readme.html

But! When you test your application, it throws an Exception and you eventually realise that you forgot to make the change to the shared-libraries during the deployment of the application. The Oracle XML parser is still being used.

Using the new commands you would be able to change this on the deployed application as follows:

>java -jar admin_client.jar .... -addRemoveInheritedSharedLibrary -appName myapp -name oracle.xml

>java -jar admin_client.jar .... -addImportSharedLibrary -appName myapp -name apache.xml -minVersion 2.7 -maxVersion 2.7

17 November 2008

JEE5 web-app declaration

I seem to have trouble finding the correct definition of the web-app tag for JEE5/Servlet2.5 modules.

So for nothing more than a readily available memo to myself, here it is:
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

The schema is located here: http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd

XMLSchemas for WebLogic Server

The first set of XSD files for WebLogic Server have just been posted to the Oracle XSD hosting location: http://xmlns.oracle.com/weblogic.

The index page allows you to drill down into the version of WebLogic Server you are interested in, and ultimately locate the component specific XSD file.

For example, the JDBC Data Source XSD is located at: http://xmlns.oracle.com/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd

05 November 2008

Checking if FastSwap is enabled

In doing some work with the FastSwap feature of WebLogic Server recently, I wanted to be able to display whether FastSwap was enabled for the application.

I used the small hack below to determine whether FastSwap is enabled or not for the application. This examines the current ClassLoader that is being used and compares it with the FastSwap enabled ClassLoader.

private final String fastSwapLoader = "com.bea.wls.redef.RedefiningClassLoader";
private boolean isFastSwapEnabled() {
return Thread.currentThread().getContextClassLoader().getClass().getName().equals(fastSwapLoader);
If the classloader name changes in a future release, then of course this would break ... but it serves the purpose currently on WLS 10.3.

Another interesting area was to observe how the class name changed as the underlying class itself changed and FastSwap did its funky thing. I noticed that the second frame on the Thread stack contains the FastSwap modified classname. Grabbing that, you can keep track of the class name changes over time to display.

private String determineClassName() {
return Thread.currentThread().getStackTrace()[1].getClassName();

As the class changes over time, the names will look like the below:

  • sab.demo.fastswap.web.TestServlet_beaVersion0_1
  • sab.demo.fastswap.web.TestServlet_beaVersion1_11
  • sab.demo.fastswap.web.TestServlet_beaVersion2_12
  • ...

Starting WebLogic Server instance with local JMX access enabled

Needing to connect to a WLS instance with JConsole to view/use the MBeans?

Me too.

The simplest way I found to do it was to to add an entry to the setDomainEnv.cmd file for the specific managed instance:

set JAVA_OPTIONS=%JAVA_OPTIONS% -Dcom.sun.management.jmxremote

When you then run the managed instance, the setDomainEnv.cmd file is called and the additional property is added to the JVM when it is launched.

This is covering the case of starting the server instance from the command line -- if you are using Node Manager, then you'll need to set this in the configuration script that is used by the nodemanager.