Thursday, March 13, 2008

A better configuration with Spring MVC

Configuration management  involve  many aspects  on  how the application has to spread in several environments for integration pourpose, QA testing, pre-production, and final production.
Said elements  affect the configuration regarding information systems addresses as database, jndi and sockets and ldap.
Let me  talk about a java project, at a certain point it will be promoted to integration then test environment.
During these stages, problems and suggestions raise up, many enhancements are made and pushed along the delivery chain. As usual it would happen that these recycles increase sharply as the timeline is getting uncomfortably tight. Managing  these releases and synchronizing the environments with the incoming changes is a error prone and time consuming task.
Best pratices suggest continuous integration as the way to manage build artifacts and deliver the applications among different environments. An external tool as would be apache continuum and maven that can deploy, setup, start the application in a completely automatic way, freeing the developers to directly handle this task.
These tools start to work from the source repository which is the ultimate source traceability hub and may say the last word about the state of the project as regarding setups and branches.

Our starting  point is always the central repository, so how to track the setup configuration for different places where the webapp will be deployed?

Suppose we are working on a Spring enabled web application, and you may take advantages  from the dynamic setting up of configuration files  path with the PropertyPlaceholderConfigurer which handle ${system-property} tags and they are filled by the Spring MVC layer.
You may create several sub folder for each config environment, for instance :

WEB-INF/local/applicationContext.xml
WEB-INF/local/log4j.properties
WEB-INF/test/applicationContext.xml
WEB-INF/test/log4j.properties

Now the application context setup is easy,  it simply tells Spring how to find the proper configuration files as the example:
<servlet>
<servlet-name>dispatch</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <init-param>
   <param-name>contextConfigLocation</param-name>
    <param-value>WEB-INF/${environment}/applicationContext.xml</param-value>
  </init-param>
<load-on-startup>1</load-on-startup>
</servlet>
You may also specify in the same way the log4j enviroment-specific configuration:

<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>WEB-INF/${environment}/log4j.properties</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
Afterwards, setup the system variable in your web container adding the "-Denvironment=[local,test]" in the JVM parameter.

Sunday, March 9, 2008

JMX Annotations in Spring

Wow. Over a month without writing anything to this blog. Seems that the days over christmas blocked a lot of time as well as other things that happened around that time. But now i am back with something to share. I really like the new JMX annotations Spring recognizes. In a new project i have to write a small server that should be managed via JMX and i really like springs way of handling it with annotations. In Principle its the same as the transaction annotation. You simple tell spring via:

<bean id=”attributeSource”

        class=”org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource”/>

and a few lines more spring config that you want to export all annotated beans as Mbeans.

Its really interessting to see that more and more of the features around classes like webservices, transactions and now jmx are annotation based. This makes the code much more readable in my oppinion. When i have some more time, i will also convert to define the spring config itself via annotations, but that will be quite a lot of work.

Apart from that, i will leaving for ski vacation in 2 days. Yipeee. I am really looking forward to be 4 days in Austria at the Zillertal valley. With one skipass you can ride more than 600 km trails. Check this if you want to see more. Boy, i like skiing.

Saturday, March 1, 2008

What's new with DWR3 & Spring

With DWR 3 around the corner (the first milestone is available right now) is time to have a look at the new features it brings to the table. In fact, it packs so many, that I'm going to talk just about those related to Spring.
As you know (or should :-), by now DWR has a nice integration with Spring and specially Spring MVC, thanks to the custom namespace it provides. Nonetheless the team has make an effort to improve it. And the results are astounding! Let's review the new features:

  • Remoting beans from a parent (root) context
    Until now, when using <dwr:controller> just the beans in the same context where proxied. From now on, the root context can define candidate beans as well.
  • New defaults
    DWR will offer default names for your controller and remoted beans. In the former case the bean will be called dwrController. In the later, the bean will be available in your client code with the same name as the bean, capitalized. So <bean id="sample" class="..."> will be remoted as Sample.js
  • Explicitly setting an application context
    As of now, the default web application context was always used. The new version allows a developer to set a specific application context in the DWR Spring servlet. DWR will scan this context looking for candidate beans.
  • Namespace support improved
    Release 3 will add the <dwr:url-mapping /> tag. If declared in your XML (along with a <dwr:controller />) all the needed mappings will be automatically created and handled.
  • Configure everything using annotations
    Spring beans annotated with @RemoteProxy and @RemoteMethod will be automatically proxied and available in the browser. To activate this feature a new <dwr:annotation-config /> tag has been developed. Just one caveat, this kind of configuration does not work for advised / scoped proxies for the time being. You have to revert to the common &ltdwr:remote /> and <aop:scoped-proxy /> in that case.
  • Classpath scanning
    DWR will scan the classpath looking for classes annotated with @RemoteProxy and create the bean definitions directly (so you can ommit the @Component annotation). A new <dwr:component-scan/> tag has been created for it. A side note here, the code is not yet available (it's not in the milestone) because it requires Spring 2.5.2+ which has not been publicly released yet.
  • Several other minor changes and bug fixes
    A lot of work behind the scenes. For example, a bean name can now be preceded by a slash so it's automatically mapped.
All in all, a lot of good work. And the best of all, it's just the beginning! Other areas, like file handling or reverse AJAX, pack even more interesting features. I can only recommend that you give it a try today.