Tonari No To To Ro Totoro To To Ro Totoro, Kodomo No Toki Ni Dake Anata Ni Otozureru, Fushigina Deai (Tonari No Totoro - Ghibli Songs)

Spring Framework 3.1 M2 has been released past week. This new release is the last milestone, and next versions will be tagged as RC.

This new version completes the work started in M1, and adds some new functionalities.

To summarize them we can name:

• Configuring Spring Web MVC application without web.xml (post).
• Cache abstraction has been revised.
• A new "packagesToScan" feature for JPA.
• REST support refinements with respect to URI templates.
• And many more refinements.

In current post I will talk about Java-based container configuration approach to setting up a Spring Web MVC application.

As a reference application we are going to migrate Spring MVC Template Project to 100% Java-based container configuration.

If you are using STS, you can create a new Spring project from Spring Template Project wizard:

One of these templates is for creating a Spring Web MVC application. In my STS version, this template creates a XML-based container configuration project.

As you have already noted, important elements of this project are: 

• HomeController that redirects to home.jsp page.
• web.xml file where Spring DispatcherServlet (loading servlet-context.xml) and ContextLoaderListener (loading root-context.xml) are specified.
• root-context.xml defining shared resources visible to all other web components.
• servlet-context.xml defining servlet's request-processing infrastructure, and importing controllers.xml configuration file.
• controllers.xml as its name suggests configures controllers.

What we are going to create is a revision of Spring MVC Template Project that instead of setting up project using XMLs, is configured using Java classes. The new directory structure is:

If you look carefully, under src/main/webapp directory, there are no XML Spring configuration files. And no web.xml, but I will talk about that later. For now imagine that under WEB-INF there is a web.xml file.

See that structure is very similar to previous one, but spring directory is removed and config package is created. Moreover XML files have been converted to  standard classes.

Again ignore strange WebAppInitializer class that has appeared. Let's see applied changes:

root-context.xml has its equivalent with mytld.mycompany.myapp.config.RootContextConfig.

Most important thing in previous class is @Configuration annotation. This annotation indicates that the class can be used by the Spring IoC container as a source of bean definitions.

Class that replaces servlet-context.xml file is:

I am going to show you servlet-context.xml content so you can ensure that XML and Class contain  the same parameters.

Apart from @Configuration annotation, this class is annotated with @EnableWebMvc, which enables @Controller programming model, and @Import for importing other bean definitions, like servlet-context.xml imports controllers.xml. This class extends from WebMvcConfigurerAdapter because some extra configuration is required. WebMvcConfigurerAdapter defines options for customizing or adding to the default Spring MVC configuration. In summary it provides customizing parameters as mvc namespace does. In our case, as servlet-context does, we define static resources path to /resources/, so we only override configureResourceHandling method. If for example we would like to register interceptors, configureInteceptors method should be overridden. And finally @Bean is used for creating the view resolver bean. @Bean methods define instantiation, configuration, and initialization logic for objects to be managed by the Spring IoC container.

Next class is called ControllerConfig and is the responsible of registering controllers. In this case @Bean approach is used because component-scan is not supported directly. Anyway you can use scan method of AnnotationConfigApplicationContext for same purpose but in this case first choice has been chosen.

And finally web.xml must be changed for loading Java-based configuration instead of XML-based ones. In this case contextClass parameter of DispatcherServlet and ContextLoader listener must be changed to AnnotationConfigWebApplicationContext so Spring IoC Container can load beans from configuration classes, and contextConfigLocation must be pointing to configuration classes, and not XML files.

And I suppose you are wondering why in previous directory structure cannot be seen web.xml but WebAppInitializer class. This is explained in my post, and is another new feature of Spring 3.1 M2, that you can configure a Spring Web MVC application with no web.xml.

So if you want a 100% Java-based configuration, simply removes web.xml file and creates the WebAppInitializer class, which looks like:

As you can see, same elements of web.xml are present but they are configured in a programmatic way.

Hope you find the post useful, of course you can create hybrid applications, mixing elements configured in XML way and other ones configured in Java classes.

Two Spring Template Projects are provided, one configuring Spring MVC application in a Java-based fashion and web.xml, and another one 100% Java-based configured.

Spring Template Project with web.xml
Spring Template Project no web.xml

