News: Interview with Mark Hapner on What's New in J2EE 1.4

  1. TheServerSide recently interviewed Mark Hapner, the spec lead for J2EE 1.4. In this Tech Talk, Mark discusses what's new in the upcoming release, technical issues surrounding the platform, and future directions. Some topics he looks at are enhancements to the Connector Architecture, EJB 2.1 MDBs, Web Services APIs such as JAX-RPC, and he also looks at various JSRs that didn't make it into the spec.

    Read Mark Hapner's Interview on What's New in J2EE 1.4
  2. What surprises me in the interview is customer demand for Web Services to do integration. For a little while it seemed like WS's were sputtering, but apparently not. Is anyone doing large amounts of WS for integration? What kind of apps are they connecting to?

    This is good news for all those Web Services vendors.
  3. I'm pleased to see that Mark Hapner sounds very open-minded about how JSR-175 (metadata attributes) may largely replace EJB deployment descriptors. Looking forward to J2EE 1.5...

  4. <rod>
     I'm pleased to see that Mark Hapner sounds very open-minded about how JSR-175 (metadata attributes) may largely replace EJB deployment descriptors. Looking forward to J2EE 1.5...

    Yup. By the way, we are approaching Community Review, so hopefully, everybody will soon be able to take a look at the proposal in its current form and provide feedback. Stay tuned.

  5. Cedric / Rod,

    I though the point of deployment descriptors is to be able to declaratively change the behaviour of a class/EJB without changing the code, thereby reducing the potential of introducing bugs.

    It also allows you to have diffeent deployments for the same bean, something particularly useful in frameworks but also mandatory if you want to deploy your bean to more than app server, app server version, EJB version etc

    XDoclet, ejbgen et all take the approach of placing all of the deployment descriptor information in the implementation class and then generating the descriptors and the home and component interfaces from the added elements in the source code.

    Using this approach how do I deal with multiple deployments?

    Placing deployment info in the code means you have to change the code to change the deployment, which goes against the above principal.

    Are you proopsing that some DD info be moved into attributes/metadata and that some remain in DD's or that DD's disappear altogether?

    What do I do if I want to deploy my bean to multiple application servers and multiple versions of these appliaction servers, multiple EJB versions etc. This is a common environment in companies delivery wrapped software.

    With EJBGen and XDoclet I forsee the descriptor elements in the code completely taking over the source code, completely obscuring the business functionality of the code. Particularly if the imlpementation class is being deployed to many servers, versions and EJB versions.

    Am I barking up the wrong tree with this? Will this metadata approach tackle these issues?
  6. Deployment descriptors[ Go to top ]


    The problem with deployment descriptors in general is that they contain information that is both runtime and deployment, as you correctly noted. I believe that runtime descriptors belong in the source and that deployment descriptors belong in an external file.

    To me, a "runtime descriptor" is a descriptor that is tied to a Java element: class or method (or even field, although this is not applicable to J2EE as of today). Things like transaction attribute, method permission, various class names, etc... are all runtime descriptors and should be specified in the source, near the Java element they refer to. In that particular case, metadata is the perfect vehicle to express this information.

    A "deployment descriptor" is pretty much everything else... JNDI name is an obvious choice, but also information such as client jar or other proprietary settings that span over several EJB's/WAR's, such as create-tables, etc... These settings should not be part of the source. Maybe an XML file, although a properties file is probably equally valid.

    Of course, EJBGen supports both models (you can use variables defined in an external file instead of metadata).

    JSR 175 doesn't address explicitly this issue but it will be trivial to build tools on top of it to obtain this behavior.

    Does this answer your concerns?