The Annotation Paradigm Shift

One of the current paradigm shifts in the Java world is to update existing APIs that were originally based on inheritance and replace them with much the same API only this time based on annotations.

For example, EJB 2.x used inheritance,

EJB3 Transaction Annotation

This blog documents the EJB3 transaction annotations and was written because I had to add a transaction annotation to an EJB recently and the javadoc for JEE 5 didn’t document what the TransactionAttributeType values do; some are obvious if you’ve done this before, but I'm not psychic.

Message Driven Bean Annotations for EJB3

The other day, I blogged about the name and mappedName attributes of @Stateless, @Stateful and @MessageDriven annotations of EJB3.

In writing that blog, it occurred to me that it’s very hard to find information on which attributes are available. In the good ol’ days of EJB 2.x, all you had to do was to look at the appropriate EJB schema file and you knew which XML element and attributes did what.

Using EJB3 Annotations with Weblogic 10.3 / 11g

It seems to me that BEA and now Oracle are usually behind the curve when it comes to implementing the latest JEE specifications and often interpret things rather differently to the guys working on the Glassfish reference implementation.

From Use-Case to Coding

How do you go about writing software? Is it an art or a science? Are classes created from the imagination or are they in the requirements waiting to be discovered? This blog is a stab at figuring this out by attempting to document how I currently approach coding. I’m assuming a lot: you have your development environment, you know what tools you’re using, you know your target environment, you know the system’s architecture and probably lots more besides.

To illustrate the process, consider the following fragment taken from a hypothetical use-case:

Transactions and Coding MDBs

Recently I posted a small blog on how to use setRollbackOnly() to inform your JEE container that your MDB has encountered an error, and that doing this was the preferred method of error handling when using Container Managed Transactions.

It seems to me that although many of the EJB technical books tell you how to write a simple MDB implementation using the MessageListener interface they usually don’t mention transactions in any detail or assume Container Managed Transactions from the start.

MDB Durable Subscribers

A durable subscriber is an MDB that will receive its messages even if it goes down. To make a MDB into a durable subscriber, you need to add a couple of lines to the ejb-jar.xml and weblogic-ejb-jar.xml.

The Ejb-Jar


<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
  <display-name>Event Logging Component</display-name>
  <enterprise-beans>
    <message-driven> 
      <ejb-name>EventLoggingMDB</ejb-name> 
            <ejb-class>uk.gov.hmrc.candi.service.ejb.EventLoggingMDB</ejb-class> 
      <transaction-type>Container</transaction-type>
          <message-destination-type>javax.jms.Topic</message-destination-type>
           <activation-config>
                <activation-config-property>
                    <activation-config-property-name>subscriptionDurability</activation-config-property-name>
                    <activation-config-property-value>Durable</activation-config-property-value>
                </activation-config-property>
           </activation-config>
       </message-driven> 
  </enterprise-beans> 
  <assembly-descriptor> 
    <container-transaction> 
      <method> 
        <ejb-name>EventLoggingMDB</ejb-name> 
        <method-name>*</method-name> 
      </method> 
      <trans-attribute>Required</trans-attribute> 
    </container-transaction> 
  </assembly-descriptor> 
</ejb-jar>


---

The Weblogic-Ejb-Jar


<?xml version="1.0" encoding="UTF-8" ?> 
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/10.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.bea.com/ns/weblogic/10.0 http://www.bea.com/ns/weblogic/10.0/weblogic-ejb-jar.xsd"> 
 
  <weblogic-enterprise-bean>
    <ejb-name>EventLoggingMDB</ejb-name>
     <message-driven-descriptor>
      <pool>
                <max-beans-in-free-pool>1</max-beans-in-free-pool>
              <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
      </pool>
          <destination-jndi-name>EventTopic</destination-jndi-name> 
          <connection-factory-jndi-name>weblogic.jms.XAConnectionFactory</connection-factory-jndi-name> 
          <jms-client-id>EventLoggingClient</jms-client-id>
          <max-messages-in-transaction>1</max-messages-in-transaction>
     </message-driven-descriptor>
  </weblogic-enterprise-bean>
</weblogic-ejb-jar>


EJB/MDB class loading problems with Spring 2.x

This little blogette covers a problem that arises when you try to deploy an EAR file on Weblogic’s web-server where the JEE components such as MDBs and EJB use the wrong Spring Application Context in the wrong place and at the wrong time.

When this error occurs you’ll get a NoClassDefFoundError exception that refers to a class that somewhere deep inside the call stack. This exception happens even though the EAR is correctly configured with all JARs present and classpaths correct.

This is caused by the use of Spring’s ClassPathXmlApplicationContext which loads an entire context for every EJB / MDB.

The fix is to use ContextSingletonBeanFactoryLocator and a beanrefContext.xml (though the xml file name is configurable), which loads the Application context once, sharing it between all EJB or MDB instances.

How to do MDB error handling

If an MDB is consuming a message when an unexpected error occurs most programmers think that the obvious thing to do is to throw an exception back to the MDB's container. The container can then decide how to handle the error: drop the message, delay for a while and then resend depending on how JMS queue or topic is configured.

If your MDB is transactional, then to inform the container of your error all you need to do is to use the bean context to call setRollbackOnly().

To inform the container of a problem for any MDB—transactional or non-transactional—you can throw an exception derived from the RuntimeException or Error thrown by the MDB. This causes the MDB instance to be destroyed and re-created, which incurs a performance penalty.

For more information, take a look at the Weblogic / Oracle website

Applies to Weblogic webserver.