Bug 713448 - jboss-as-5 plugin: problems with deploying an application with an unmet dependency
Summary: jboss-as-5 plugin: problems with deploying an application with an unmet depen...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: 4.0.1
Hardware: All
OS: All
high
high
Target Milestone: ---
: ---
Assignee: Jan Martiska
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: 715077 715080 715086
TreeView+ depends on / blocked
 
Reported: 2011-06-15 12:59 UTC by dsteigne
Modified: 2018-11-14 12:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 715077 (view as bug list)
Environment:
Last Closed: 2012-02-07 19:17:03 UTC
Embargoed:


Attachments (Terms of Use)
A WAR which has a dependency that can not be met which can be used to test this issue. (810 bytes, application/octet-stream)
2011-06-27 18:20 UTC, Larry O'Leary
no flags Details

Description dsteigne 2011-06-15 12:59:37 UTC
Description of problem:
When deploying an application with an unmet dependency via admin console (Profile Service API):

    Admin console reports an error in deployment
    Application is not copied to deploy/ (or rather it seems that it is copied, but then deleted)
    Application does not show up in deployed applications in admin console
    Application *DOES* show up in JMX console, for example:

        J2EEApplication=null,J2EEServer=Local,j2eeType=WebModule,name=test.war

An unmet dependency is NOT an error.
Expected behavior:

    There shouldn't be an error (warning at most).
    Application should be copied to deploy/.
    Application should show up as a deployed application (where it could be undeployed).

Why does the application still show up in JMX console but not in deploy/?
It looks like the profile service assumes an error starting the application means
it was never deployed, and doesn't undeploy before removing it from deploy/?


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ian Springer 2011-06-20 14:39:47 UTC
Here's the code from the as5 plugin for deploying an ear or war (i.e. creating an EAR or WAR Resource):

http://pastebin.com/DJmSFAHN

Note, it tries to first distribute (i.e. copy into the deploy dir) and then start the app (distribute and start are both operations on the profile service DeploymentManager interface). If the start step fails, it will undeploy the app and consider the EAR or WAR Resource creation a failure. If the unmet dependency is causing start to fail, then this is what you are seeing here. 

Do we want to change the behavior of the as 5 plugin so if starting the app fails, it logs an error, but does not undeploy the app and abort the Resource creation?

Comment 2 Ian Springer 2011-06-21 18:52:57 UTC
[master 38ce0dd] fixes this. Now, if starting the newly deployed app fails, we do not rollback the deployment or send a failure response, but instead log a warning and set an informative error message on the create response. Unfortunately, due to a bug in the profile service (https://issues.jboss.org/browse/JBPAPP-6754), our check to see whether the app started successfully always returns true, even when the app failed to start. Hopefully we can get a fix from the EAP team for this, but in the meantime, at least now the EAR/WAR Resource creation succeeds for an EAR or WAR with missing dependencies.

Comment 3 Ian Springer 2011-06-21 19:10:51 UTC
>> Unfortunately, due to a bug in the profile service
>> (https://issues.jboss.org/browse/JBPAPP-6754), our check to see whether the app
>> started successfully always returns true, even when the app failed to start.

which means the following never happens:

>> log a warning and set an informative error message on the create response

Instead, we simply return a status of SUCCESS and don't inform the user that the call to start() failed.

Comment 4 Larry O'Leary 2011-06-27 18:20:20 UTC
Created attachment 510134 [details]
A WAR which has a dependency that can not be met which can be used to test this issue.

Comment 5 Jan Martiska 2011-09-16 08:33:26 UTC
Verified the fix - the application gets deployed (stays in deployed state and in "deploy" directory even after errors in EAP console), no error is encountered by JON. The deployed application remains in the EAP's inventory in JON.

Build used for verification: RHQ 4.1.0-SNAPSHOT ad51846
GWT Version: 2.0.4
SmartGWT Version: 2.4

Will probably add an automated testcase for this for EAP 6 plugin.

Comment 6 Mike Foley 2012-02-07 19:17:03 UTC
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE


Note You need to log in before you can comment on or make changes to this bug.