Springify The Strategy Pattern

            The strategy pattern, sure we have heard enough and used enough many times before. But if you are wondering how effectively one could use this pattern in a spring powered application then here are few approaches. I wouldn’t waste time talking about strategy pattern. So let’s get started with some code, consider a typical eCommerce company offering various levels of savings on shipping cost based on the type of memberships. So let’s keep this logic simple here to try out various approaches.

First thing First

  Here are few basic components of strategy pattern first. Start with an interface ShippingCostStrategy.java as shown below,

public interface IShippingCostStrategy {
    public double calculate(Item item);
}

Now write few possible strategy implementations like below,

public class PrimeShippingCostStrategyImpl implements IShippingCostStrategy {
     public double calculate(Item item) {
        double cost = 0.0;
        //Calculate the shipping for prime members 
        return cost;
     }
} 

public class PremiumShippingCostStrategyImpl implements IShippingCostStrategy {
     public double calculate(Item item) {
        double cost = 0.0;
        //Calculate the shipping for premium members 
        return cost;
     }
}

public class RegularShippingCostStrategyImpl implements IShippingCostStrategy {
     public double calculate(Item item) {
        double cost = 0.0;
        //Calculate the shipping for regular members 
        return cost;
     }
}

public class Item {
   private int itemId;
   private String code;
   private double price;

   public Item() {
      super();
   }
 
   public Item(int itemId, String code, double price) {
      super();
      this.itemId = itemId;
      this.code = code;
      this.price = price;
   }

   //All the getter and setter methods are omitted for brevity
}

Define these beans in the shippingCost-context.xml like below and these are required no matter what the approach is,

<bean id="primeShippingStrategy" class=" xxx.xxx.PrimeShippingCostStrategyImpl" />
<bean id="premiumShippingStrategy" class=" xxx.xxx.PremiumShippingCostStrategyImpl" />
<bean id="regularShippingStrategy" class=" xxx.xxx.RegularShippingCostStrategyImpl" />

Approach #1

             In this approach we will keep our context for the strategy simple meaning we will let the client (service) to take the responsibility of determining the possible right strategy implementation class and setting in to the context.

The calculateShipping method in the context will then call the calculate method on the strategy that is being set.

The ShippingContext.java we got here is as shown below,

public class ShippingCostContext {
   IShippingCostStrategy shippingCostStrategy = null;
 
   public double calculateShipping(Item item){
      return shippingCostStrategy.calculate(item);
   }
 
   public void setShippingCostStrategy(IShippingCostStrategy shippingCostStrategy) {
      this.shippingCostStrategy = shippingCostStrategy;
   }
  
}

Let’s look at the ShippingCostService that is being the client for this strategy.

Here we are injecting all the strategy classes and context into this client.

public class ShippingCostService {

   private PrimeShippingCostStrategyImpl primeShippingStrategy = null;
   private PremiumShippingCostStrategyImpl premiumShippingStrategy = null;
   private RegularShippingCostStrategyImpl regularShippingStrategy = null;
   private ShippingCostContext shippingContext = null;
 
   public double calculateShipping(Item item, String memberStatus){
      double cost = 0.0;
      if(memberStatus.equalsIgnoreCase(StrategyConstants.MEMBER_PRIME))
         shippingContext.setShippingCostStrategy(primeShippingStrategy);
      else if(memberStatus.equalsIgnoreCase(StrategyConstants.MEMBER_PREMIUM))
         shippingContext.setShippingCostStrategy(premiumShippingStrategy);
      else if(memberStatus.equalsIgnoreCase(StrategyConstants.MEMBER_REGULAR))
         shippingContext.setShippingCostStrategy(regularShippingStrategy);
   
      cost = shippingContext.calculateShipping(item);
    return cost;
 }

 //All the setter and getter for the above attributes goes here

}//End of ShippingCostService

Now the spring configuration would be straight forward,

