Created attachment 917138 [details] deployment_failed Description of problem: deployment of new war from repo content fails (always) Version-Release number of selected component (if applicable): JON 3.2.2 DR4 How reproducible: always Steps to Reproduce: 1. Start JBoss EAP 6.1 standalone server. 2. Start JBoss ON 3.2 system. 3. Import JBoss EAP server into inventory. 4. Configure connection settings for newly imported resource. 5. Deploy jboss-as-helloworld.war to JBoss EAP server. 6. Create test repository from Administration > Content / Repositories: * *Name*: `Test Repo` 7. From Test Repo upload a new version of helloworld WAR: * *Upload File*: jboss-as-helloworld-1.0.1.war (any WAR will do) * *Type*: *File [Deployment:JBossAS7]* 8. Subscribe the imported JBoss EAP server to *Test Repo*: 1. Under *Resources Subscribed To This Repository* click *SUBSCRIBE...* button. 2. For search, enter `jboss-as-helloworld.war` and set type drop-down to *Service* and click search. 3. Check jboss-as-helloworld.war resource which was returned. 4. Click *SUBSCRIBE SELECTED*. 9. Navigate to the content page of the jboss-as-helloworld.war resource. 10. Select the new tab. 11. Check one of the new versions of jboss-as-helloworld.war (jboss-as-helloworld-1.0.1.war). 12. Click *DEPLOY SELECTED*. Actual results: deployment fails Expected results: deployment succeeds Additional info: screen-shots attached this is not a regression
Created attachment 920543 [details] helloworld.war
Created attachment 920544 [details] ClusterWebApp.war test app wars added
OK, I think this may actually behaving as expected. The Content tab basically allows for a redeploy of the same deployment, basically an update of the bits, but for the same actual deployment. In the reproduction steps you first deploy jboss-as-helloworld.war. You then try to update to jboss-as-helloworld-1.0.1.war. Since EAP is using the filename as the deployment name, it can't find jboss-as-helloworld-1.0.1.war. So actually, the statement above, "(any WAR will do)", does not seem to be true. Remember that packages can be assigned the same name, and the versions can differ. This is the expectation when performing this sort of update. In other words, the versioned-deployment strategy we've been trying to accommodate recently, where version strings exist in the artifact name, does not translate well to the content/package strategy. Content expects the version to be separate from the name. The whole thing is made confusing by the complete lack of an error-message in the failure detail. And also, nothing useful in the agent log. The following commit fixes it so the failure message can be seen in both places, but the master commit 367145b3a9a714b02eff372019fb08bc41c3b5fb Author: Jay Shaughnessy <jshaughn> Date: Thu Jul 24 14:05:58 2014 -0400 This is not a fix for the reported issue, which actually seems to not be a bug. This is a fix to ensure failed package installs persist the error messageto the history record in the DB. And to provide a more useful log message in the agent log. release/jon3.3.x commit 562cd907ca79fc18f9bfdf9aa051bbe5e10f3fea Author: Jay Shaughnessy <jshaughn> Date: Thu Jul 24 14:09:59 2014 -0400 Cherry-pick master ec19fd70d8db8e100b3c83c75f8d29d6c5c797ff
Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993
Created attachment 923325 [details] content_update
closing issue as verified since no error is visible anymore 4 new BZs filed related to this bZ #1126460 , #1126387 , #1126044 , #1126053