Migrating from Weblogic to Springboot — Part 2
Glad you are continuing to read Migrating from Weblogic to Spring Boot article. This part covers Unnecessary Dependencies, Fat Jar vs Thin Jar and Start-stop sh Best Practices.
If you haven’t finished reading the first part yet, I highly recommend continue to that part firstly. Here is the link:
4. Removing Unnecessary Dependencies
4.1 Apache Maven Dependency Plugin
While developers coding, they usually try or use external libraries. However, sometimes unused libraries’ dependencies can be forgotten in the pom.xml. Separating unused ones from used ones can be burden and the process is open to make mistake if the pom.xml relatively huge. Apache Maven Dependency Plugin is a clever solution to that problem.
4.2 The Dependency plugin has several goals, you can use according to your needs. We are going to stick with analyze goal for this example.
4.3 Add below plugin to your pom.xml inside <plugins> tag. Don’t forget to check out the latest version from https://mvnrepository.com/
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
</plugin>4.4 To show an example, org.unix4j dependency added to the pom.xml but never actually used in any classes. Click to Execute Maven Goal and search for analyze and find the mvn dependency:analyze goal from the list.
Let’s execute this goal.
mvn dependency:analyze
4.2 Plugin found our unused dependency as can be seen below.
4.3 Plugin worked brilliantly for this time but this is not always happens. It can be confused when pom.xml has dependency with runtime scope and it can not analyze those dependencies properly. Runtime scope is not available when you compile your application. But still the plugin expect to see them. Solution might be for this case is updating the plugin definition with <ignoreNonCompile> true parameter in the pom.xml.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<configuration>
<ignoreNonCompile>true</ignoreNonCompile>
</configuration>
</plugin>4.4 An other useful Apache Maven Dependency Plugin is the tree goal. It shows dependency tree of your project. This goal is quite efficient to display dependency conflicts and duplicate jars. IDEs might have equivalent tools to this maven goal. For instance, Eclipse has Dependency Hierarchy which is almost in the same usage.
mvn dependency:tree
4.5 Exclusions
There might be sub-dependencies come with Spring boot dependencies. Excluding unnecessary ones helps to make lighter jars which is more efficient while deploying the product to the cloud systems.
You can exclude particular jar’s from dependencies according to needs.
<dependency>
<groupId>com.furkan.topal</groupId>
<artifactId>exchangeapi</artifactId>
<version>0.0.1</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>Remove unused dependencies to make more lightweight fat jar.
5. Fat Jar vs Thin Jar
There are other jar types other than Fat Jar and Thin Jar as well but in the real world scenarios these two are the ones mostly used. Hence, knowing the distinctions between them and when to use are vital for software development cycle.
5.1 Fat Jar in a nutshell
The use of fat JARs for deploying Java applications became popular alongside the rise of the microservice architecture style, DevOps, and cloud-native technologies, such as public cloud, containers, and orchestration platforms.
5.2 Thin Jar in a nutshell
When having multiple instance application on a machine and these instances use same libraries, using thin JARs might be effective in storage and network bandwidth sense. The lack of shared dependencies (in the fat JARs examples) can also cause inconsistency across the use of utilities such as logging and challenges with integration of communication or serialization across services.
The choice is yours.
6. Start-stop sh Best Practices for Old Schools
If you are still using physical or virtual machine but not cloud, you can continue to read. This part will help you to make happy your operation teams which are used to Weblogic.
Start-stop sh is somehow subtle part of the development but there are best practices about it just like any other part. So, let’s dive right in to it.
6.1 Multiple Instance Example
Below examples cover all types of shs that needed while deploying multiple instance applications.
6.1.1 bootstrap.sh
The bootstrap name is not indicate that we are using an other technology. Actually, it’s a naming convention for this kind of sh. All instances are manageable from here. You can start and stop all or particular shs only by typing two additional keywords.
6.1.2 start-app-web-all
Start all instances.
6.1.3 stop-app-web-all
Stop all instances.
6.1.4 Folder Structure
Each instance have its own configuration file.
As you can see there is a lib file at the above folder path image. It a sign of a thin jar. Each instance uses common libraries from that lib folder.
Details of an instance’s folder can be seen at the below image.
6.1.6 start-app-web.sh
Start an instance.
You might notice we indicate a specific jar name as
…$APPLICATION_HOME/lib/picocontainer-2.13.5.jar.
The reason for that is before getting the all libraries, we indicate a particular version of a jar just in case of library folder contains several version of that. Thus, we prioritize our required version.
6.1.7 stop-app-web.sh
Stop an instance.
To conclude, these subjects were important steps while migrating from Weblogic to Spring Boot for us. They appeared as the outcomes of software development at the corporate environment.
Hope you find it interesting and useful. If you have any comments, questions or just want to discuss, do not hesitate to leave a comment here.
