Spring provides options to integrate many ORM frameworks available in Market and one of them is Hibernate. With the options like configuring SessionFactory and HibernateTemplate, it makes developer’s life smooth to integrate other cross cutting concerns. Amongst all the other features, Spring provides a convenient feature is to autodetect “Annotated” Entity classes from package(s) using helper bean “org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean”. The package(s) name can be injected using setter method “packagesToScan”. Set the value of this property to the package name where you place the Entity classes and you are good to go. No need to add entry for every *-hbm.xml file OR explicitly configuring annotated classes.

But recently I came across a problem, wherein I found that my application’s Entity classes were not detected and when I was querying, hibernate was simply throwing an error as “XXX is not mapped”.

Well after struggling for almost an hour and checking out all the configuration, it was not visible as what was causing the problem [almost clueless ]. The next step was (obvious) jump into the Spring code and checking out what went wrong. Aha! that really helped and I found the reason why Spring was not able to detect Entity classes. The “AnnotationSessionFactoryBean” class internally prefixes packages with “classpath*:” protocol before searching them and as stated in Spring documentation due to bug in JDK classloader the underlying classloader used by Spring to load resources is not able to recognise files kept within Jar. (mine were kept inside JAR and not in exploded format.). Though the application deployed was a Web Application which creates XmlWebApplicationContext and internally uses “ServletContextResourcePatternResolver” to resolve classes (Resolves resources insdie JAR file), was simply failing due to the fact of having prefix “classpath*:”

