Thanks for the wonderful explanation, that's exactly how I understood as
well.
All I'm trying to say is that it might be worthwhile to capture the
benefits in a formal document :-)
-Arun
On 5/20/10 10:37 AM, glassfish_at_javadesktop.org wrote:
> Not having written the spec, the primary benefit of multiple versions is simply the ability to switch versions quickly.
>
> If you go through a typical use case right now, deployment consists of copying files and updating domain.xml.
>
> An example is say you have an application on a remote server. If you use the GUI or a remote CLI, deploying a new copy of running application consists:
>
> 1) Downing the current application
>
> 2) Undeploying the current application
>
> 3) Copying up the new aritifact (EAR/WAR).
>
> 4) Expanding that artifact on the app server.
>
> 5) Deploying the new application.
>
> 6) Starting the new application.
>
> You can see that if you have a particularly slow connection, or a large application, the downtime of the existing application can be significant.
>
> One way to avoid this is to copy and expand your application to the app server first, then undeploy the old app and deploy the new app from a directory.
>
> But if something goes wrong, the old app is undeployed and your application server doesn't have a running version of the app. So to "roll back" you would have to redeploy the old copy.
>
> if you copy the new application to "newdir" while leaving the old application in "olddir", this rollback isn't necessarily very difficult.
>
> However, if you simply deployed your new app "over" the old one, the old app isn't there at all any more, so there is no quick rollback. You'd have to upload and deploy the old version.
>
> By letting you "stage" different versions of the application, you can help minimize application downtime during upgrades. As I mentioned, you can do this "by hand" right now, but if you wanted to deploy an application to a cluster of machines, that's a lot of hoop jumping and coordination.
>
> With versioned applications, the app server can do this for you, and, ideally, let you switch over (and back) very quickly with little management on your part.
>
> As for being able to run 2 versions simultaneously, that seems like quite a hurdle above what basic versioning can offer. You would have to be able to set up an alternate listener, to deploy the other version on different ports. But you would also have to be very careful about application design, resource sharing (both apps using the same connection pool for example), etc.
>
> I can see a lot of value with the basic versioning in terms of administration (assuming I'm understanding what it is supposed to do correctly).
> [Message sent by forum member 'whartung']
>
> http://forums.java.net/jive/thread.jspa?messageID=470745
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta