Unit Testing CXF Web Services

Here is a quick little unit test setup to test your CXF service class and your client class. This is nice if you are testing marshaling issues.

@Test
  public void testMyWebService() {
    MyWebServiceImpl endpoint = new MyWebServiceImpl ();
    JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
    svrFactory.setServiceClass(MyWebServiceInterface.class);
    svrFactory.setAddress("http://localhost:9000/myService");
    svrFactory.setServiceBean(endpoint);
    svrFactory.create();

    JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
    factory.setServiceClass(MyWebServiceInterface.class);
    factory.setAddress("http://localhost:9000/myService");
    MyWebServiceInterface client = (MyWebServiceInterface) factory.create();

     List details = client.performSomeWebServiceAction("11");
    Assert.assertNotNull(details);
  }

That's it! This will bootstrap an actual JAXWS version of your service within your JVM and hit it with a real CXF client. One thing you have to make sure of, if you are running tests on a CI server be sure to use a port which is not in use on that build box.

Fixing Eclipse JDK Issue

If you have ever had the issue of eclipse complaining it was not running in a jdk here is how to fix it. Open the eclipse.ini file at the root of the eclipse installation. Add this line to the top of the file, change it to point to your jdk...

-vm
C:\Program Files\Java\jdk1.6.0_11\jre\bin\javaw

Restart Eclipse and you are done!

CXF Interface Extending Another Interface

Just a fun little finding for the day. In the newer versions of CXF you cannot have an interface you define as a WebService extend another interface. This tends to throw a SOAP Fault Exception "Unexpected Wrapper Element". The solution for this is to create another service for the interface you are extending or just merge all the methods into one interface.

Spring JDBC Template Tuning

Had a fun little issue the other day with spring's JDBC template. I was querying a fairly large data set, about 65 million records, and realized the job was running slower than molasses going uphill. After debugging the code I found the query was returning very fast, so the database was not the problem. The issue ended up being JDBC template itself, namely the fetch size. If you do not configure the fetch size explicitly the template will use the driver default, which for Oracle is 10, the database I was working with.

The rows returned from my test query was about 53,000, so with a fetch size of 10 this would take  5,300 network trips to retrieve all the data and store it in memory. Before tuning this operation took about 2.5 minutes to run.

One thing to keep in mind when tuning the fetch size is memory consumption. You should be sure you will have enough memory available to store the result set. For my example I set the fetch size to 10,000 as my result sets were always very large. I was also working with a batch job which ran during off-peak hours, so I knew my available memory would be plentiful.


After setting the fetch size the operation took 15 seconds to run, way better than before. Nice!

Sample code:
On a dao class extending JdbcDaoSupport  I stuck this in an overridden initDao() method.
simpleJdbcTemplate.setFetchSize(1000);

Here is another good post about JDBC fetch size: http://webmoli.com/2009/02/01/jdbc-performance-tuning-with-optimal-fetch-size/

Dust off the old blog

Been a couple months since I have added anything to this blog, I was too busy with work. I have a new job now that is structured a little different, I will have some time to add to this every once in a while, here it goes...