Using CXF Interceptors to do some magic around your web service calls [1105]

Sun, 06 Nov 2011 12:24:28 +0000

We use JBossWS CXF for a heavily utilised enterprise system. It links into spring to pick up and execute beans. We have a bunch of exceptions that could get thrown.

To simplify it, the code was originally written to create an anonymous class a la Runnable which is wrapped around a try catch block. The exceptions that are thrown are then converted to a soap fault and passed back.

```java private SOAPFaultException convertToSoapException(ApplicationException e) { try { if(null == soapFactory) { soapFactory = SOAPFactory.newInstance(); } SOAPFault sf = soapFactory.createFault(); sf.setFaultString( e.getMessage() ); sf.setFaultCode( Integer.toString(e.getErrorCode()) ); return new SOAPFaultException( sf ); } catch(SOAPException soapException) { throw new RuntimeException( soapException ); } } ```

Nothing inherently wrong with this. However, there are a couple of issues with this in that each soap method is set to throw an ApplicationException and there is not further documentation of which of the subclasses are actually relevant to that method.

In a runtime environment, this is not hugely relevant. However, when generating documentation from the WSDL’s, it is.

To resolve this, we changed each method to throw their relevant exception, and wrote an interceptor to pick up the exception and convert it…

The first step was to write an interceptor which is surprisingly simple and straightforward.

```java public class ExampleSoapFaultInterceptor extends AbstractSoapInterceptor { Logger log = Logger.getLogger(getClass()); public QuarkSoapFaultInterceptor() { super(Phase.MARSHAL); } @Override public void handleMessage(SoapMessage message) throws Fault { Fault f = (Fault) message.getContent(Exception.class); Throwable cause = f.getCause(); if (cause instanceof ApplicationException) { log.info("Exception Thrown", cause); QuarkException e = (QuarkException) cause; f.setFaultCode(new QName("", String.valueOf(e.getErrorCode()))); } else { log.warn("Unexpected Exception thrown ", cause); } } } ```

The class doesn’t need to extend the AbstractSoapInterceptor but you would then have to manually implement a number of mechanisms that the abstract class provides.

The constructor simply defines where this interceptor should be inserted into as part of the chain. There is a whole bunch of different places where it can be inserted based on this. Information can be found in their documentation.

To insert this interceptor into a web service, the service needs to be annotated as follows:

```java @WebService(endpointInterface = "uk.co.kraya.example.WebService") @OutFaultInterceptors(interceptors= {"uk.co.kraya.example.interceptors.ExampleSoapFaultInterceptor"}) public class ExampleWebService implements ExampleAPI { ```

Each exception thrown from the web service will now be intercepted. You can then include any further further information in the soap fault.

In this particular case, the only thing that gets done is to update the fault code with the error code set against the exception. Any additional information can be set against the soap fault at this point. You can also log as we are doing.

JBossWS CXF - POJO vs Stateless [1104]

Sat, 05 Nov 2011 15:32:32 +0000

Cleaning up a bunch of code to reduce object instantiations got me thinking about the webservice layer. We are using POJO based webservices but it got to me wondering whether useless Stateless web service beans would improve memory usage. More accurately, whether it would improve garbage collection performance.

To test this, the plan was to build two versions of the same web service and load test it to see the memory and cpu utilisation to compare cost / performance.

In the process, I also discovered other differences.

Both the web services were built against this interface

```java @WebService public interface WSTest { @WebMethod public String greetClient(String name); } ```

That is of course a simple enough interface.

The EJB version of this is as follows:

```java @WebService(endpointInterface = "uk.co.kraya.wstest.WSTest") @Stateless @Remote(WSTest.class) public class EJBWebTest implements WSTest { public String greetClient(String name) { return "EJB Says Hello to " + name; } } ```

Simple and straightforward enough and the POJO version is not that different

```java @WebService public class PojoWebTest implements WSTest { @WebMethod public String greetClient(String name) { return "Pojo Says Hello to " + name; } } ```

I also used the following web.xml. This may not be a necessary step any more.

```xml

Archetype Created Web Application

GreetingWebService

uk.co.kraya.wstest.pojo.PojoWebTest

GreetingWebService

```

Now that was complete, there was the deployment to consider. I had assumed that I could just do one build, package it as an war and just deploy it but as it turns out, that didn’t work. This only deployed the Pojo web service. To deploy the EJB web service, I had to package it as an EJB (maven) and deploy a jar file.

This meant that I ended up with two deployments, wstestpojo.war and wstestejb.jar.

Once deployed, I used SoapUI to load test both the web services and the results were interesting.

In the grand scheme of things, the difference was pretty minimal between the two. However, the Stateless EJB web service used a little extra (3% - 5%) CPU presumably from the pooling of the beans and accessing them.

I used JBoss 5.1 and ran into an issue with log pollution

EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

This was printed every time an EJB based web service was called.

I found more information about the EJBTHREE-1337 issue and a workaround for it The workaround simply involves updating log4j to not log it which is good enough for me… :-)

As a final note, I am unsure as to how this would scale with complex web services that have multiple instantiated objects as part of it. I have a sneaky suspicion that web services with expensive object instantiations would perform better if using Stateless EJB Beans as would web services that are memory hungry. However, this has not been tested.

Web-Services on despatches

Using CXF Interceptors to do some magic around your web service calls [1105]

JBossWS CXF - POJO vs Stateless [1104]