Spring Introduce Environment Profile

Spring 3.1 introduce notion of an Environment. This abstraction of profiles has been integrated throughout the container. As always, spring community trying to help developer by introducing this very useful concepts, I do think this will be very useful for application and will definitely reduce project timeline. Application now can easily switch between profiles. Like environment-specific bean definitions, like the need to register certain bean definitions in certain contexts, while not in others. You could say that you want to register a certain profile of bean definitions in situation A, and a different profile in situation B. it's important factor to understand that the Environment contains information about which profiles (if any) are currently active. When the Spring ApplicationContext above is loading our three bean definition files, it pays close attention to the attribute in each of them. If it is present and set to the name of a profile that is not currently active, the entire file is skipped — no bean definitions are parsed or registered. You would use same way to load ApplicationContext – spring container, which will activate your profile. 

Play Safe - I would still play safe and use this only when it’s necessary to do this, like you only changing some bean values. You can use this if sets of beans are similar between dev or production. 

What's new in Spring 3.1 - Part II

As you can see from my previous post, that I love talking about Spring Framework and recently in Spring 2GX, they have announced how Spring 3.1 will lay out. It surely looking promising as Spring team puts lots of thought behind each Spring framework milestone. Here are most of the features that you are going to see in Spring 3.1 world.

Scheduler Enhancement - you can schedule cron job to call from java bean, similar to timer bean..

Improve and support JEE6 - Continue to provide more feature enhancement for JEE6

Environment profiles for bean- I think this will be widlt used as this allow to have a profile for different environment, like development, test and production. In other words grouping bean definition for activation in specific environments.

Java based application configuration- I think this will help developers who does not want to deal with XML configuration and want to configure using annotation in java class.

@Configuration

Public class applicationConfiguration

{

@AutoWired

private DataSource ds;

@bean

public OrderDetail OrderDetail(){

return new OrderDetailImpl(ds);

....

}

}

Cache Abstraction- provide support for distributed caching that is specially useful for caching solution in cloud . Also will have common adopter for cache solution provider like EHCache. they have support for convenient caching annotation "@Cacheable", they have cache manager API for EHCacheCacheManager, GemFireCacheManager

Conversation Management - provide abstraction for conversational sessions, you should be able to identify conversational state by may be passing around ID for conversational states, I think you might be able to externalize session information and use as distributed caching. Also this theme will provide foundation for Web Flow 3.0

Servlet 3.0, JSF 2.0, Groovy - Automatic deployment of framework listeners. which I think might have drawback as you don't want to deploy everything (as you might be using all ths listeners), they will have support for JSF2.0 and will have more support. They might have template classes for Groovy support.

What's new in Spring 3.1?

With all of the good stuff in Spring 3.0, it's hard to imagine what could possibly follow in Spring 3.1.

I just got this news from Spring2GX event side that they are introducing a number of often-requested configuration features. Need a standalone datasource in dev, but one from JNDI in production? Environment-Specific Bean Definitions are a first-class approach to solving this very common kind of problem. Love code-based configuration, but need the power and concision of Spring XML namespaces?

I'm guessing they will have support or integration for other languages like Scala, Groovy etc....well this event is one week away and will update more as i get more info about this...

Just to see what we have so far from spring, here are some points from Spring 3.0 enhancements

Full-scale REST support in Spring MVC, including Spring MVC controllers that respond to REST-style URLs with XML, JSON, RSS, or any other appropriate response. We'll look into Spring 3's new REST support in chapter 12.

A new expression language that brings Spring dependency injection to a new level by enabling injection of values from a variety of sources, including other beans and system properties. We'll dig into Spring's expression language in the next chapter.

New annotations for Spring MVC, including @CookieValue and @RequestHeader, to pull values from cookies and request headers, respectively. We'll see how to use these annotations as we look at Spring MVC in chapter 7.

A new XML namespace for easing configuration of Spring MVC.

Support for declarative validation with JSR-303 (Bean Validation) annotations.

Support for the new JSR-330 dependency injection specification.

Annotation-oriented declaration of asynchronous and scheduled methods.

A new annotation-based configuration model that allows for nearly XML-free Spring configuration. We'll see this new configuration style in the next chapter.

The Object-to-XML (OXM) mapping functionality from the Spring Web Services project has been moved into the core Spring Framework.

Spring RestTemplate

Its hard to say anything about spring without seeming biased in favor. Spring's RestTemplate is as solid as can be expected. Their standard call back based approach for safe release of resources works well even for the REST template. If one is using Spring-mvc and their REST support, very few reasons would drive me to consider an alternative framework for the client. One among them is definitely finer grained control, another is Http Client 4.X support. Documentation is sparse on RestTemplate as well. But one has a community to back up on. There might a bit of up front customizations, standard call back etc that an adopter might create but once done I feel that it would be a easy to work with the RestTemplate.
Clearly one has many choices in selecting a client side framework for RESTful HTTP. In most cases it probably makes sense to use the same framework for the service and client end. Then again, if you are only a consumer of a service you have multiple choices among those shown above as well as the option of using Apache HTTP Client or Components directly and bypassing the higher level frameworks. For some, integrating with the spring framework is important and all the above frameworks have means of integration points, both on the service and client sides. Support for Client Proxies is something one might want to consider as they tend to simplify the programming model. Further if Resource definitions can be shared among client server, that can be quite useful in being DRY (Don't repeat yourself) and provide means for contract definition. For those interested in performance and tuning of the HTTP Connections, using a framework that allows you to manage connection pooling and other parameters is definitely the way to go.

For more information on Spring RestTemplate, visit Spring blog

Spring RestTemplate Example: