Skip to main content

Part 2 - Enhancing the setup

As you can seen modularity has a price. Our application will be divided into multiple Maven projects / modules. Lets say in development I change 2-3 modules, then I need to build each one of them to test. This can be irritating and time wasting. Also I am a lazy developer, I will want to build them as one go. Hence I will now create a multi-module Maven build parent - child. I will just build the parent to build all my childs, including the aggregator ecrm project, which we will essentially deploy.

So we create a maven quick start archetype project. You can turn this into parent project as shown in Listing 1. Also I will refactor the pom in ercm project by moving dependencies and properties to the parent. Similarly view/pom.xml is modified to treat it as a child project.

Listing 1 - parent/pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>ecrm</artifactId>
<packaging>war</packaging>

<name>ecrm</name>
<url>http://maven.apache.org</url>

<!-- ~~~~~~~~~~~~ -->
<!-- DEPENDENCIES -->
<!-- ~~~~~~~~~~~~ -->
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>view</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>

<build>
<finalName>${project.artifactId}</finalName>
</build>

<parent>
<groupId>com.effectivcrm</groupId>
<artifactId>parent</artifactId>
<version>0.0.2</version>
</parent>
</project>

 

Listing 2 - ecrm/pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>ecrm</artifactId>
<packaging>war</packaging>

<name>ecrm</name>
<url>http://maven.apache.org</url>

<!-- ~~~~~~~~~~~~ -->
<!-- DEPENDENCIES -->
<!-- ~~~~~~~~~~~~ -->
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>view</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>

<build>
<finalName>${project.artifactId}</finalName>
</build>

<parent>
<groupId>com.effectivcrm</groupId>
<artifactId>parent</artifactId>
<version>0.0.2</version>
</parent>
</project>

 

Listing 3 - view/pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<artifactId>view</artifactId>
<packaging>jar</packaging>

<name>view</name>
<url>http://maven.apache.org</url>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<dependencies>

</dependencies>

<parent>
<groupId>com.effectivcrm</groupId>
<artifactId>parent</artifactId>
<version>0.0.2</version>
</parent>

</project>

Update - separating the controller

Following on our trail to create modular application, its time to move the controller to a different module / project. Thanks to maven this is very easy we can create another project with quickstart archetype named controller.Now we move the controller Java class to this project under com.effectivcrm.controller package. Also I will tweak the controller/pom.xml to include it as a child project. We also introduce a spring configuration file spring-controller-config.xml to include module specific Spring configuration for the controllers. Since the controller package scanning is moved to the new Spring configuration it has to be removed from the spring-web-config.xml. I will rename that to view/spring-view-config. Last but not the least we need to include the new project as parent module and depdency in ecrm project the aggregator.

Update - fixing the welcome page

Last but not the least we will solve the problem with welcome file and redirect to first / guest page. Unfortunately there is problem with Tomcat (or is this a feature? I do not know). So what I do is I will delete this index.jsp and remove the welcome file entry in web.xml. I will not add an entry in the controller to handle request mapping to / and pass it to the sign in page. The modifided code base is now available in the trunk.

Update - The missing log4j configuration

Well I missed the log4j configuration file. Actually my Tomcat had one so I had no problem. Note that the log4j is not residing inside my war / classpath. I have externalized it to load from a specific location inside Tomcat. This is probably not the world's best log4j.xml. I will progressively enhance it as we move forward to cater to different needs.  I have uploaded the same in the conf folder of svn/trunk.

Update - resources from classpath

I also want the resources to be loaded in a modular way. Hence I moved them to src/main/resources/META-INF/assets folder of view project. Accordingly I have changed the resource configuration in sping-view-config.xml file as shown in the snippet below:

 

<mvc:resources location="classpath:/META-INF/assets/img/" mapping="/assets/img/" />
<mvc:resources location="classpath:/META-INF/assets/css/" mapping="/assets/css/
" />
<mvc:resources location="classpath:/META-INF/assets/js/" mapping="/assets/js/**" />

SVN Location - http://code.google.com/p/spring-modular/source/browse/

Comments

Popular posts from this blog

Why do you need Spring Cloud Config server?

Last month I wrote a primer on concepts around 12 factor app. Before getting into the details of the Spring Cloud Config Server, I must refresh on the principle #3 from the list presented in that post.

3 – ConfigurationStore config in the environments
Configuration information must be separate from the source code. This may seem so obvious, but often we are guilty of leaving critical configuration parameters in the scattered in the code. Instead, applications should have environment specific configuration files. The sensitive information like database password or API key should be stored in these environment configuration files in encrypted format.
 The key takeaways from this postulate for a cloud-native microservices application are:
Do not store configuration as part of the deployable unit (in the case of lead microservice - inside the jar or war if you are still deploying war like the good old days). Instead, store it in an external location and make it easily accessible during run-…

Upgrading Lead Microservice - Use MariaDB and Flyway with Spring Boot

So far I have been using an in-memory H2 database or Mockito for testing the lead microservice. To make the transition towards using the Spring Cloud Config server, I need to upgrade the micro-application to use MariaDB. I will be adding the configuration in the application.yml  the file which in the subsequent post will move over to the config server store. I will also be using Flyway to make it easy to maintain the database schema changes in future. I will use this post to introduce Flyway in the mix. Spring Boot also provides first class integration with Flyway. I am using Flyway as its really quick and easy to get started, minimal learning curve (no DSL) and I am comfortable with it having used it in the past.

Assumptions

MariaDB 10 is installedBasic familiarity with FlywayHeidi SQL client is installed.
Step 1 - Update build.gradle to include the MariaDB JDBC and Flyway dependencies.
Do not forget to do a Gradle refresh on your IDE (I am using STS 3.8.4 on Java 8)

Step 2 - Rename the…

Part 3 - Integrating Tiles, Thymeleaf and Spring MVC 3

In this post I will demonstrate how to integrate Apache Tiles with Thymeleaf. This is very simple. The first step is to include the tiles and thymeleaf-tiles extension dependencies. I will include them in the pom.xml. Note we wil lbe using Tiles 2.2.2Listing 1 - parent/pom.xml --- thymeleaf-tiles and tiles dependencies <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- Tiles -->
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->

<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-core</artifactId>
<version>${tiles.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-template</artifactId>
<version>${tiles.version}</version>
<scope>compile</scope>