This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara 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).