Music: http://www.youtube.com/watch?v=KzLDdof7U8M&feature=related

It's Strange But It's True, I Can't Get Over The Way You Love Me Like You Do, But I Have To Be Sure, When I Walk Out That Door (I Want To Break Free - Queen)

Spring Framework 3.1 M2 has been released past week. This new release is the last milestone, and next versions will be tagged as RC.

This new version completes the work started in M1, and adds new functionalities.

To summarize them we can name:

• Java-based application configuration approach has changed from the @Feature approach in M1 to @Enable* annotations (I will talk about this in next post).
• Cache abstraction has been revised.
• A new "packagesToScan" feature for JPA.
• REST support refinements with respect to URI templates.
• Many more refinements.
  

In current post I will talk about one new feature that will allow us to configure Spring Web MVC application without web.xml.

With Servlet 3.0 specification, web.xml is not required anymore, you can configure your servlets using @WebServlet annotation. Prior to Spring 3.1, DispatcherServlet should be declared and configured in web.xml, so although our application was deployed using Servlet 3.0 specification, web.xml was "a must". With Spring 3.1, things are different. You can use WebApplicationInitializer approach for bootstrapping a Spring web application without web.xml.

First of all let’s take a look at traditional way (using web.xml).

No problem here, if you have developed applications using Spring MVC this file will sound you familiar.

But now let’s use WebApplicationInitializer approach.

Spring 3.1 comes with WebApplicationInitializer interface, that must be implemented in Servlet 3.0 environments in order to configure the ServletContext programmatically - as opposed to (or in conjunction with) the traditional web.xml-based approach.

What we need is a class (can be created in any package, next I will explain why!!!) that will implement WebApplicationInitializer. Our equivalent class to previous web.xml is:

See that same information is required, but is provided programmatically instead of using web.xml. Spring application context must be created by you setting config file/s location, DispatcherServlet is still valid and must be registered too using addServlet method, and of course context-param can be added using setInitParameter method. And only creating this class that implements WebApplicationInitializer, you can remove your web.xml from your application.

Look ma' no web.xml and Spring Web application is still working. And now let me explain why if our class is not configured anywhere and moreover is created in any place (inside classpath), is instantiated and its onStartup method called? Servlet 3.0 ServletContainerInitializer is designed to support code-based configuration of the servlet container at startup phase. Spring people have created SpringServletContainerInitializer class that implements ServletContainerInitializer, and this class will be loaded and instantiated and onStartup method invoked by any Servlet 3.0-compliant container during container startup. This occurs through the JAR Services API ServiceLoader.load(Class) method detecting the spring-web module's META-INF/services/javax.servlet.ServletContainerInitializer service provider configuration file.

Hope you like this new feature.

Note: Servlet 3.0 container is required (for example Tomcat 7), and versions of Tomcat <=7.0.14, root mapping ("/") cannot be used.

Download Code.

Music: http://www.youtube.com/watch?v=Odk3W3qLByI

Y Hay Un Decano También, Y Un Abogado También, Y Un Policía Rodeado De Ladrones (La Taberna del Buda - Café Quijano)

Due to the advent of mobile internet, a variety of devices have connection to the world (mobiles, pads, GPS, netbooks, ...), and these devices could not be as powerful as desktops/notebooks. For this reason, keeping web pages as lightweight as possible is a must. Improving the engineering design of a page or a web application usually is the biggest savings and that should always be a primary strategy. With the right design, some other strategies can be followed. One of these is code minification.

Now-days, jQuery are becoming so popular in client-side of web development. jQuery is a cross-browser Javascript library designed to simplify the client-side scripting of HTML. jQuery itself is composed by "one" file. Thanks of that boom, Javascript is becoming more important when a web interface is developed.

Have you ever opened jQuery Javascript file? Let me tell you what you will see. Nothing human readable, all code occupied only one long line, and variables and methods name are as short as possible:

See this example:

Of course, there is no developer in the world (or at least I wish), that could write this code. So where this code comes from? It is so easy, it comes from a Javascript minifier tool.

The goal of Javascript and CSS minification is always to preserve the operational qualities of the code while reducing its overall byte footprint

There are a lot of tools designed for minifying Javascript files. One of these are YUI Compressor from Yahoo. From its site:

