• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Xml based configration Vs Annotation

 
Ranch Hand
Posts: 162
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Xml based configuration Vs Annotation


Which is the best for J2ee applications configurations

with respect to maintainable ,performance ,reusability of enterprise applications ?

any pointer appreciated.

Thanks in advance.
 
Ranch Hand
Posts: 413
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
xml Annotation
maintainability High Low

All others same
 
Kuladip Yadav
Ranch Hand
Posts: 162
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chaminda Amarasinghe:
xml Annotation
maintainability High Low

All others same



If you want to develop large scale enterprise application,
Which will you pick up ?
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
XML-based configuration files are the better choice for large systems. Annotations are short-cuts appropriate for small projects. Having meta-data coded in source code files is a problem. Hard-coding any meta-data that is used to govern the application has always been bad.

Having to recompile a bunch of classes over and over again takes time and money and requires testing. Unacceptable for any enterprise system of value, in my opinion.

Using annotations for Jim's Cardboard marketing website (20 visitors per month) might make sense. Systems with clusters of web and application servers and EIS should be declaratively configured.
 
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
maintainable
- there are advantages on using annotations, on the developer point of view. the parameters that change often should be put on xml.


performance
- no impact to this.


reusability
- just like maintainability, there are advantages on using annotations, on the developer point of view. the parameters that change often should be put on xml.
 
Author
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the point is being missed here. Because many people miss this point, we end up with piles of amorphous XML instead of leveraging the type safety of our language. In short, we end up with something like Spring (good for APIs, bad for XML).

So what is this missing point? The point is, XML is no less code than Java is. Sure, XML doesn't have to be compiled, but it does have to be packaged. If you are repackaging the application, it's hardly even noticable if you happen to be compiling at the same time. Hard-coded means in the application, not necessarily in the Java code. This whole big system argument is simply wrong.

But let me pause before a cause a flame war. I cannot tell you how to design your system because, after all, it's your system. But, I want to give you some advice. If you fear having to recompile, then you need to recognize that what you are dealing with is configuration, not code. Configuration belongs in the database (or some data store) where you can slap an administrative interface on it, give it to tech support, and make them feel empowered. If what you are dealing with is code, then you want it to be in Java where you can leverage the type safety. This is one of the primary themes of Web Beans.

Granted, this is an age old debate and I'm not necessarily right. And Seam doesn't force your hand. Use annotations. Use XML. Either one will get you to your goal.

One point about annotations before I close. Annotations will impact performance if you read them at runtime. The call to isAnnotationPresent() on Class is a synchronized method. Thus, you introduce a bottleneck into your system by invoking it. Do all of your annotation scanning at initialization and cache the information for later use, like Seam.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Big systems are typically designed by highly skilled engineers that move on to other projects within the organization. Or, systems are designed by consulting companies and delivered to clients that did not have the resources to build the system. The point here is that configuration files and deployment operations can be handled by operations staff. The workload of highly-skilled engineers and operations staff is different. It is more efficient, safer and cost effective to enable operations staff to change configuration data rather than to require someone to be on call to touch actual class source code.

Modifying a value in an XML-based file and going into source to change a value are different operations. Moreover, the tasks of recompiling source code and creating a new EAR or WAR file are different. "Hard-coded" traditionally means something coded in the source. Data in an XML-file is not hard-coded. If you want to start redefining industry terms, feel free.

Again, Joe's marketing site with a total of 10 classes and an enterprise system with multiple testing and development environments and hundreds of classes and multiple modules are not the same.

There are good ways to design a system using XML-based configuration and their are bad ways. How something is designed and the underlying principle of declarative programming are not the same.

Annotations are "developer" short-cuts for small applications that the "developer" will continue to manage over time. Designing with annotations for large-scale enterprise systems is questionable.
[ August 08, 2008: Message edited by: James Clark ]
 
Dan Allen
Author
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Annotations are "developer" short-cuts for small applications that the "developer" will continue to manage over time. Designing with annotations for large-scale enterprise systems is questionable.



