There are a number of enchancements that would make glassfish into an even more competent app server, able to cater to the larger enterprise deployment. Here is a non exclusive list and I'm happy to take this discussion further if you'd like.
* Versioned application deployment - There can be multiple levels of sophistication with-regards to this. The basic idea is that application deployments will handled a little more as a source control system which will enable rollback to a previous version if needed
* Versioned application configuration - Right now the configuration changes are kept in a single file so there is no way to go back to a "last known good" configuration. Also when doing configuration changes they should be able to be grouped into a "changeset" which is the unit of configurauiton which will be applied and rolled-back
* Transactional aware cache - There are two uses of a distributed cache. As a second level cache for a persistence provider like Toplink esstentials and Hibernate, but also as a free-standing service. For both of these uses it should be possible to configure the cache to be transactional so that cache updates will be updated and commited in the same transaction as the operation in the app server. Otherwise we risk using invalid cached data and if we cannot rely on the cache we need to hit the database anyways which is what we wanted to avoid in the first place
* Synchronous state replication should be possible and easy - In concert with the transactional cache bullet, this is a partial solution, not guaranteeing full transactional semantics for cache updates, it still synchronous so that there is less risk of cached data losses
* Pluggable app server services, e.g. persistence providers
* Content sensitive call tracing filter function - The call tracing functionality can today filter on users, but this is quite corse level. For solutions where the user is another server which generates high-load in itself it becomes impossible to turn-on traceing for such a user. What would be really smooth would be the option to configure a filter which would inspect the actual call parameters to the operation and determine if it should be traced or not
* AOP framework support - Other app servers integrate AOP frameworks which can be very efficient in solving some application level design and monitoring issues. GF should include such a framework
* Support in the GUI for configuring common load balancing solutions on the market, e.g. mod_jk
[Message sent by forum member 'jesper_soderlund' (jesper_soderlund)]
http://forums.java.net/jive/thread.jspa?messageID=243286