lasterra Blog

We have seen how this JSR has contributed great simplicity to the development of Java Enterprise applications. This "copy" of the ancient XDoclet has improved very much for a reason, the code that is generated behind a @JSR-175 is not seen, and therefore it is not possible to modify.

This solves the problem that existed earlier when across @metainformation, we were generating code that often, for one or another reason we modify it, with the inconsistent problems that this could generate in the future when a change come to the project.

We are going to penetrate into the code of the previous example of the Web service, to see that really, a Web service JavaEE5 does not generate any line of code, and it is Glassfish who takes care of it.

In the first image we can see that no generated file exists, not .java, not .class in the whole project.

Although for me the most surprising thing is that neither there exists any type of information relative to the Web service in the descriptor of the application, the file web.xml

The first time that I realized this, surprises me very much, becouse, for example, this conceals the address of the Web Service. I thought then that in the specific descriptor of Glassfish i will find any information, but there wasn't.

I had to go to the console of administration to see the address of the Web service and how, in some internal step, a lot of information had been generated in three configuration files:

This generation of code and configuration will have people in favor and against with. I think it is an advance because it gibe more simplicity, which is very positive. Also I see that although the IDEs help us more and more, in this case is the platform who help us, which is the one that takes care of generating the code. An applause for the JSR-175.