• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown
Bartenders:

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

 
Ranch Hand
Posts: 56
Scala Mac OS X Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
     
    Author
    Posts: 12617
    IntelliJ IDE Ruby
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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).
     
    ranger
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
     
    Ranch Hand
    Posts: 527
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.


     
    author & internet detective
    Posts: 41502
    881
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Ranch Hand
    Posts: 56
    Scala Mac OS X Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Ranch Hand
    Posts: 527
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    ranger
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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

     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic