Issues with redeploy

[Prasad Kashyap <go...@gmail.com>]

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
(http://issues.apache.org/jira/browse/GERONIMO-1925#action_12377462) .
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.
http://issues.apache.org/jira/browse/GERONIMO-1974

Cheers
Prasad

Re: Issues with redeploy

[Prasad Kashyap <go...@gmail.com>]

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
C:\Apache\geronimo2\applications\welcome\target\geronimo-welcome-1.2-SNAPSHOT.war
C:\Apache\geronimo2\configs\welcome-jetty\target\plan\plan.xml
geronimo/welcome-jetty/1.1-SNAPSHOT/car

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

    Error: Operation failed: Trying to stop unknown configuration:
    geronimo/welcome-jetty/1.2-SNAPSHOT/car


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.

Reopening http://issues.apache.org/jira/browse/GERONIMO-1974
Cheers
Prasad


On 5/3/06, Prasad Kashyap <go...@gmail.com> 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
> (http://issues.apache.org/jira/browse/GERONIMO-1925#action_12377462) .
> 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.
> http://issues.apache.org/jira/browse/GERONIMO-1974
>
> Cheers
> Prasad
>
>
>