This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I have never worked on Projects that used Annotations. and I was wondering why EJB3 is based on annotation approach.
I feel that with all services like transaction, security etc.., embedded into the code through annotations, if something has to be changed, we need to update code and look for all dependant methods/code that has to be changed. It would be a maintenance nightmare if there is huge such code which developer has to scan through to make all these changes.
Having Configuration in XML would save sometime to change on file instead of so many files.
Ofcourse regression testing is crucial in both the cases.
What adavantages you see in using Annotation approach?
Use annotation for the defualt values, and then if you need to have something different in your deployment you can create a configuration file that overwrites what is in the annotation.
The plus about annotations is that it keeps that information close to the code where you tend to ask what the transaction level is, when you are looking at the code. Rather than having to go somewhere else to see what it is.
I also find configuration files are getting rampant and then become a maintenance issue.
I think the main advantage of the annotation aproach is, that it avoids redundancy.
The annotation is tightly connected to the class / method / attribute. As such when you refactor an attribute name you cant forget to change the string inside the mapping file, because there is none.
But mostly its a must have to be able to overwrite attributes in xml files, to give deployers the possibility to change minor aspects without the need of recompilation. (Maybe he just wants to change table names)
Search for jibx vs. jaxb discussions. The jibx developers always highlight the possibility to maintain differend mappings. A pure annotation aproach cant do that (i think). The benefit is that its possible to migrate to a new xml file without changing the pojos. This offers the ability to an easier migration path, because the same pojos will be able to handle the old and also the new xml format.
But im not sure if there is need for such an issue concerning ejb, because one cmp will only handle one mapping per deployed instance. So there is no need for the same migration issues (maybe im wrong).