Configuring Spring MVC

tl;dr The process of configuring Spring MVC involves configuring the DispatcherServler as a front controller in the web.xml and configuring the Spring context file where Spring MVC specific beans like Controllers, Handler mappings, View resolvers, Locale resolver and Theme resolver can be wired.

This post is about how to configure Spring MVC. It is part of the Configuring Spring Series.

Spring MVC allows you to put the Spring framework at the fore front of your web layer. As you probably know, it is possible to use Spring in a web application without Spring MVC. As mentioned in Configuring Beans In Spring Framework, you can use WebApplicationContextUtils to bring in the Spring context into your web application. In that scenario, Spring is not responsible for the whole Web layer, it just plays its part, mostly as a DI container. But with Spring MVC, Spring framework is put at a central and integral part of your web layer.

Dependencies

I would be using Maven for dependency management. To get Spring MVC, certain required artifacts needs to be added to your project. To get these dependencies with Maven, your pom.xml file may look thus:

Configuring Hibernate JPA in Spring Framework

tl;dr To configure JPA in Spring via Hibernate, you wire up one of the classes provided by Spring that creates a bean of type EntityManagerFactory which then makes EntityManager available for you. There are two types of Entity Managers, and the class you wire up depends on which Entity Manager factory you would be using. We have Application Managed and Container Managed Entity Managers.

This post gives an overview of how to configure Hibernate as a JPA implantation, for use in a Spring application. It is part of the Configuring Spring Series.


In Configuring Hibernate in Spring Framework, we saw that in other to talk to the database via Hibernate, your application code would do so via Spring's implementation of Hibernate's main interface: org.hibernate.Session which is made available via an implementation of  org.hibernate.SessionFactory. And the process of configuration is just a process of wiring up Spring's to provide this needed SessionFactory as a bean.

You have a similar procedure when it comes to configuring Hibernate JPA in Spring. 

Instead of working with a SessionFactory, you work with EntityManagerFactory. And instead of Hibernates' Session you have EntityManager  through which the actual database access is done.

The process of configuring Hibernate JPA in Spring hence, is all about wiring the Spring bean that would make available for you the EntityManagerFactory.

Before we get to the business of actual configuration, let's get some key concept's explained.

Structure, Work flow, Design

They say it's good to have separation of concern, and I agree, but I would suggest that PHP's nature which easily allows the muddling of logic across layers of application creates a more fluid workflow (in the short term) that leads to more fluidity and better aesthetic looking creations; while with languages like Java; what you mostly get, (unless you put extra effort not to), are designs that feels more like they were constructed instead of inspired. With things looking all so structured and "boxy".

Is That A Reg Flag?

I am adopting a slightly different meaning to the phrase "red flags"; which in colloquial usage refers to a warning signal or something that demands attention. Although my modified meaning also can be seen as a warning signal; the new meaning I am ascribing to the phrase is based off the Red Flag Traffic Laws

The Red Flag Traffic Laws were laws in the United Kingdom and the United States enacted in the late 19th century, requiring drivers of early automobiles to take certain safety precautions, including waving a red flag in front of the vehicle as a warning.

The law as defined from Wikipedia. Emphasis mine.

An interesting part of the enactment:

  ...[a person] shall carry a red flag constantly displayed, and shall warn the riders and drivers of horses of the approach of such locomotives, and shall signal the driver thereof when it shall be necessary to stop, and shall assist horses, and carriages drawn by horses, passing the same.

To people of today's world; this policy definitely sounds absurd and backwards. But at the time it was put in place, it was done so as to address a real concern; safety to others in a world where self propelled locomotive is about to become more common...

But the absurdity of it is not my primary concern but the limitation the policy would have placed on the expression of a new technology. For one, having someone always in front of the locomotive means that the locomotive theoretically is not allowed to move faster than a particular speed. A big advantage of having a self propelled locomotive is then lost! Why have a car when you can only drive at a much slow pace?

And this is where my new internal usage of Red Flags takes it meaning. It expresses propositions, way of thoughts, policies that stifles the expression of innovation not with the intention of doing so but as a result of taking actions that intends to protect a valid concern.

And some characteristics of these kind of thinking; "these Red flags" can easily be spotted by taking a look at some of the characteristics of the Red Flag Traffic Law itself:

