a cup of java

This is about another exception you may get while playing around with JBoss, Transactions, Remote EJBs etc. And the exception is:

org.jboss.resource.JBossResourceException:
Could not enlist in transaction on entering meta-aware object!

My friend Venu had a post in his blog on why this exception happens and how to fix it in JBoss 5.0. You can read it here. But if we are using JBoss 5.1.0 this solution cannot help us. Because there are a couple of changes in the configuration in this new version of JBoss. In fact if you can take a look at the JBoss 5.1.0 GA release notes we can see a lot of changes in configuration especially if we are migrating from JBoss 5.0 to 5.1.

And here is the solution.

Open the JBOSS_HOME/server/JBOSS_CONFIGURATION/conf/jbossts-properties.xml. Set the following.

<!-- Support subtransactions in the JTA layer? Default is NO. -->
<property name="com.arjuna.ats.jta.supportSubtransactions" value="YES"/>

Hope this helps.

P.S. If you have any more details in this issue, please feel free to share it. Thank you.

This is again a small JMS configuration stuff we have to do in JBoss 5. There is considerable difference in doing it in JBoss 5 compared to JBoss 4 and don’t expect our old configuration to work well with JBoss 5 without any change. In JBoss 5 they are using JBoss Messaging in place of JBoss MQ. You can read a detailed post on migrating from JBoss 4 to JBoss 5 here.

This post is about the configuration of a simple queue. We can configure topics also like this. In JBoss 5, the configuration file is in messaging directory with in the deploy directory.

In JBoss 4.x the JMS configuration (in jms/jbossmq-destinations-service.xml) is like this:

<mbean code="org.jboss.mq.server.jmx.Queue"
 name="jboss.mq.destination:service=Queue,name=MyQueue">
 <attribute name="JNDIName">queue/MyQueue</attribute>
 <attribute name="RedeliveryDelay">10000</attribute>
 <attribute name="RedeliveryLimit">3</attribute>
 <depends optional-attribute-name="DestinationManager">
    jboss.mq:service=DestinationManager
 </depends>
</mbean>

In JBoss 5.x we should do this (in messaging/destinations-service.xml):

<mbean code="org.jboss.jms.server.destination.QueueService"
 name="jboss.messaging.destination:service=Queue,name=MyQueue"
 xmbean-dd="xmdesc/Queue-xmbean.xml">
 <depends optional-attribute-name="ServerPeer">
    jboss.messaging:service=ServerPeer
 </depends>
 <depends>jboss.messaging:service=PostOffice</depends>
 <attribute name="JNDIName">queue/MyQueue</attribute>
 <attribute name="RedeliveryDelay">10000</attribute>
 <attribute name="MaxDeliveryAttempts">3</attribute>
</mbean>

References:

JBoss Messaging:
http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-2.0.0.alpha1/html/performance.html

Migrating from JBoss 4 to JBoss 5:
http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga/

You can check this URL also for configuration guidelines (JBoss Messaging 1.4.4):
http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.4.GA/html/configuration.html#conf.destination

I don’t know whether I should call it an issue. But for me it was an issue. Recently I switched to JBoss 5.1.0 GA. But when I tried to run it, it was throwing the following exception:

[ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
        at java.security.AccessController.doPrivileged(Native Method)

You will have this problem if you are working with JDK 1.5.x. You can switch to JDK 1.6.x and you can get it working fine. But my entire work setup required me to run my Eclipse Ganymede on 1.5 but JBoss on 1.6. So I wrote a batch file which look like this:

@echo off
echo Overriding the Jboss home and Java home ...
set JBOSS_HOME=D:\jboss-5.1.0.GA
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0
echo Jboss home: %JBOSS_HOME%
echo Java home: %JAVA_HOME%
call %JBOSS_HOME%\bin\run.bat -b 192.168.x.y

So I can have my Eclipse running on 1.5 with JBOSS_HOME set to JDK 1.5 and JBoss on 1.6. Hope this will be helpful for you in some way.

Venu had another JBoss hack and he was able to fix one more issue that may bubble up during the migration from JBoss 4.x to 5. This time found out how solve “Adding multiple last resources is disallowed. Current resource is ….” exception which happens while trying to access an EJB from a different EAR with in a transaction and trying to commit that transaction.

Read the article here

What is a filter?
From the JSR 154 specification,

A filter is a reusable piece of code that can transform the content of HTTP requests, responses, and header information. Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource.

How to write a filter?
We can create a filter by writing a new class which implements javax.servlet.Filter. We need to specify the filters in the deployment descriptor so that the container can create a filter chain to process the request/response.

The filters in deployment descriptor:

<web-app>
	<filter>
		<filter-name>MyFilter</filter-name>
		<filter-class>subin.rnd.enterprise.filter.MyFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>MyFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>MyFilter</filter-name>
		<servlet-name>MyServlet</servlet-name>
		<dispatcher>REQUEST</dispatcher>
	</filter-mapping>
</web-app>

We can have a filter (or a chain of filters) processing the request/response. In the above descriptor, we are linking a filter for a URL pattern as well as for a specific servlet. So in the above case, for MyServlet, the filter will get executed twice as we have mapped the filter MyFilter to all URLs and for MyServlet. So the order of execution will be MyFilter.doFilter() > MyFilter.doFilter() > MyServlet.doGet().

MyServlet.java

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet
extends HttpServlet
{
  @Override
  public void doGet(HttpServletRequest request,
    HttpServletResponse response)
  throws ServletException
  {
    System.out.println("doGet()");
    response.setContentType("text/plain");
    ServletUtility.write(response, "Hello world!".getBytes());
  }
}

MyFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

public class MyFilter
implements Filter
{
  public void destroy()
  {
  }

  public void doFilter(ServletRequest request, ServletResponse response,
     FilterChain filterChain)
  throws IOException, ServletException
  {
     System.out.println("doFilter()");

     ByteStreamResponseWrapper responseWrapper = null;
     byte[] responseAsBytes = null;
     String processedResponse = null;

     // Creating a response wrapper
     responseWrapper = new ByteStreamResponseWrapper(
        (HttpServletResponse) response);
     filterChain.doFilter(request, responseWrapper);

     // Process the response
     processedResponse = responseWrapper.toString();
     if (null != processedResponse)
     {
       processedResponse = processedResponse.toUpperCase();
       responseAsBytes = processedResponse.getBytes();
     }

     // Writing the response (as bytes) to the servlet output stream
     ServletUtility.write(response, responseAsBytes);
  }

  public void init(FilterConfig filterConfig)
  throws ServletException
  {
    // We can initialize a filter using the init-params here
    // (which we defined in the deployment descriptor - web.xml)
  }
}

Other files
There are two more Java files – ByteStreamResponseWrapper & ServletUtility. ByteStreamResponseWrapper is an extension of javax.servlet.http.HttpServletResponseWrapper with some methods – toString(), getOutputStream() & getWriter() – overriden. ServletUtility is a utility class to write a byte stream to the servlet output stream.

Output
The “Hello world!” from MyServlet is filtered to “HELLO WORLD!”  by MyFilter.

Fig: Output in browser

Fig: Jboss console output

Note:
I wanted to put above XML in syntax-highlighted mode; but the WordPress plug-in failed miserably. Tough luck.