<bean id="shippingContext" class=" xxx.xxx.SpringShippingCostContext" />
<bean id="shippingCostService" class=" xxx.xxx.ShippingCostService" >
   <property name="primeShippingStrategy" ref="primeShippingStrategy"/>
   <property name="premiumShippingStrategy" ref="premiumShippingStrategy"/>
   <property name="regularShippingStrategy" ref="regularShippingStrategy"/>
   <property name="shippingContext" ref="shippingContext"/>
</bean>

         

Simple class to test this out,

public static void main(String args[]) {
   ApplicationContext context = new ClassPathXmlApplicationContext("shippingCost-Context.xml"); 
   ShippingCostService shippingCostService = ShippingCostService)context.getBean("shippingCostService");
  
   String memberStatus = StrategyConstants.MEMBER_PREMIUM; //REGULAR, PREMIUM, PRIME
  
   Item item = new Item(1, "PREMIUM", 20.00);
   double cost = shippingCostService.calculateShipping(item,memberStatus);
   System.out.println("Shipping cost: for Member type: "+ memberStatus+ ", cost: "+cost);
}

Approach #2

             In this approach we are transferring the responsibility of determining the right strategy from client to the context.

So we will have to inject all the strategy implementation classes into the context as shown below,

public class ShippingCostContext {
  
  private PrimeShippingCostStrategyImpl primeShippingStrategy = null;
  private PremiumShippingCostStrategyImpl premiumShippingStrategy = null;
  private RegularShippingCostStrategyImpl regularShippingStrategy = null;
 
 
  public double calculateShipping(Item item, String memberStatus){
     double cost = 0.0;
     if(memberStatus.equalsIgnoreCase(StrategyConstants.MEMBER_PRIME))
         cost = primeShippingStrategy.calculate(item);
     else if(memberStatus.equalsIgnoreCase(StrategyConstants.MEMBER_PREMIUM))
         cost = premiumShippingStrategy.calculate(item);
     else if(memberStatus.equalsIgnoreCase(StrategyConstants.MEMBER_REGULAR))
         cost = regularShippingStrategy.calculate(item);
     return cost;
  }
 
  // All the setter and getter for the above attributes goes here
}

As we see the calculateShipping method in context will determine the call to the right strategy class based on the new parameter memberStatus. There by we freed the ShippingCostService from making the decision of injecting the right strategy implementation class into the context.

public class ShippingCostService {
 
     private ShippingCostContext shippingContext = null;
 
     public double calculateShipping(Item item, String memberStatus){
         double cost = 0.0;
         cost = shippingContext.calculateShipping(item, memberStatus);
         return cost;
     }
 
     // All the setter and getter for the above attributes goes here

}

The spring configuration for this approach would be,

<bean id="shippingContext" class=" xxx.xxx.SpringShippingCostContext" >
     <property name="primeShippingStrategy" ref="primeShippingStrategy"/>
     <property name="premiumShippingStrategy" ref="premiumShippingStrategy"/>
     <property name="regularShippingStrategy" ref="regularShippingStrategy"/>
</bean>


<bean id="shippingCostService" class=" xxx.xxx.ShippingCostService" >
     <property name="shippingContext" ref="shippingContext"/>
</bean>

We could test this approach out using the same test class code as given above in approach 1.

Approach #3

            The third approach improvises the approach 2 by introducing a map of available strategies.

So introducing any new strategy would just be a matter of configuring rather than coding in context.

Look at this code for context under this approach,

public class ShippingCostContext {
     private Map shippingStrategies = new HashMap(); 
  
     public double calculateShipping(Item item, String memberstatus){
         double cost = 0.0;
         if(shippingStrategies.containsKey(memberstatus)){
            IShippingCostStrategy shippingCostStrategy = (IShippingCostStrategy)shippingStrategies.get(memberstatus);
         if(shippingCostStrategy != null)
             cost = shippingCostStrategy.calculate(item);
  }
  
     return cost;
 }
 
