I absolutely agree.
However, the server doesn't need to be able to load classes dynamically. The proposed changes do not entail that it does. The server could still reload the whole application on each update. The improvement would still be that only the files get transmitted to the server that have been modified. The server could then assemble a new deployment based on the existing one and the modified Increment and then deploy this new, self-assembled application archive in the traditional way.
The proposal to get rid of the need for physical deployment-unit assembly does not require dynamic class definition reloadin either. The server could still act in the classical sense and reload an application in total for each update, but a good deal of time could be saved if IDEs didn't need to physical assemble an application before deployment. The only need for this is because the development arrangements of application artifacts differs from the deployment structure and because IDEs have no means to provide servers with virtual deployment units.
My imagination is such that a server would be able to deploy an application by being provided with a link to a virtual filesystem location. At this location, the server would expect to find a correct application archive atructure. The top level directory would have to contain a META-INF directory with an application.xml file in it...
An IDE would provide the server with a virtual filesystem link that leads back to a virtual filesystem service provided by the IDE itself. If the server requested to receive a directory listing for his deployment link, the IDE would return a correct application archive structure. If the server consequently tried to access the META-INF/application.xml file, it would again connect to the IDEs virtual filesystem service and request this file. The IDE would consult it's project configuration to resolve the META-INF/application.xml file to a project location myproject/meta/deploymentdescritors/application-config1.xml.
Of course, the need to do full redeployments on server-side would still be time consuming but the development experience would be much better. Test the virtual deployment caps that are implemented in Eclipse for Tomcat 6 webservers and you will see how perfect the approach is.
BTW: the approach to physically build a deployment unit should survive also for deployments that are outside the scope of the code-deploy-test cycle.
[Message sent by forum member 'wtff' (wtff)]
http://forums.java.net/jive/thread.jspa?messageID=243442