I completely disagree. Annotations are not just developer short-cuts. It's true that you need XML for certain things, such as database connection information and JNDI names. That makes perfect sense. Those are things your operations staff could and should be changing. Your operations staff should not be changing things like transaction boundaries. In those cases, you need the expertise of the engineers or else you risk screwing up the system. Annotations fit. Bijection annotations are another great example. There is no way an operations staff should touch one of those. If they do, they should probably be yelled at. Annotations are not just a toy! Read the Web Beans spec for an even clearer picture.

We can agree on, and drink together to, the fact that anything that an operations staff can reasonably change should probably be in XML or, better yet, in Java properties files. I wouldn't give my operations staff an XML document because, frankly, its too complex looking for them (but that depends on the circumstance).
 
Dan Allen
Author
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would furthur argue that it is far clearer for a new developer to find code-oriented metadata (transactions, bijection, security, etc) in annotations than it is for them to go digging through (or drowning in) thousands of lines of XML and trying to mentally make the coorelation. A Spring configuration file just gets out of hand over 100 lines. How can that be good for a big system?

Again, we can find a common ground. I wouldn't throw out XML, but you cannot reasonably throw out annotations, I don't think.
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:
Modifying a value in an XML-based file and going into source to change a value are different operations. Moreover, the tasks of recompiling source code and creating a new EAR or WAR file are different. "Hard-coded" traditionally means something coded in the source. Data in an XML-file is not hard-coded. If you want to start redefining industry terms, feel free.



The point you're missing here is that there are different types of configuration - initialization parameters, and component dependencies. You must be coming from heavy Spring use, as these two - completely distinct! - types tend to be mixed up in Spring, being indiscriminately dropped into one (or multiple) XML config files.

No one advocated putting initialization parameters (DB connection properties, LDAP URLs etc.) into code. No sane developer would do this, and Seam-using ones are not an exception here. There's either XML or property files for this, and that's how I personally do this type of configuration in my Seam projects. Thus, the point of "changing a value in XML vs in code" is completely wrong.

When we're talking component relationships (e.g., Actions -> Services -> DAOs), this is a completely different beast, and it's best not to mix it up with the former case. This kind of configuration is relatively static, defined mostly at the system design level, and doesn't change much (if at all) after the system is delivered. Even when it does, the fact that a component suddenly starts to depend on a different set of components, usually means a serious system redesign, and a recompilation in this case is warranted and even welcome (not to mention that typical clients hardly ever do this type of configuration).

Upd: Dan has addressed these points even better while I was typing
[ August 08, 2008: Message edited by: Alex Savitsky ]
 
Chaminda Amarasinghe
Ranch Hand
Posts: 413
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I totally agree with Alex Savitsky

But I have a little doubt with xml configuration or property file.

In my cause we allways push a package file (eg, war, jar, sar) to the production. So having the configurations inside the packaged file again not maintainable.

I like to know is there any other approach to overcome this issue.

Thanks
 
Dan Allen
Author
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alex, thanks for the clarification. I think collectively we established the correct balance.

Chaminda, the very best way to "abstract" configuration out of your packaged archives is to put the resources in JNDI, which has been available in Java EE (and J2EE before that) from the start. Granted, it has pretty much sucked from a client perspective even until today because the names are not standardized. Seam and Spring both try to ease the pain by offering connectors or lookup agents. Java EE 6 is finally going to adopt some sort of sane standard (hopefully!).

On the other hand, if you have a client that likes to change a setting in the application daily, then you should put whatever setting that is in a database and create an editor for it. No lie, I was on a project where we deployed every night to push out "code changes". It took me a while to convince them that these were changes to user settings.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Again, we can find a common ground. I wouldn't throw out XML, but you cannot reasonably throw out annotations, I don't think



Good point.
 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know if is right to revive this thread or create a new one, but, what about performance when your use annotations vs when you use xml ? I read in another pages that using annotations have an impact in performance because the runtime has to check the classes looking for annotations.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
XML-based files need to be parsed and then read. Both of these activities effect performance. Unless there is a drastic difference between one or the other in regards to impact on application performance, it is not a big deal.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic