I would like to support the feature requests made earlier in this thread about [b]deployment versioning and configuration versioning. [/b]
Just as there is a difference in quality between an application server that has manually configurable clustering support (like JBoss) and an application server that has a comprehensive and exhaustive, fixed approach to clustering including admin console support, distribution of deployments etc..(like Glassfish) , just so there is also a difference between being able to simply deploy applications and having a comprehensive builtin solution for "staging".
Content Management Systems provide staging capabilities for reviewing and publishing document based content and application servers should be able to do the same for applications.
There are two further capabilities that pretty much all currently available application servers are lacking and that would make Glassfish V3 stand out. In fact, the following two features are actually something that every Java enterprise developer has been hoping for for years whilst application server vendors have successfully managed to neglect these crucial needs.
1.) [b]Comprehensive application isolation[/b]
It is quite a usual case to have the need to deploy the same application more than once on a single server instance. For example: having a production-version, a validation version, a development version, a test version etc. of the same application available for different user groups. One could expand this list. Think of staging again: key users need to review and test a new application release and grant permission for it to me moved into production. The application would have to be deployed
and wired to mockup backend systems a.s.o.. It is quite awkward to brag to superiors about the sophistication of JEE based technology in constrast to other solutions and then having to admit that 10 different server instances need to be operated in order to host the same application in 10 different setups.
It is easy to deploy different applications to the same server instance but it is virtually impossible to deploy two variations of the same application. On Jboss for instance, one would have to rewrite tons of descriptors in order to have the applications use different JNDI names etc. and in the end, it is still not possible because the JNDI names for Message Driven Beans cannot be customized.
It is an endless game of pain. Meanwhile, PHP developers cannot even begin to understand why such things should be such a problem in the Java world.
2.) To a PHP developer it is incomprehensible why one should have such a heavyweight build-deploy -test cycle in JEE. The company I'm currently working for has a build skript for assembling one JEE application and executing this script takes 10 Minutes. Even if it took only 1 second to deploy a modification, this would still be unacceptable.
Some application servers have come up with lukewarm solutions to half of the zero-deployment time issue, by allowing to deploy JSP files to a directory or having exploded deployment archives, or being able to update a single JSP file into an existing deployment. JBoss came up with a servlet filter that fetches JSP pages from the workspace location. So now, developers even need to customize their applications just to achieve something that should be out-of-the box in the first place.
Furthermore, these solutions most often only work for the web-layer, not for all parts of a JEE application.
Working with Eclipse, the assembly directives for JEE applications are mere configurations made within the IDE. When deploying such an application, the configuration settings are used to physically assemble a deployment unit and then copy the whole shebang to an application server.
At the very least, IDE plugins for Glassfish V3 should be able to support [b]incremental deployments[/b], meaning that the EAR archive built by Eclipse isn fully copied to the server but instead, the contents of the EAR to be deployed and the already deployed one should be compared and only the differing resoures should be transmitted. The server should then update the existing application with the incremental changes.
Additionally, I don't see any point in the current behavior of Eclipse server plugins to build physical EAR archives based on the eclipse configuration instead of using the configuration to just emulate an EAR archive view. This can be done with Eclipse for the latest Tomcat releases but of course only for .war archives and leads to zero build time. This support needs to be extended to all JEE deployment units. This probably requires the server to be based on some sort of virtual file system layer and the Eclipse server plugin to play along and emulate a virtual filesystem for the server mirroring the correct deployment structure of an application that has a different source-level organization.
[Message sent by forum member 'wtff' (wtff)]
http://forums.java.net/jive/thread.jspa?messageID=243394