Axis 1.4 support for TLSv1.2

The library doesn't understand that out-of-the-box. It will always perform a handshake using TLSv1 instead. This happens even after the initial handshake was done in TLSv1.2 in the rest of the program. adding -Djavax.net.debug=ssl:handshake:verbose reveals that the ClientHello would always successfully be established on v1.2 but the next call would be another ClientHello in v1 afterwards. Neither of -Dhttps-protocols=TLSv1.2 nor -Djdk.tls.client.protocols=TLSv1.2 helped. This helped with getting the debugging to this stage.

The SSL plugin found on Github was one possibility, but I was hoping to find a solution which is more lightweight. Initially, I found this, which hinted at configuring the AxisProperties. The rabbit hole lead me to the suggestion of customising the SecureSocketFactory next. Digging deeper, I finally found the setting that "unlocked" TLSv1.2 for Axis. It was the setEnabledProtocols that mostly did the trick, and allowed me to get a move on.

With the customised SocketFactory, setEnabledProtocols, I could finally run the program as such

<JAVA_HOME>/bin/java -Dhttps.protocols="TLSv1.2" -Djava.security.properties=java.security -jar MyApp.jar

The java.security file was merely a text file containing 2 empty property assignments:

ssl.SocketFactory.provider=
ssl.ServerSocketFactory.provider=

It certainly helps starting off the week in a good way.

Rediscovering outdated quirks in IE11

Welcome to 2019, it had been exactly 2 months since the year started, and finally I'd came across notable oddities.

As detailed in the post here, during the course of my work, it was discovered that while the browser was already Internet Explorer 11 running on Windows 10, the production environment had maintained a compatibility mode view for the legacy application.

Testing the same setup on my own machine turned up interesting bugs before the above was realised. The getElementById was retrieving by the "name" attribute on HTML elements successfully in IE7, but because my own IE11 was not configured this way for the site, the errors started appearing. We'll endeavour to work towards fixing all similar bugs in the application, but for now, leaving it on compatibility view would have to do.

Mysterious Latency

The project was underway and we've started looking into performance tuning. The eG system monitoring tool flagged out webservice transactions lasting more than a few seconds. The application was apparently choking for more than 4 seconds on Java code. But it was not just any chunk of logic. The method being flagged was org.apache.cxf.transport.servlet.AbstractHTTPServlet; which was part of the CXF library. This was not even part of our custom codes.

I'd fired up the Java VisualVM to inspect the thread stack on my local machine. We had a couple of guys help take a look at the latency as well, diving into the log files. We'd pretty much stumbled upon the same issue from different angles.

The framework we're using adopts CXF, which in turn is able to output SOAP requests and responses to the log files. By setting the loggingInInterceptor and/or loggingOutInterceptor, we were debugging the XML content in the staging environment. The "limit" property was set to "-1" for both, in order to log entire payloads. This, of course, did not sit well with the other environment looking at the performance aspects of the system. This logging activity was costing an additional 5 seconds at times, according to the log (ironic, I know). We'd then recommended for the property to be set to "0" instead, so that zero bytes of the payloads will be logged.

Connecting Java VisualVM to WebSphere 8
Referring to this post, I'd added the following JVM arguments into my WebSphere
-Djavax.management.builder.initial= -Dcom.sun.management.jmxremote  -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=1099 -Djava.rmi.server.hostname=MYHOSTNAME

Subsequently following this article that's a bit clearer, I'd then connect via VisualVM to the localhost:1099, which was then able to sample the method calls with indications of self execution times.

Configuring CXF logging
The XML configuration of the CXF interceptors look something like this:
<bean id="loggingInInterceptor" class="org.apache.cxf.interceptor.LoggingInInterceptor" parent="abstractLoggingInterceptor">
    <property name="limit" value="-1"/>
</bean>
<bean id="loggingOutInterceptor" class="org.apache.cxf.interceptor.LoggingOutInterceptor" parent="abstractLoggingInterceptor">
    <property name="limit" value="-1"/>
</bean>
Which goes without saying, that the limits should be set to a value other than "-1" if you don't want/need the SOAP for debugging, especially outside of a development environment.

This is extra important if your XML includes one or more image binaries encoded as Base64 strings.