Posts tagged "Spring"

There are many situations when you need to write a SOAP-based webservice. Maybe you are writing a test dummy, or maybe you got the interface from some kind of architect. (Yes, there are other reasons, too.) And chances are you’ll be using Spring-WS to do this.

Recently I was doing that, and I found the following inside the interface definition (WSDL):

<element name="faultMessage" type="common:FaultMessage"/>

<message name="faultMessage">
    <part name="faultMessage" element="tns:faultMessage"/>
</message>

<portType name="someName">
    <operation name="searchOrder">
        <input message="tns:searchOrderRequest"/>
        <output message="tns:searchOrderResponse"/>
        <fault name="faultMessage" message="tns:faultMessage"/>
    </operation>
</portType>

That was a rather challenging thing! In case the operation would fail, it should give a SOAP Fault with a custom element in it:

A few weeks ago, I wrote about migrating an existing Spring-application to Java 9. When I finished, two things remained to be investigated:

1. Code coverage for unit tests.
2. A bunch of warnings when running the application in Tomcat.

Code coverage for unit tests

As Alan Bateman pointed out, upgrading JaCoCo to its latest version should resolve the issue about the $jacocoData field. In fact, I thought I had done that, but somehow I kept on getting the same error every single time. But when I tried (again) last week, it somehow disappeared. No error to be seen, all tests green, and a nice coverage report from JaCoCo. I’m a happy developer, again!

I recently participated in a Twitter conversation about upgrading to Java 9. Like most of the people, my current projects are all on Java 8. Of course the question came up, why don’t you upgrade? Good question! Since I hadn’t even tried, I decided to see how far I could come…

The component I took for my experiment is a pretty simple Spring application. It doesn’t use Spring Boot. It exposes a few REST endpoints, and calls couple of webservices over SOAP. For these webservices, it uses bindings generated by the JAXB plugin for Maven.

It’s been a while since my last post! I recently have been reading a lot about the idea of “API management” or an “API gateway”. There’s a lot of commercial offerings in this field. Many of them promise you (to some extend) ultimate flexibility and endless possibilities. My preference is for “lean and mean” approaches where I can pick the building blocks that I need. In the long run, that offers more flexibility. After all, you could replace building blocks. Having small building blocks makes it less tempting to put any kind of business logic in such a gateway. Doing that must sooner or later lead to some kind of vendor lock-in.