     public void setShippingStrategies(Map shippingStrategies) {
         this.shippingStrategies = shippingStrategies;
 }
}

Context now holds the map of all configured strategy beans in it. This wouldn’t affect the way client invokes the strategy at all.

All it needs to do is pass an additional parameter memberStatus to the context to help determine the right strategy.

public class ShippingCostService {
     private ShippingCostContext shippingContext = null;
 
     public double calculateShipping(Item item, String memberStatus){
         double cost = 0.0;
         cost = shippingContext.calculateShipping(item, memberStatus);
         return cost;
     }
}

The configuration for this approach is simple enough as we are going to use the util schema to achieve this.

We created the property shippingStrategies of type Map with key using static fields and value would be respective bean.

<bean id="shippingContext" class="xxx.xxx.ShippingCostContext" >
   <property name="shippingStrategies">
     <map>
       <entry>
         <key>
           <util:constant static-field="xxx.xxx.StrategyConstants.MEMBER_REGULAR"/>
         </key>
           <ref bean="regularShippingStrategy" />
        </entry>
        <entry>
            <key>
             <util:constant static-field=" xxx.xxx.StrategyConstants.MEMBER_PREMIUM"/>
            </key>
            <ref bean="premiumShippingStrategy" />
        </entry>
        <entry>
            <key>
             <util:constant static-field=" xxx.xxx.StrategyConstants.MEMBER_PRIME"/>
            </key>
            <ref bean="primeShippingStrategy" />
        </entry>
    </map>
  </property>
</bean>


<bean id="shippingCostService" class=" xxx.xxx.ShippingCostService" >
      <property name="shippingContext" ref="shippingContext"/>
</bean>

Make sure to add the util namespace and shema location information to the header beans of the context xml like as shown,

xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd"

That’s it you are ready to test your strategy using the same test class above.

Final Note

    The advantage of approach 1 is, the client will be in control if the business logic in client (service) that determines the strategy to use is inseparable or tightly coupled. The same advantage could turn into a disaster with tight coupling. So approach 2 would bring in the much needed loose coupling and let strategy context take care of determining the right strategy. This brings in an opportunity to add more business intelligence into the context. The last approach as you saw definitely improvises the overall strategy to implement the strategy pattern in spring. Sure there must be even better approaches out there and if you do have one please share.

Reference

1. Reference to the strategy pattern.
2. Reference to the Spring Util schema documentation.

Rules for Java Application

Well, I am sure you have heard enough about rules and rule engine. But if you are scavenging for a quick start tutorial with simple example then you are on the right place. The example supplied with this article uses jRuleEngine v 1.3. Let me first throw few lines out on the rules and rule engine just to fill you.

What is a rule?

Rule is a business rule that validates the data under certain circumstances.

Simply rule is nothing but the business logic that we code in our service classes using if else statements.

Lets take a typical shopping cart as an example and say if couponCode.equals(“TRY10”) then apply 10% off of the total amount in the cart. So checking the various coupon codes is one rule inside the OrderService class. Applying 10% off is an action that goes with the rule if it is applicable.

Now imagine, coding one dozen coupon codes and applicable actions around it inside the service class. This is a very simple scenario but enough to start thinking of kicking this logic out of service class. This is where we would end up using the rule engine so that business can drive these variants without code changes.

What is a rule engine?

A rule engine is simply an interpreter of these rules or if/then statements. Theoretically you give the input to this rule engine, tell the set of rules to apply on the input and expect the desired output.

So now these rules can be defined in external files in the format of xml and other proprietary formats that adhere to RuleML standard or simply drive the rules from database tables.

Enough explanation, let’s get our hands dirty

So say this ecommerce company makes various seasonal coupons available for their customers. Just for the brevity we will consider each coupon has expiration date and discount percent. So the shopping cart application should be managing these coupons more effectively in order to cope with business ideas. It’s time to bring in the rule engine.

