[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ]

Paul McMahan updated GERONIMO-2006:
-----------------------------------

    Attachment: GERONIMO-2006.patch

I was able to recreate the problem on tomcat.  It is caused by a buffer overrun 
when render parameters that are set during the processAction phase are bigger 
than 8k. Since the error messages from the deployers are often larger than 8k 
the attached patch works around the buffer overrun by saving the message in the 
portlet session instead.

The patch also looks for use of the configId attribute in the plan and if found 
uses the new upgrade utility to provide an upgraded version of the plan that 
the user can save locally as a starting point.  In some cases (welcome app, 
jmx-debug app, etc) no further editing of the plan is required.  The user can 
just save the updated plan for their 1.0 app and immediately deploy it again 
from the same portlet.  The patch doesn't support upgrading plans that are 
embedded in the archive -- this is a bit more challenging but I think can be 
done.

And finally, since error messages from the deployers are often very, very long 
and contains several stack traces this patch just shows the first line of the 
error message in the console (which is usually sufficient) and provides a 
button to show the full message if the user wants all the gory details.

> Deploying an application with an incorrect deployment plan results in 
> non-functional admin console panel
> --------------------------------------------------------------------------------------------------------
>
>          Key: GERONIMO-2006
>          URL: http://issues.apache.org/jira/browse/GERONIMO-2006
>      Project: Geronimo
>         Type: Bug
>     Security: public(Regular issues) 
>   Components: deployment, console
>     Versions: 1.1
>     Reporter: Dave Colasurdo
>     Assignee: Aaron Mulder
>     Priority: Blocker
>      Fix For: 1.1
>  Attachments: GERONIMO-2006.patch, Myapp.war, badPlan.xml, badPlan2.xml, 
> stackTrace.log
>
> Deploying myApp.war using badPlan.xml (both attached) results in a 
> non-functioning "Show Web App Wars" panel.
> The console "Deploy Applications" panel reports "application installed and 
> started successfully".  However, the application did not startup succesfully. 
>  The badPlan file is actually missing tcpListenerAddress=auto which causes 
> TomcatReceiver Gbean to fail startup.  I've attached the stacktrace to the 
> JIRA.  
> From then on, the "Web App Wars" console panel shows "portlet error" and 
> there is no way to uninstall the bad application via the console.  The server 
> must be stopped and restarted in order to have the "Web App War" panel 
> function correctly.
> The console should be able to report the true status of the "deploy/start" 
> and recover from deploying a bad plan.

-- 
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

Reply via email to