Version-Release number of selected component (if applicable): Version: 3.0.1.GA Build Number: dd8a001:fbca611 EAP 4.3 CP10 How reproducible:always Steps to Reproduce: 1. have EAP started in default profile inventoried in JON 2. deploy a hello.war (Create child in EAP's inventory tab, select archive to be exploded [Deploy zipped=No]) 3. wait for deployment to appear among other EAP's children in inventory 4. ASSERT deployment is exploded on filesystem (in EAP deploy dir) and is reachable on EAP via HTTP 5. Navigate to hello.war resource, select Content tab 6. Click 'New' upload new version of war (some modified version) Actual results: - Deployment becomes unavailable on server (server returns 404) - on file system it is no longer exploded, you'll find hello.war file - after a while, deployment is detected as offline by JON This is what appears in EAP's log 15:43:05,282 INFO [TomcatDeployer] deploy, ctxPath=/hello, warUrl=.../deploy/hello.war/ 15:44:20,585 INFO [TomcatDeployer] deploy, ctxPath=/hello, warUrl=.../tmp/deploy/tmp2120379007588589648hello-exp.war/ 15:44:20,946 INFO [TomcatDeployer] undeploy, ctxPath=/hello, warUrl=.../deploy/hello.war/ Expected results: - modified version of hello.war becomes available via HTTP - on file system, deployment remains exploded Additional info: setting severity to urgent, because it could be very common usecase
The deployment code does not take into account current application state (zipped or exploded) and deploys everything as zipped. This is not a regression with respect to the content changes recently made. I tested with EAP 4.2 and 4.3 CP10 and deployments succeed regardless of existing deployment state (zipped or exploded). Each application has a flag dedicated to this (if the current deployment is zipped or exploded) but is not properly used for content updates. This is not a regression but a fix can be placed in future releases to keep existing deployment configuration.
triage to JON 3.1 mfoley,crouch
Blocking BZ fixed.