geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <>
Subject Re: Issues with redeploy
Date Fri, 05 May 2006 02:59:43 GMT
I did a redeploy test on the latest code and this is what I found now.

Here's the command:
deploy --user system --password manager redeploy

Here's the error message:
    Redeployed geronimo/welcome-jetty/1.2-SNAPSHOT/car

    Error: Operation failed: Trying to stop unknown configuration:

Refreshing the list in the console, I still get the message in the portlet,
"Error occurred in portlet!"
Same stacktrace as posted earlier in this thread.


On 5/3/06, Prasad Kashyap <> wrote:
> I have been testing the redeploy functionality using CLI and came
> across the following issues/questions/concerns. Basically, I have been
> redeploying the same war but bumping the version # in the plan.
> 1) After a redeploy is done by CLI, the portelt in the console that
> displays the list is broken.
> (http://localhost:8080/console/portal/apps/apps_war). It shows the
> message, "Error occurred in portlet!"  The stacktrace is attached. It
> needs a server restart to fix this problem.
> 2) What should the redeploy behavior be ? It's usage text says, " A
> shortcut to undeploy a module from one or more servers, then deploy a
> new version..." Now undeploy (tries to) delete everything from the
> repo. I say "tries to" because a classloader problem locks the jars
> and prevents them from being deleted
> ( .
> However the rest of the files from the app are deleted successfuly.
> But redeploy leaves all the files from the older version behind.
> 3) After a CLI redeploy and a server restart (see #1), the previous
> versions of the app show up in the list on console. They are not
> loaded but they can all be started together. The latest version is
> served.
> Now, if behaviors 2 &3 are expected/desired, then that's fine. We
> should just change the usage text for redeploy. IMHO, I like this
> behavior. The user can have multiple versions of the app running and
> later decide when he wants to uninstall any of the other versions. It
> also introduced a redundancy factor where if the latest version goes
> down, the earlier version takes over and start serving. Now if this is
> not the intended behavior, then can someone please explain why we
> can't make it the intended behavior ?
> We should fix item #1. I have opened G-1974.
> Cheers
> Prasad

View raw message