First thing first

            Let’s get started with rules. We could drive these rules through 2 ways, xml or database tables as I mentioned earlier.

Loading rules through XML

            Take a look at the code snippet below


<rule-execution-set>
    <name>CouponRule</name>
    <description>Rules to apply coupon discounts</description>
</rule-execution-set>
 

We just defined a rule execution set with name and description to look up later.

Now we could use synonymn element as name itself suggests, define a handler for any input objects that could be referred inside the rule xml and rule engine.


<synonymn name="order" class="com.rule.model.Order" />
<synonymn name="coupon" class="com.rule.model.Coupon" />
 

Now we could define a rule using rule element like below,   


<rule name="Rule10" description="10% discount coupon rule" >
    <if leftTerm="coupon.getName" op="=" rightTerm="TRY10" />
    <if leftTerm="coupon.isValid" op="=" rightTerm="true" />
    <then method="order.applyCoupon" arg1="10.00" />
    <then method="order.setComment" arg1="Applied 10% off." />
</rule>
 

What we are trying to do with the above rule lines is, if coupon name is TRY10 and order date (assume) today is before or equals to expire date then apply 10% off of total order amount of the cart and set the comment. For the brevity I used comment but practically it could be a logic to mark the cart that coupon has been applied already. That’s pretty much it for one coupon rule.

Now if you have tens or hundreds of coupons then you will end up writing that many rule elements inside this xml.

Loading rules through database tables

            In theory rule in xml files should be good enough but not enough when it comes to manageability on long run. Just imagine adding hundreds of coupon rules would simply bloat the xml. Secondly xml changes would require an application restart. Using tables would bring better manageability of rules and makes it more dynamic.

OK, how do we create these rule tables and how do we define these rules in them?

Rules Class Diagram

            If you look at the jrule engine source code you would see these classes going on in their rule package.

Logical ERD

            A straight translation of the above classes would result in tables shown below in the ERD diagram. These tables represent a simple conversion of the elements defined in xml into table.

Well we could go one level up and define the rule execution set to hold these rules.

Now it is just a matter of writing insert/update statements into these tables but you could build the UI in your application to manage these rules as well. If you decide to have a UI for business to manage these rules then you will have to come up with relational tables around the required properties. I will try to cover that in my next article.

Rest of the code around rule api’s is simple and self explanatory in this example so I wouldn’t bother digging into it.

If you look into this convenience wrapper class RuleInfrastructureServiceImpl, you will notice there are utility method to get the ServiceManager, RuleAdministrator and several overloaded createRuleExecutionSet methods.

The createRuleExecutionSet could be called with input stream to load rules from xml where as called with RuleImpl object to load rules off of tables.

Ultimately you will need to create a rule session to execute rules. A rule session is a communication connection between your application code and rule engine. In theory each rule session represents one execution rule set.

It is always best practice to use a stateless rule session over stateful in most scenarios considering the performance bottlenecks.

The OrderService’s applyCoupon method would take three parameters Order, couponCode entered by the customer and rule session object.

Final Note

          Using rule engine would simplify lot of business operation around the application but would definitely takes 2 plus 2 cents to design and build such rules interfaces in the application.

Reference

          Download the source code for the example used in this article.

Springify the LDAP application

       Spring LDAP makes LDAP operations so simple. Spring lets you write the code and structure the functionalities around LDAP just like any other data access functionality. It provides fine wrapped template to work with LDAP just like JDBC or JMS. Let me share some of the basic operations using spring’s LdapTemplate that are most common in any application. Spring source has put together a very nice and detailed documentation, so please refer http://static.springsource.org/spring-ldap/docs/1.3.x/reference/html/ for Spring LDAP and refer to open source LDAP http://www.openldap.org/ for more details.