“The YUI Compressor is Javascript/CSS minifier designed to be 100% safe and yield a higher compression ratio than most other tools. Tests on the YUI Library have shown savings of over 20% compared to JSMin (becoming 10% after HTTP compression).”

Because the growth of popularity of jQuery, and HTML 5/CSS3, client-side coding is playing an increasingly important role in web development, and one of these consequences is that in client-side you could need to develop some custom Javascript files, apart from using already developed Javascript libraries like jQuery. And then the question is, if jQuery minify their files, why I cannot do the same with my Javascript/CSS files? And the answer is: “Yes you are right”, and also I say: “We will automatize this process into Maven, so your web project will be packaged with minified scripts”.

Let’s start with a very simple “Hello World” script file:

If you execute manually YUI Compressor as standalone application (java -jar yuicompressor-x.y.z.jar), script is minified to:

output: myscript.js (115b) -> myscript.js (54b)[46%]

Now our script is 46% smaller than the first one, of course the price we are paying is that we are loosing readability, but in production environment makes no sense.

Next step is configuring your pom.xml (Maven) so when application is packaged, all packaged Javascript files are minified. For this porpoise yuicompressor-maven-plugin (http://alchim.sourceforge.net/yuicompressor-maven-plugin/) plugin comes to rescue you.

No secret here, plugin is executed in generate-sources phase, and is configured with no suffix option because I want that “compressed” file has the same name as original one, and also I don’t want any line break in minified file.

And finally the last trick, maven-war-plugin configuration should be changed for avoiding it replaces minified files for original ones.

In this case scripts are in src/main/webapp/script so excluded sources are script/*.js. yuicompression plugin will copy minified files into target directory that will be used by war plugin for building war file. For this reason we should avoid that war plugin also copies the original file to target directory, replacing the good ones (compressed) for the bad ones (uncompressed).

If you read my previous post, where I talked about decreasing download time of Javascript/CSS files(using aggregation) and also I explained why not to use an automatic approach in development time but in running time, I suppose you are wondering why I am explaining in this post minification using Maven? Well let me explain, YUI Compression should be used in conjunction  with aggregation files. YUICompressionplugin supports aggregation too, so if you are developing a public API it is a good approach using YUICompression (using Minifing and aggregation) with Maven. But if you are developing a website, the best approach is applying optimizations at runtime using Jawr API as I explained in my previous post. But next question  is how to use Jawr (by default it uses JSMin) with YUIcompression? The response is easiest one anyone could think, Jawr also supports YUI. Only one line should be added, open jawr.properties and copy next line:

jawr.js.bundle.factory.bundlepostprocessors=YUI

Now Jawr will minify aggregated file using YUI Compression instead of JSMin.

Hope you find post useful.


Music: http://www.youtube.com/watch?v=K_mJ1NgqiSk

I Hitched A Ride With Chris McCandless, I Stepped In The Wild With Chris McCandless, And I Felt Alive With Chris McCandless. I Was Wide Awake In The Dream. (The Ballad of Chris McCandless - Ellis Paul)

Now-days, jQuery are becoming so popular in client-side of web development. jQuery is a cross-browser JavaScript library designed to simplify the client-side scripting of HTML. jQuery itself is composed by "one" file called jquery-x.x.x.min.js. With only one Javascript there is no performance problem. But with jQuery has been appeared some "addons/plugins" that uses this library. An example could be jQueryUI http://jqueryui.com/ but more can be found at http://plugins.jquery.com/. Each of these addons contain their own Javascript file. For example jQueryUI contains apart from jQuery file, jquery-ui-x.x.x.custom.min.js and one CSS file, so in this case in a web page two Javascript and a CSS elements are defined. As more and more extensions are used, more Javascript files are required. And more scripts imply more connections to server, so for example if three Scripts and one CSS are defined, four connections from browser to server are required.

Because of these amounts of connections, downloading time is increased; content negotiation and the fact that normally there will be only two concurrent connections to the same host, produces an overhead that results in a long page loading time. For example, it is faster to serve a 8KB script file than  eight of 1KB.

For speeding up your application, would be desirable that only one Javascript and one CSS were downloaded. Arrived at this point, one can think next approach; using a Maven plugin or any other automatic system, that opens all js files and concatenate all of them in a single file. This approach is valid, but has a major problem, any small change forces developer to re-run build script before changes can be tested. Also you are duplicating same information in two or more files, so you must take care assuring consistency between them. 

The goal for Jawr is to provide a system to easily map resources to bundles using a simple descriptor, and a tag library to import these bundles to JSP pages.

In summary, using Jawr taglib you define a fictional Javascript file (for example widgets.js) in JSP; this file does not exist physically anywhere. Then in Jawr configuration file (jawr.properties), you map which Javascript files should be appended when client browser requests "unreal" Javascript file (widgets.js). So from developers' point of view you could have a hierarchy of several js files, while from client-side (browser), only one file is sent.

Using Jawr in only Servlet based web applications are easy. Jawr comes with a Servlet net.jawr.web.servlet.JawrServlet, where you define Jawr configuration file, and a workable mapping for js extensions. (http://jawr.java.net/docs/servlet.html).

But in case of Spring MVC web applications, things are bit complicated. Jawr provides a Spring controller, that acts the same manner as previous Servlet, but instead of using servlet-mapping tag you must create a SimpleUrlHandlerMapping.

In this post I will explain you how to create a Spring MVC jQuery web application integrated with Jawr. Let's start with a Spring MVC application that does not contain any references to Jawr.

JSP page contains definitions for all elements required by jQuery plus one custom script file (defining a() function).

and in servlet-context.xml static resources (Scripts and CSS) mapped correctly.

This web application contains four references to static resources, so load diagram looks like:

As you can see there is no file aggregation. With Jawr these four connections can be reduced to two, one for all Javascript files and another one for CSS.

Let's start mapping resources. This is specified in jawr.properties file that should be present in root classpath:

First line enables the ability to serve gzipped resources to browsers that support it. Next two lines are required for mapping script files. jawr.js.bundle.[bundleName].id is the property where you specify the name of fictional Javascript file. This name will be the one used in JSP. The other line jawr.js.bundle.[bundleName].mappings is where you indicate all Javascript files that should be appended when jawr.js.bundle.[bundleName].id file is requested by browser. In previous example when your JSP page is requesting /script/all.js resource, Jawr will join a.js, jquery-1.5.1.min.js and jquery-ui-1.8.13.custom.min.js and sent back the result to client-browser. Last lines are the same but for CSS files.

Next step is changing JSP, so instead of having one reference for each file, only contains one reference to jawr.js.bundle.all.id value.

Jawr provides a tag library used to generate tags that import bundles to clients and these tags are <jawr:script/> and <jawr:style/>.

Unlike Servlet approach, web.xml don't have to be modified, Jawr provides a Spring controller that must be configured as you would do in Servlet approach.

Next step is configuring Spring Controller. Jawr site provides documentation about how to configure a Spring MVC with Jawr. The example provided uses old-school fashion configuration controllers using SimpleUrlHandlerMapping. But because I always use annotated controllers and I don't want to have some controllers defined with annotations and other ones in UrlMapping, in this post Jawr Spring Controller has been extended for being used with annotations.

For implementing Jawr Spring Controller with annotations I have only created an aggregation between annotated controller and Jawr controller. So class looks:

and the same approach for CSS is used but changing RequestMapping to /**/*.css and Qualifier to jawrCSSController.

As you probably noticed, two Jawr controllers are used, one for Javascript and another for CSS. This is because Jawr requires that you specify if code to optimize is Script or StyleSheet. Spring configuration looks:

Finally <resources> tag from servlet-context.xml should be changed to:

<resources mapping="/css/images/**" location="/css/images/" />

because now only images are required to be served as static resources.

With previous changes applied, load diagram looks like:

See that only one connection for all Javascript files are performed. And also see how downloaded time has been improved from first version. Times showed here are not calculated in a scientific way, they are calculated from localhost, but if you compare previous diagram with this diagram, you can see an improvement.

You can also speed up even more your response time using a cache strategy, but this topic is out of scope of this document.

I wish you have found this post useful, and now before using jQuery scripts, prepare your environment with Jawr so your application can be loaded even faster.

I hope you find this post useful.

Download Code.

Music: http://www.youtube.com/watch?v=3tdQx4Y3I2c