Mark Spritzler has written the following feature article for TheServerSide.com about the Spring 3.0 @Configuration annotation, describing how its proper use can help limit the size of your Spring configuration file, while making your Spring 3.0 application easier to configure.

How the Spring 3.0 @Configuration Annotation Trounced the Monolithic Spring XML File

---

Mark Spritzler is the owner of Perfect World Programming, LLC. Mark is a trainer and consultant for companies like SpringSource, NTier Training and JBoss. Mark is an expert in Spring, Hibernate and iPhone development. You can contact him through the "contact us" page at  perfectworldprogramming.com.

www.perfectworldprogramming.com
mediaserverblog.wordpress.com

I knew people will soon realize shortcomings of annotation and come up with this solution.

I am confident that what can be done in XML can be done in Java class too, but what I want to see it how better it will be when  trying to move from large enough and production like XML file into Configuration class.

Will it be less complex than XML?

Will it make it easier to configure interceptors, pointcuts and proxies?

Will it support extending and overriding bean definitions, and how easy will it be compared to XML?

Lastly, the example is not a very good one. For example what is the point of @Bean annotation when transaction is directly calling dataSource method?

Maybe Spring will intercept dataSource() method and do additional work, but its not explained in the  article as well as how to add custom logic to interception. Maybe its done in XML?

I think the example was effective as a succinct and 'to the point' example of how the @Bean and @Configuration annotations can be used. We'll leave the discussions about transaction demarcation and the XA specification to another day. I think those topics are significant enough to deserve and article of their own, and we'll see if that can't happen here.

>>Will it be less complex than XML?

In many of the Spring applications I've worked on, it seems that to most of the developers, there is nothing in the world more complicated and convoluted than a large Spring configuration file. And without type checking, far too much time gets spent trying to figure out why programs aren't working.

Cameron, I am asking about the transaction specifics. The questiion was, why we are defining @Bean annotation on dataSource() method since it was not explained in the article or obvious from the example code? We could have declared dataSource as private method.

:)

It's a good question. I'll ping the author and grab his insights.

http://blog.springsource.com/2006/11/28/a-java-configuration-option-for-spring/

Just pointing out that this concept was way...way... in the past.  I guess this article is to show those who have shunned Spring because of XML configuration.

Yes the datasource does not need to be @Bean.  I think this is to show XML-less configuration, so don't dwelve into why he did that.  He's merely showing example of @Configuration and @Bean.

As far as XML vs Annotation, why not use both? I don't quite get why people trying to stay on one side.  This is my philosophy when choosing XML vs Annotation.

XML

Any configuration that is likely to change.  For example, datasource.

Annotation

Any configuration that is least likely to change.

Anyways, I don't think there's any right or wrong way of using it.

XML

Any configuration that is likely to change.  For example, datasource.

 

Annotation

Any configuration that is least likely to change.

 

Anyways, I don't think there's any right or wrong way of using it.

 

Exactly. I just had this issue. I have an update process that sometimes needs to run bulk and other times to run intermittent. For the bulk, i reuse connections. For the intermittent, I use a new connection every time (otherwise i get an error every day).  Sure, i could code something to deal, but it is just not worth the effort. Using XML to do this is much better than code.

As far as XML vs Annotation, why not use both? I don't quite get why people trying to stay on one side.  This is my philosophy when choosing XML vs Annotation.

XML

Any configuration that is likely to change.  For example, datasource.

 

Annotation

Any configuration that is least likely to change.

Very good summary.

I have a feeling that annotations are pushed forward by people who either have XML phobia, or have crappy IDEs. Spring support in IDEA is superb, and I have never had any problems dealing with huge Spring XML descriptors.

To cope with ever-growing context descriptors, we tend to split large Spring XML context files into smaller chunks and then we have a 'bootstrap' context file that imports all the smaller ones.

To me, the main disadvantage of annotations is that they are often equivalent to hard-coding. They are compiled into java classes and you are doomed if you want to change your wirings or configuration after the compilation phase.

XML configuration is external to compiled binaries, it keeps all wirings and configuration in one place, it is still there in the same format in the assembled project, and it can be easily modified in an emergency situation.

Annotations are intrusive, they often create additional compile-time and runtime dependencies, they are scattered all over the place. Once compiled, annotations and java-based configuration cannot be easily viewed without decompilation or tracing back to the original code.

We had a brief foray into annotation-based configuration, but eventually had to revert anything but @PostConstruct/@PreDestroy and Spring-JMX annotations.

As far as XML vs Annotation, why not use both? I don't quite get why people trying to stay on one side.  This is my philosophy when choosing XML vs Annotation.

XML

Any configuration that is likely to change.  For example, datasource.

Annotation

Any configuration that is least likely to change.

Very good summary.

I have a feeling that annotations are pushed forward by people who either have XML phobia, or have crappy IDEs. Spring support in IDEA is superb, and I have never had any problems dealing with huge Spring XML descriptors.

To cope with ever-growing context descriptors, we tend to split large Spring XML context files into smaller chunks and then we have a 'bootstrap' context file that imports all the smaller ones.

To me, the main disadvantage of annotations is that they are often equivalent to hard-coding. They are compiled into java classes and you are doomed if you want to change your wirings or configuration after the compilation phase.

XML configuration is external to compiled binaries, it keeps all wirings and configuration in one place, it is still there in the same format in the assembled project, and it can be easily modified in an emergency situation.

Annotations are intrusive, they often create additional compile-time and runtime dependencies, they are scattered all over the place. Once compiled, annotations and java-based configuration cannot be easily viewed without decompilation or tracing back to the original code.

We had a brief foray into annotation-based configuration, but eventually had to revert anything but @PostConstruct/@PreDestroy and Spring-JMX annotations.

Interesting. Just testing this new comment response screen.

As far as XML vs Annotation, why not use both? I don't quite get why people trying to stay on one side.  This is my philosophy when choosing XML vs Annotation.

XML

 

Any configuration that is likely to change.  For example, datasource.

 

 

 

Annotation

 

Any configuration that is least likely to change.

 

 

 

 

Very good summary.

 

I have a feeling that annotations are pushed forward by people who either have XML phobia, or have crappy IDEs. Spring support in IDEA is superb, and I have never had any problems dealing with huge Spring XML descriptors.

 

To cope with ever-growing context descriptors, we tend to split large Spring XML context files into smaller chunks and then we have a 'bootstrap' context file that imports all the smaller ones.

 

To me, the main disadvantage of annotations is that they are often equivalent to hard-coding. They are compiled into java classes and you are doomed if you want to change your wirings or configuration after the compilation phase.

 

XML configuration is external to compiled binaries, it keeps all wirings and configuration in one place, it is still there in the same format in the assembled project, and it can be easily modified in an emergency situation.

 

Annotations are intrusive, they often create additional compile-time and runtime dependencies, they are scattered all over the place. Once compiled, annotations and java-based configuration cannot be easily viewed without decompilation or tracing back to the original code.

 

We had a brief foray into annotation-based configuration, but eventually had to revert anything but @PostConstruct/@PreDestroy and Spring-JMX annotations.

 

Interesting. Just testing this new comment response screen.

 

I'm not getting something here.  The commment response screen is very awkward.

im so glad about this annotations!thanks!!

vintage celebs

Monolithic Spring XML File are complicated

wny graphic designer