[ http://issues.apache.org/jira/browse/GERONIMO-1974?page=comments#action_12377953 ]
Prasad Kashyap commented on GERONIMO-1974: ------------------------------------------ This is how I think the redeploy should work. I don't mind if, by default, it replaces the target module entirely, in the config.xml and in the repo but the redeploy should have an option of leaving them behind, running. So if during redeploy, the "co-exist" option is chosen, the earlier version of the target module should be left behind running. The configirations should still be loaded and the files in the repo left behind. However, the latest version of the app serves requests. The user now the option of removing earlier version(s) when he is satisfied the latest version is working as desired. The multiple versions of the app introduce layers of redundancy such that if the latest version goes down/stops, the immediate earlier version takes over as the backup. It worked like this by default until y'day. > Can't "redeploy" a copy of an application using a different version in the > module ID > ------------------------------------------------------------------------------------ > > Key: GERONIMO-1974 > URL: http://issues.apache.org/jira/browse/GERONIMO-1974 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > Attachments: redeploy-stacktrace.txt > > If you deploy an application with version foo/bar/1.0/baz and then change the > plan to be foo/bar/1.1/baz and try to redeploy it doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