Having no provision to override this behaviour of “AnnotationSessionFactoryBean”, I thought of extending the class and added a method to use prefix for loading resources. Also I had to override the scanPackages method to use custom logic for loading resoruces. To load the resources from JAR you need to use inject path as WEB-INF/lib/*.jar!/com.abc. Note the “!/” in path, Spring makes use of this delimiter to identify the JAR and the resource path. After deploying the change, I found that Spring was now able to autodetect the Entity from JAR.

If Flex is dominting RIA world, CXF is dominating SOA world with its feature rich framework. CXF not only makes developers life easy by abstracting many complex task through a set of APIs but also adheres to WS-* standards without a need to having dependency on other frameworks.

On an average to develop a webservices using CXF, would hardly require 5 minutes (If developers use Code First Approach). Developer need to declare a business interface, implementation class for same and annotate both these entities with JAX-WS annotation, configure the webeservice and pufff, you are done. You don’t even need to run Webservices, plug the configuration with built-in web container and you can test Webservices right from your IDE.

Well to explain all the features of CXF, this articles won’t be enough (I would rather end up writing 1000′s of pages.). While working on one of the project involving CXF, Blaze DS, Spring and Flex, we faced one problem and that turned out to be worst nightmare. We had created a set of webservices exposed through CXF and deployed with its own WAR file. On the other hand, we had created one more application, holding Flex SWF files, JAX-WS client configured through CXF – Spring configuration in XML. The clients were injected in Remoting Destination, using SPRING dependency injection feature. Finally the remoting destinations were exposed through SPRING – Blaze DS integration project.

So far, everything worked well except one problem, each time remoting destination invokes webservice operation, a new session was getting created and hence webservices were not able to maintain state of the Client.

After visiting to various forums and going through the CXF documentation we found that, CXF does provide a way to maintain session and same is explained at

• http://stackoverflow.com/questions/1741314/jaxwsproxyfactorybean-sharing-http-session (Check first reply, second reply provided by me for handler does work perfectly.)
• http://www.theserverside.com/news/thread.tss?thread_id=40839

While both the approach are able to maintain session at client side, it requires that the client code should be aware of webservices API. In our case, since JAXWS:Client was injected through SPRING configuration, making beans aware of WS API would break the architecture. Also using both the above discussed approach are having there own problem, first solution will not be suitable if the number of webservices is huge. This means it would require tracking all the webservices in application. Second approach works well for a single webservice, the moment you use another webservice of same application, voilaaa.. you will see a new session is again created.

Well, we didnt had an option but to somehow maintain session between WS-Client and WS. A thought came in my mind to check how CXF maintains session for a single webservice using BindingProvider, I started going through HTTPConduit.

After carefully reading the source code, I realised that if I could able to add Message.PROTOCOL_HEADERS to every webservice context in a generic way, my job is done. Adding Message.PROTOCOL_HEADERS to webservice context, gives developer a chance to play with HTTP headers. I developed a JAX-WS handler and tracked the request/response for every webservice invocation and added a logic to cofigure Message.PROTOCOL_HEADERS. And yippy!!! my webservice clients are now able to maintain session and that too without a need of modifying webservice client.

All I need to do is,

1. Create JAX-WS handler and configure it in SPRING configuration file.
2. Add handler to Webservice client.
3. Use BlazeDS API to hold/retrieve reference of WS session cookies and play with Message.PROTOCOL_HEADERS.

I like the extension points provided by CXF to accomplish tasks which are not so easily available in other frameworks.

This time one more assignment to integrate Spring APIs with Jboss MQ. After reading through Spring documentation, I found its pretty easy to integrate any Messaging Provider solution into Spring application.

Configuring JMS Topic in JBoss

To create new JMS Topic destination you should configure new topic destination in [deploy_directory]/deploy/jms/jbossmq-destinations-service.xml. Following code snippet creates new Topic Destination.

jboss.mq:service=DestinationManager
jboss.mq:service=SecurityManager

Well in actual production system you should not configure guest role access with Read/write permission. Add above XML code snippet below <server> tag and save it. Start JBoss console and you should notice that JBoss will create new topic and bind it to JNDI with name as “topic/MyTopic” (Note this is generic JMS client configuration and doesn’t use any properitory JMS provider APIs. You will have to change the properties of jndiTemplate based on your Messaging Service Provider.)

Using Spring API

Now lets create client code to send messages. I assume that you are using Spring – BlazeDs integration project and aware of how to configure Spring configuration file with BlazeDS. The following code snippet must be defined in Spring configuration file. Make sure you have also imported Spring-Flex namespace.

org.jnp.interfaces.NamingContextFactory
localhost
 org.jnp.interfaces:org.jboss.naming 

java:/XAConnectionFactory

topic/MyTopic

Now you can expose jmsDestination using flex:jms-message-destination tag. (Available with Spring-BlazeDS integration jar.)

Creating Flex Client

We are done with the server side configuration and now its time to define Flex Client to subscribe to JMS topic. Flex comes with a handy tag as MX:Consumer and MX:Producer. MX:Consumer is useful to subscribe to JMS topics and queues, while MX:Producer by the name itself it is quite clear that this tag is used to publish messages to JMS. Declare following tag to subscribe to JMS topic

Note that in above example the value of destination attribute is exactly same as the value of id attribute defined for jms-message-destination tag. This still won’t start subscription to JMS topic and in order to start subscription you must explicitly subscribe to JMS topic by calling subscribe method  on MX:Consumer instance. Let assume that following function is invoked on “CreationComplete” event of application.

private function subscribeTopic():void
{
messageConsumer.subscribe();
}

This will start subscription to JMS topic destination and keep on polling to message server for any new message. OK! but how you will receive message notification, notice there are two event handler defined with MX:Consumer tag declaration. And here is the code snippet of “message” event handler.

private function consumerMessageHandler(event:MessageEvent):void
{

var msg:AsyncMessage = new AsyncMessage(event.message);
Alert.show(ObjectUtil.toString(msg.body));
}

This function just prints all the contents of the Message. If you are accessing Object style JMS message, the properties of such message can be accessed using “.” notation.

Deployment

Package all the generated SWFs and copy all the required files (JAR, XML configuration files etc) to a WAR file and deploy it on JBoss server. Hit your application URL and you should be able to receive any messages sent to JMS topic.

Known Issue

At the time of deployment, you might come across following exception being thrown by JBoss

: Failed to convert property value of type [org.jboss.mq.SpyXAConnectionFactory] to required type [javax.jms.ConnectionFactory] for property ‘connectionFactory’

Make sure that the deployed WAR file doesn’t contain and JMS-API library file. The above error is occurring due to ClassLoader issue but the error message is misleading.