1. The law was put in place in good faith. The intention was not to stifle expression of an emerging technology; but to protect the populace. But the outcome, invariably  limited the expression of a new technology
2. The law was focusing on established way of life instead of embracing and exploiting a new way.
3. Although the concern expressed by the law is valid; it tried addressing these concerns from the same paradigm level.

Making sure all self propelled locomotive have a hoot would have been a solution that sufficed. This is how addressing the concern from a different (or higher) paradigm would have largely addressed the concern without having to put an artificial limitation on the workings of the self propelled locomotive.

So when we are confronted with any new concepts; innovations or technologies that has the potential of disrupting the safety of well established way of doing things and we have a strong urge to put things in place that would address these concerns; we need to be aware that our actions might lead us to just be enacting our own versions of the Red Flag Traffic law. We don't want to do that.

In Software, You Build To Change Too

There are moments when differently considering how a domain is captured and expressed leads to an epiphany of sort: A much clearer insight into the matter at hand.

It could be a slight or simple change of point of consideration, but the insight it leads to, could be quite profound.

The Earth moved. A simple change in the way the solar system is viewed but a change that led to a significant upheaval of not just how we understand the cosmos; but a change that also rattled the political and power structures at that time.

I recently had a similar change with regards to how I internally conceptualize Software Development (or construction) and Software Architecture. Not surprisingly, my internal modelling has largely been shaped by the type of architecture that I am most exposed to: which is the civil type: how buildings are made, roads, bridges etc. And in these domains, the primary concern is building to last. The success of the architecture of a bridge is judged on how long it can last without fail. Same goes for high rise buildings. Building to change is not primary in these domain. 

This view has been projected onto how I primarily perceive Software Architecture. A great Software Architecture is the one that creates software that can always keep performing no matter what. This is the building to last metaphor.

But just as building to last applies to software; building to change is (should) also be core too. In fact; how well a software facilitate easy change would determine how long it may last.

Software is meant to mutate, by its very nature, with time. And a good software architecture is one that enables for easy change to the system while ensuring the system continues to provides its utility.

So when approaching a software creation process; keep in mind that building to change is as much important as building to last and let this fashion the architectural decisions you make.

Configuring Hibernate in Spring Framework.

tl;dr to configure Hibernate in Spring, you need to configure a bean that implements org.hibernate.SessionFactory. Configuring this bean involves specifying the data source, the Object-to-Database mapping (if you using xml for the mapping) and the hibernate properties.

Last post in the Configuring Spring series looked into how to configure data sources, a basic requirement, regardless of the actual method in which your application would communicate with the database server: either via plain JDBC or via an ORM tool.

This post would look into how to configure Spring to use Hibernate. Hibernate is an object-relational mapping library for the Java language, that provides a framework for mapping an object-oriented domain model to a traditional relational database.

In how to configure data sources in Spring, we saw how the data source is the entry point to having your application communicate with a database server; how it is configured and retrieved for use in your application by classes that are specifically created to handle interaction with the database (DAO classes)

In configuring hibernate to work with Spring Framework, the data source still remains the primary entry point, but it would not be what your application code (or DAO class if you go with this pattern) would have to use directly in other to communicate with the database. With Hibernate, your application code requires something called the SessionFactory

So the process of configuring Spring to work with Hibernate is basically then all about configuration the bean that would make the SessionFactory available for you.

Configuring Data Sources in Spring Framework

This is the second post in the configuring Spring series. It kickstarts the database centric configurations required when building an application that persist data with Spring framework. This post talks about configuring data sources.

There are various ways to enable the ability to persist data in your application. From using any of the available Implementation of Java Database Connectivity (commonly referred to as JDBC) to going the ORM route via any of the popular ORM frameworks (Hibernate, MyBatis, Eclipse Link etc )

But with any of the above mentioned method, a data source is always a requirement; because...well you need to have a source to the data if you want to persist and/or retrieve data. And in Spring the data source ends up as a Bean that you would configure.

Spring provides several options of configuring the data source. You can have:

1. Data sources that are provided via JNDI.
2. Data sources that work with JDBC drive.
3. Data sources that are from a connection pool.

But before we go ahead to look at configuration proper, it would be useful to quickly define some basic concepts you would encounter when dealing with persistency: