Parent ClassLoader Last on WebLogic

There were some requirements recently to convert some source files from WebSphere to WebLogic as the deployment target. I'm not particuarly familiar with WebLogic as the projects I've been involved in, largely employs WebSphere. Some hijinks ensued and I'd reached a familiar problem regarding NoClassDefFoundError.

My first lead pointed me to this question, where a helpful answer gave some insight to how WebLogic works. The solution was to add a <prefer-web-inf-classes> XML configuration. My assessment at this stage was that this issue seems similar to how WebSphere deals with the ClassLoader problem, where in certain cases, priority needs to be given to files found in the application, due to identically named classes.

Option to set the ClassLoader policy from within WebSphere Admin Console

I proceeded to try and find out if there was a configuration option to set this from within the WebLogic admin console. There was not. A second link seemed to corroborate this finding. And then I found the official documentation. The only was to set this up was via an XML entry from the weblogic.xml file as part of the deployed application:

<weblogic-web-app>
  <container-descriptor>
    <prefer-web-inf-classes>true</prefer-web-inf-classes>
  </container-descriptor>
</weblogic-web-app>

This wasn't a convenient fix, but it was a solution after all. Albeit it certainly would have been helpful, had this been made available from the admin console.

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.