Spring 3 In Action: annotations over descriptor files, is it better?

[Ivano Pagano]

Hi Mr.Walls,
I have a generic consideration to share for everyone to comment, regarding the use of annotation in Spring and which has been in my mind since this new feature was announced.
I remember when the xml configuration was considered a revolutionary change to finally separate application code from the configuration burden.
Now I can see the improvement of a simple annotated method over the "old style config", requiring several lines of code to read parameters or variables.
My perplexity is about wiring the configuration in the codebase once again, meaning that

Compilation and redeploy becomes necessary for configuration updates

I lose the general picture of application architecture available through well-designed file/s organization

The code gets extensively (albeit loosely) coupled to the underling framework

It sounds a bit like a backward step to me in this regard, the more so if I take into account that annotation has been sort of a "buzzword" in the java industry for the last few years, often well-deserved. Can it be a sort of marketing choice, or the consequence of overstated expectations?

Is there some wrong assumption on my part about this? What's your experience and your opinion on this?
Did I read correctly that spring xml configuration will be eventually abandoned?

Thanks to everyone willing to share opinions

Have a nice day

[David Newton]

I still prefer XML configuration for a lot of things (and I *hate* XML, but until there's something like Groovy/JRuby/etc. config, it'll do).

[Mark Spritzler]

The code gets extensively (albeit loosely) coupled to the underling framework

While all the pros and cons to xml and all the pros and cons of Annotations are all very valid. I would disagree with the above statement. In that I need absolutely no framework jars at runtime to have that code run, those Annotations would then be ignored.

I would also assert that the majority of times you do a configuration change, you will also be re-compiling. I have always found that to be the case when I was working with EJBs and Spring.

I definitely prefer the speed of configuration via Annotations over xml, my preference. And I also prefer how I can use my code anywhere regardless of the Annotations that I put in my classes. I would also assert that I find it actually easier to determine how things work in an app with Annotations in the class, so I only open one file, rather than multiple files with .java and .xml files.

Mark

[Anil Vupputuri]

Very nice Pro's and Con's on Annotations. Some people believe XML documents are not the easiest to read or maintain. But I think otherwise, XML docs are self explanatory and only downside I would say with XML is one should refer both XML and Code to find out details about that method or class. For e.g. if method needs to be Transactional it would be nice to put just one line of Annotation on top of that method rather declaring the same in remote XML file.

[Jeanne Boyarsky]

Mark Spritzler wrote:I would also assert that the majority of times you do a configuration change, you will also be re-compiling. I have always found that to be the case when I was working with EJBs and Spring.

This statement really sums things up. In fact, it came up at work today. We were discussing whether X changes. We have never changed X without redeploying the app in EJB; why would we want to now?

I do think there are legitimate scenarios to change just the XML. For example configuring security differently in different environments. But the fact that something is defined as a bean is pretty constant!

[Ivano Pagano]

Mark Spritzler wrote:

The code gets extensively (albeit loosely) coupled to the underling framework

While all the pros and cons to xml and all the pros and cons of Annotations are all very valid. I would disagree with the above statement. In that I need absolutely no framework jars at runtime to have that code run, those Annotations would then be ignored.

Mark

You're right Mark of course, and this is why I used the term loosely coupled. Still I feel uncomfortable filling the code with lots of annotation, even if it's not actually wired through the framework and so not bound to the jars technically speaking. Matter of taste here...

The following could not be so closely related with my previous assertion,
but it still seems to me that writing injection information in the class, prevents the coder from configuring the same bean class with multiple different wirings, or is it possible? The reason I could be asking silly questions is that I didn't document myself deeply on the subject.
Several times we reused the same bean in the same context, injecting different configurations though xml. How can I do this with annotations?

[Anil Vupputuri]

Jeanne Boyarsky wrote:

I do think there are legitimate scenarios to change just the XML. For example configuring security differently in different environments. But the fact that something is defined as a bean is pretty constant!

How do we define security using single set of Annotations (I believe SpEL used here) without needing multiple properties files to reflect specific environmental details?

[Mark Spritzler]

but it still seems to me that writing injection information in the class, prevents the coder from configuring the same bean class with multiple different wirings, or is it possible?

But the wiring is generic, so all I have to do is include only the classes that I want injected. I don't have to change my Annotation configuration if I change out a different implementation.

You can also change your component scan base-package to do the same thing.

Mark