First thing First
       Let’s categorize these basic LDAP operations into the following
         • Creating an entry or Binding.
         • Deleting an entry or unbinding.
         • Retrieving basic attributes.
         • Retrieving attributes using filter.
         • Retrieving operational attributes.

Create an Entry
        To add an entry into the LDAP all you have to do is to call bind method on ldapTemplate. There are two ways of binding the new entry.
First way is calling the bind(Name dn, Object obj, Attributes attributes). So create the Attributes with attributes to bind. Here you are creating a new person object with attributes to bind.


BasicAttribute personBasicAttribute = new BasicAttribute("objectclass");
personBasicAttribute.add("person");
personAttributes.put(personBasicAttribute);
personAttributes.put("cn", “Vinay Shivaswamy”);
personAttributes.put("description", “some description here”);

Create the DistinguishedName by providing the path in string format.


DistinguishedName newContactDN = new DistinguishedName("ou=users");
newContactDN.add("cn", “Vinay Shivaswamy”);

Now call the bind method by passing the Attributes and DistinguishedName just created.


ldapTemplate.bind(newContactDN, null, personAttributes);

Second way is to call bind(DirContextOperations ctx). So create the DistinguishedName by providing the path in string format.


DistinguishedName newContactDN = new DistinguishedName("ou=users");

Create the DirContextOperations object by passing the DistinguishedName just created. Once context is created its just matter of setting attributes into this context as shown below.


DirContextOperations ctx = new DirContextAdapter(dn);
ctx.setAttributeValue("cn", "Vinay Shivaswamy");
ctx.setAttributeValue("description", "some description");

Now Call the bind method by passing the DirContextOperations just created.
ldapTemplate.bind(ctx);

Delete an entry
       Deleting an entry is lot easier than creating one. All you have to do is to call unbind method as shown below by passing DistinguishedName,


DistinguishedName newContactDN = new DistinguishedName("ou=users");
newContactDN.add("cn",”Vinay Shivaswamy”);
ldapTemplate.unbind(newContactDN);

Retrieving basic attributes
       The basic attributes can be retrieved using lookup or search methods of LdapTemplate. Below is an example of using search to get the list of matching common name attributes only. Search would return a List and if you are interested in retrieving unique matching entry then use searchForObject method instead.


ldapTemplate.search(baseName, "(objectclass=person)", new AttributesMapper() {
public Object mapFromAttributes(Attributes attrs) throws NamingException {
return attrs.get("cn").get();
}
});

If you simply want to retrieve all the available attributes then write your own AttributesMapper implementation, add all the attributes to return.

Retrieving attributes using filter
       Retrieving attributes based of search criteria would be helpful and you can do that with the help of Filter. Spring Ldap filter package provides various supporting filters. Look at the example below to see how easy it is to build and use the filter.


AndFilter andFilter = new AndFilter();
andFilter.and(new EqualsFilter("objectclass","person"));
andFilter.and(new EqualsFilter("cn",”Vinay Shivaswamy”));
andFilter.and(new EqualsFilter("sn",”Shivaswamy”));

Once the filter is built then it is just the matter of calling search by passing the filter to retrieve the matching email attribute,


ldapTemplate.search("baseName", andFilter.encode(),new AttributesMapper() {
public Object mapFromAttributes(Attributes attrs)
throws NamingException {
return attrs.get("email").get();
}
});

Retrieving operational attributes
       Ldap Server maintains many operational attributes internally. Example entryUUID is an operational attribute assigns the Universally Unique Identifier (UUID) to the entry. The createTimestamp, modifyTimestamp are also operational attributes assigned to the entry on create or update. These operational attributes does not belong to an object class and hence they were not returned as part of your search or lookup. You need to explicitly request them by their name in your search or build the custom AttributeMapper implementation with matching attribute names.
Now let’s try to retrieve the entryUUID, first you need to build the search controls like this,


SearchControls controls = new SearchControls();
controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
controls.setReturningObjFlag(false);
controls.setReturningAttributes(new String[]{"entryUUID"});

