Eclipse debugger out of sync

Recently faced an issue where while debugging a project (Eclipse, WAS Liberty, RHEL 6.5), I faced the common issue of 'Code not in sync' with the break point.
Checked all the usual suspects - Project clean, server restart, even restarted  Eclipse. No use.
Then I checked the Liberty deploy folder. I was using the "Run from Workspace" option in Eclipse/WAS Liberty. In this Liberty will simply create an XML file at WASInstallDIR//usr/servers/defaultServer/apps, with the name of your-project.xml

Checked the file and wallah found it.

I had recently duplicated my dev environment, one for checkins, and one for checking out large changes before actually making them part of source control. During this copy-paste, project-name.xml was also copied along with Liberty. And Surprisingly, even though I added and removed the project from the Liberty Server multiple times, Liberty was still using the old XML and hence pointing to my old project.
Hufff... Hours lost but lessons learned.

Liberty or death

I was working on an application which was working fine on WebSphere server (as war and Eclipse Project). Deploy on Liberty through WAR was also working fine.

Like any other good developer wanted to shift to WAS Liberty for faster development but on trying to deploy on Liberty through Eclipse project, "js, gif, css" files were not getting loaded in the web page. Because of this the page was looking distorted and most of the functionality was lost. For all the mentioned files (js etc) I got 500 (Internal Server Error). There were no console errors and the server log was also clean.

I tried both loose config and 'from workspace' settings + lots of other workarounds but nothing.

Only helpful hint I found was, there were some spring initialization errors in server log. But Spring code was in a jar which was developed by another team so could not debug. 

After weeks of hard work found the issue which was not even a mile close to the problem I was facing. 

Due to wrong code for REST implementation, the base path was set as root application path “/”, instead of something like "/rest/*" . So whenever the first link to the application was getting clicked, REST API classes were getting instantiated before application was fully initialized. And this REST code was making calls to few Spring instantiated beans. But at this point the Spring listeners had not fired, hence the appcontext was empty. Some of the base application object were getting initialized with empty beans and hence spring security context and related classes were failing to serve the application content properly. 

The thing that makes it more irritating is : The same problematic code is working fine on Websphere full profile and Weblogic and even on Liberty if we deploy as WAR. Not sure what classloading difference is causing difference in behavior. I checked the difference between WAS full profile and liberty profile but nothing specific. 

Good thing is, now I am on Liberty, happily coding, looking forward to solve similar irritating issues in lesser time :)

xerces, what a bliss

I firmly believe that you are not a seasoned Java developer until you have  faced an irritating class loading issue.

Recently found myself in xerces hell, trust me its not a good place to be in. Without going into too much details and various issues I faced (internet is filled with them). I will talk about what solved the issues for me:

Background: XercesImpl.jar and xml-apis.jar are both part of Apache xerces and XML4J xml parser library. One of the product I was working on, somehow was shipping with only XercesImpl.jar. Things worked fine until now. (looks like xml-apis.jar delivered classes were getting picked from the JDK. xerces parser jars are part of JDK since version 6 at-least, may be even earlier)

Problem: Suddenly there were errors thrown up related to “XMLGregorianCalendar2 class not found” , “Duration2 class not found”. Looks like these classes are present in the XML4J - xml-apis.jar. As this jar was not packed with the product, hence the error.

Why these error didn't come up previously: Looks like there was no Gregorian calendar related XML parsing happening in the product previously. Due to some change it started and hence the error.

Possible solution (not working): Add xml-apis.jar in the products/web-inf. But on doing so the xml-apis classes started conflicting with the already loaded apis from the JDK. You would see errors like org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be cast to javax.xml.datatype.DatatypeFactory. Don't be too surprised, as both the classes are fully compatible but looks like the problem is classloader. Classes are loaded by different classloader and hence mismatch.

Even if the the application is having “parent last” classloader setting, you will see this error. Also I saw some pages where it said that adding xml-apis.jar to web-inf/lib is not suggested.

Correct solution (at-least which worked for me): Removed the xercesImpl.jar from the web-inf/lib. (classes will get served from the JDK)

In case you are using some ancient version of JDK with no XML parser, there is another safer solution > Keep xercesImpl.jar in web-inf/lib, and keep the xml-apis.jar in appserver/domain/lib directory.

This way the required API classes will not be loaded, even if they are, will not conflict with the JDK classes as these will be loaded in the same classloader as that of JDK.

The only problem I see with this solution is that, keeping the jar in domain lib will be extra manual step, outside of the regular app deployment.

In case you are aware of any better solution then do let me know.

(There is a setting in to Prefer application packages in Weblogic, that might also work, but I I have not tried. Anyways its a app server specific fix and playing too much with application class-loading sequence is not suggested)

Classloading; that simple error was just a beginning

Recently found myself in class-loading issues. Came across two nice tools to analyze the problem.

1. One is generic tool that can be used with any app server and also standalone programs: http://blog.jhades.org/classnotfoundexception-jhades-jar-hell-made-easy/
2. Second is weblogic specific, but good thing is you don't need to add any new jar or listener, its available for any application deployed + it also tells about the possible solution for the conflicts:Classloader Analysis Tool (CAT)

Enjoy .... (putting conflicting jars in the classpath and then solving the issues 1 day before the release *_^)