I used to be.. on Tomcat7 - The classloader magic world of a Monolith

 


I know that many of you probably don't use Tomcat for your applications deployment, but as you know there are tons of systems that currently run on this specific Application Server.


Most of the existing Monoliths around the world are deployed on Tomcat (or Weblogic or whatever) where the classloader is - of course - managed by the Application Server itself.


THE PROBLEM


We have this very old application that is working without any problem on Tomcat7. This application has an extensive use of class scanning due to Jaxb implementation that search on every Jar file and create a JaxbContext of known classes.


There was a request from customer to move the application from Tomcat7 to other Tomcat8 or Tomcat9, because the seven is out of standard for the company.


Ehi: there are no problem. There are just fews properties in catalina.properties that we need to copy and "le jeux sont faits", we can easily deploy. And this is was we did but...



Wait....whaaaaaat????? we have the correct ObjectFactory and there are no problems in old tomcat..what the hell is going wrong?


TOO MUCH CLASSES


If we looked at the jar inside the war, we can see more than 100 jar..which is of course not a problem..except for the fact that many of this jars are created by us. And many of this jars have similar packages and similar class names (there are some external services that uses xsd to build java classes..and there are a big problem of naming convention and fantasy..)


So why for Tomcat7 there are no problems, while for Tomcat8 and Tomcat9 it doesn't work? As we said before, Jaxb scans all the jar from classloader, so if you have any problem, usually it is the classloader that is working different.


Another strange thing is that using Docker, Tomcat8 and Tomcat9 works without problem, while using it in the client Virtual Machine, we had the problem.


All of the classes we need to scan are in WEB-INF/lib so - from a pure folder perspective - there is any problem on that: the same classes we had in Tomcat7 now we have in new Tomcats.


But the problem is not about "NoClassDefFoundError", so it is not a problem on which class they are inspecting, but probably the order in which they are inspecting.

And if you see the changelog in Tomcat8 and Tomcat9, they don't load using alphabetical order, they use the order that the O.S. implements.


This is also why the application works on Docker and not in the Client's VM: the O.S. is of course different and probably the Image we used locally, apply an alphabetical order, which bypasses the error.


THE SOLUTION


There is no other way to solve this problem than.. modify Tomcat. As you know Tomcat is open source, so you can download the src and - using Ant - build your own version if you need to modify something.


There are 2 points in the code where lib is scan: StandardRoot on method list and DirResourceRes on listWebAppPaths. We need to force the order here







The highlighted code is the one we added.

So using ant, the entire tomcat is rebuilt under output/build folder.


We changed just classes into catalina, so we just need to change catalina.jar and that's it!


Everything worked perfectly!


CONCLUSION


When we deal with old applications, we face this type of problems, where the order of application will change the behaviour of your code.

There are too much collisions on your class name and this can impact the execution.

This is why we now tend to develop small applications, where the number of jar we will load is very tiny and there will be no problem on classloading. Because this should not be a problem: you application should not depend on the order you load the class.


But hey.. there is always a solution!




Commenti

Posta un commento

Post popolari in questo blog

HTML and AI - A simple request, and a beautiful response for ElasticSearch without Kibana

Immagine
THE PROBEM I recently installed an ElasticSearch in a Docker environment and I want to be sure that it is working, before waiting the consumers start to connect to it. The Container is started using a volume which was cloned from another Docker installation, so it was not empty: we already have some indexes and some documents. I want to be sure that everything was available but I don't have any Kibana installation (and I can't install it at all). So only API was available and I need to check something  ElasticSearch REST APIs THE FIRST SOLUTION If you ask to Microsoft Copilot how to interact with ElasticSearch api, it will reply by suggesting: curl scripting postman But the interaction is not so human readable and it is quite noisy to write the commands. I want to have something to be easily used but I don't want to spend to much time on that. I need an accelerator THE SECOND SOLUTION I know that there is such an api to ask to ElasticSearch the list of indexes. And I also k...
Continua a leggere

A simple CD using AWS Pipeline

Immagine
  CD is a friend in software development: there is no other way to speed up feedback from your application without having a solid Continuous Deployment. I am skipping continuous integration because all of this examples are related to single repo.. where the only developer allowed to commit code it's me: the integration is with my self :) In this example we will create an automation related to a simple situation where we have a LambdaFunction exposed through an ApiGateway, where the lambda function is running a docker image. There are infinite ways of creating and managing Lambda and pipelines of course, but in this example we will use: CodeCommit to store the code ECR to store the code CloudFormation to create and update all the infrastructure. CodeBuild to create the artifacts we need Let's see it CODE COMMIT     To easily have a repository to store the code and to have a natural integration with AWS echosystem, I decided to use Code commit. Code is structured as other e...
Continua a leggere

Websocket Chat with Lambda (but all in Java)

Immagine
  I don't know if I am not able to perform search on Internet (I doubt it) but every examples of websocket chat created with Lambda was all created using Node.js. And I can cheat on Java, that's my love. So I decided to transform the usual chat into a Java project, by of course performing some changes in order to be easy to check if it works.  THE IDEA The idea behind the project is simple: a simple WebSocket API exposed with api gateway with 4 different route and a unique Lambda who is in charge to serve each request. The change I made is about the name registration: instead of just propagate the message to other connected users, I want to have the way to register a name for chat users so every time a message is published, the receiver can see who sent the message. As I said in other project, this is to be intended for testing purpose, so there are really infinite ways to do have the same behavior maybe in a better way. THE PROJECT The entire project is based on cloud formati...
Continua a leggere