One of the remarkable concepts of Enterprise- Java was the separation of roles during deployment: Wiring applications and resources together and configuring and deploying the necessary parts is something totally different from implementing and building an application. That is the real reason, why "XML hell" exists: many settings were made configurable and were not supposed to be hard-coded. Also a typical application hoster and operator would not be (and doesn't have to be) a programmer knowing about "annotations" nor the structure of an EAR or WAR or the JPA subsystem. Hence XML was an appropiate means to do customizing and configuration of an application. Maybe the XML deployment description in EJB2 was overkill, but that doesn't mean at all, that separation of concern is wrong.
Having said this, I wonder, why nowadays I do have difficulties with Glassfish to properly design and perform deployment. I definitively do not want to expand an application archive file, edit config files and "jar" the whole thing together again. This is much too error-prone and long-winded. I just want to supplement the application jar with the additional information needed for the actual operating environment. Rhe EAR should be untouched and capable to be deployed to many sites or customers in an identical form.
So much for the paradigms, here come the 2 practical problems with glassfish with respect to deployment.
1) I couldn't figure out, how I can let the operator/system administrator map a "symbolic datasource name" (given in the jta-data-source section of a JPA persistence.xml packed withing the EAR) to a real one during deployment. In Geronimo, this was possible by putting a section like
<nam:resource-ref>
<nam:ref-name>DataSourcePlaceHolder</nam:ref-name>
<nam:resource-link>jdbc/my_real_datasource</nam:resource-link>
</nam:resource-ref>
into the module section of the application server specific deployment descriptor.
2) I couldn't figure out neither, how to let the operator specify the persistence engine and the engine-specific property settings from outside the WAR or EAR. In Geronimo, this was possible by including a supplementary 'persistence' section (with the same persistence-unit name) into the module section of the application server specific deplyoment descriptor:
<persistence xmlns="
http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="fiss_persistence_unit">...
Which persistence unit to choose (as long as the implementor/supllier sticks to the JPA standard) should not be a property of the delivered application package, but is a pure integration and operation decision.
Does anybody have a clue, how to get over these two deployment obstacles without writing a "deployment-descriptor-in-jar-editor"?
[Message sent by forum member 'frankwhofmann' (frankwhofmann)]
http://forums.java.net/jive/thread.jspa?messageID=344816