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

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.

	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…

Continue reading

JBossWS CXF – POJO vs Stateless [1104]

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.

Continue reading