Once you have search control then it’s simply calling search method just like retrieving any other attributes.


ldapTemplate.search("baseName", "(objectclass=person)", controls, new AttributesMapper() {
public Object mapFromAttributes(Attributes attrs) throws NamingException {
Attribute attrUuid = attrs.get("entryUUID");
return attrUuid;
}});

Here is another way to do the same using ContextMapper,


ldapTemplate.search("baseName","(objectclass=person)", 1, new String[]{"entryUUID"},
new ContextMapper(){
public Object mapFromContext(Object ctx) {
DirContextAdapter context = (DirContextAdapter)ctx;
return context.getStringAttributes("entryUUID");
}
});

Let’s add the filter based off of operational attributes like below,


OrFilter orFilter = new OrFilter();
orFilter.or(new GreaterThanOrEqualsFilter("createTimestamp", "YYYYMMDDHHMMSSZ"));
orFilter.or(new LessThanOrEqualsFilter("modifyTimestamp", "YYYYMMDDHHMMSSZ"));

Now call the above search with the filter


ldapTemplate.search("baseName", orFilter.encode(), controls, new AttributesMapper() {
public Object mapFromAttributes(Attributes attrs) throws NamingException {
Attribute attrUuid = attrs.get("entryUUID");
return attrUuid;
}});

Final Note
       Spring simplifies the Ldap operations indeed. We just saw that but there is lot more to dig into if you need to and I hope this article serves as a quick reference to jump start your exploration. Good luck.

MDB listening to Oracle AQ using Sun Adapter

Sometime back I had to work on MDB implementation for JBoss 5.1 to connect to oracle AQ. I implemented the solution using Sun AQ resource Adapter.

The purpose of this article is not to justify this approach versus JBoss recommended approaches like JBoss’s default JMS messaging implementation, ESB and so on but is to make it easy for anyone that decides to go with this approach. As this implementation could easily run into many issues, this article should help you going.

Yes this is time consuming and frustrating due to the facts that,

1.  The official support for this adapter has been stopped.

2.  No supporting documents for this implementation.

3.  There are threads in few forums that talk about this implementation but it is kind of hard to put it all together.

First Thing First

Let’s get started, deploy and run the example to see it working.

1.       Download and execute the scripts from myAQ.sql in your oracle schema

a.       Make sure you have proper privileges as stated in the script file, ask your DBA if you are not one.

b.      Create queue table and queue and start the queue

c.       Important create queue table with pay load type SYS.AQ$_JMS_MESSAGE.

d.      Create a procedure from the above script file to enqueue and dequeue the messages.

e.      Run the enqueue procedure.

f.        Run the dequeue procedure, you will see the output

JMS Message is: Testing my first AQ JMS message

2.       Download the sun AQ adapter oracleAQ.rar from the resources section below and put it under your {JBOSS_INSTALL}\server\default\deploy directory.

3.       Download the myAQ-ds.xml and put it under {JBOSS_INSTALL}\server\default\deploy directory.

a.       Modify the highlighted configuration to suite your environment

<mbean code="org.jboss.resource.deployment.AdminObject" name="jboss.oracleaq:service=Queue,name=DEMO_QUEUE">
   <attribute name="JNDIName">myaq/queue/demo</attribute>
   <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='oracleaq.rar'</depends>
   <attribute name="Type">javax.jms.Queue</attribute>
   <attribute name="Properties">DestinationProperties=owner\=demouser, name\=DEMO_QUEUE</attribute>
</mbean>


<config-property name="ConnectionFactoryProperties" type="java.lang.String">jdbc_connect_string=jdbc:oracle:thin:demouser/demopassword@<host>:<port>:<sid>,host=<host>,user=demouser,password=demopassword,port=<port>,sid=<sid>,driver=thin
</config-property>

    <config-property name="username" type="java.lang.String">demouser</config-property>

    <config-property name="password" type="java.lang.String">demopassword</config-property>
 

4.       Now download all the dependency jars that are needed. Most of these libraries are part of oracle. You could handle these dependencies in 2 ways

a.       Download the following jar files from your oracle installed directory and copy them directly to {JBOSS_INSTALL}\server\default\lib directory.

aqapi.jar

bcel.jar

connector.jar

javax77.jar

jmxri.jar

oc4jclient.jar

ojdbc14.jar

b.      You could rebuild the downloaded oracleaq.rar file to include all the dependency jars above.

5.       Download the source jar file myAQ.jar and put it under {JBOSS_INSTALL}\server\default\deploy directory. Before copying you need to change some configuration in MDB, so to do that

a.       Import the jar project as EJB jar in to eclipse or any IDE of your choice.

b.      Open the java source file MyAqMessageBean.java and update the highlighted configuration through annotations.

@MessageDriven(

activationConfig = {

@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),

@ActivationConfigProperty(propertyName = "connectionFactoryProperties", propertyValue = "jdbc_connect_string=jdbc:oracle:thin:demouser/demopassword@{host:port:sid},host=<host>,user=demouser,password=demopassword,port=<port>,sid=<sid>,driver=thin"),

@ActivationConfigProperty(propertyName="destinationProperties", propertyValue="owner=demouser,name=demo_queue"),

    @ActivationConfigProperty(propertyName="userName", propertyValue="demouser"),

    @ActivationConfigProperty(propertyName="password", propertyValue="demopassword"),

    @ActivationConfigProperty(propertyName="ConnectionFactoryClassName", propertyValue="oracle.jms.AQjmsConnectionFactory"),

    @ActivationConfigProperty(propertyName="QueueConnectionFactoryClassName", propertyValue="oracle.jms.AQjmsQueueConnectionFactory")

})

@ResourceAdapter("oracleaq.rar")

c.       Now export the EJB jar directly in to the JBoss deploy directory.

6.       Now it’s time to start the JBoss server.

7.       Enqueue the message by running the procedure

8.       See the messages were picked by MDB on the JBoss console.

Issues

Here are the few issues that you could avoid though,

1.       Do not use 10g Lite since lite doesn’t come with DBMS_AQADM packages installed and so not able to enqueue or dequeue the message type SYS.AQ$_JMS_MESSAGE. There was an alternate solution suggested in some forum i.e. to run some DBMS-XXX package and I couldn’t get it to run so I decided to go for standard 10g edition as that was the only other option to get it work.

2.       Do not create the queue table with payload message type other than $AQ_JMS_MESSAGE as JBoss would talk to the AQ only if the payload is of this type.

3.       The adapter doesn't support XA connections in MDB.

4.       Now the bean listens to the first message only and any subsequent messages were simply lost. Solution to this is to update couple of files in oracleAQ.rar file. Well you should not run into this issue as I have supplied the updated rar file here. The details of those changes are in reference section.

5.       There is one minor glitch that you have to live with is when you try to stop the JBoss you will see error stack due to the JBoss thread confliction while calling releaseEndpoint method in InboundJmsResource.

6.       I tried this solution in JBoss 7.0.1 and at that time there were some issues related to registering the resource adapter with JBoss. I know recently some of those jira issues around this reported to be closed but I haven’t got back on it.

Conclusion

            This solution works perfectly considering application environment scope and limitations with one exception on shutdown. The community would surely appreciate if you share any resolutions to this issue or even better solution.

References

Great starter post https://community.jboss.org/wiki/AQSunAdapter
Details of implementation https://community.jboss.org/message/230057

Downloads

AQ data source configuration myAQ-ds.xml
Source Code myAQ.jar
Oracle AQ resource adapter oracleaq.rar
Oracle10g AQ SQL myAQ_10g.sql
Oracle AQ resource Adapter source oracleaq-source.rar