Steps to reproduce:

      1) Download attached and unzip
      2) Hot-deploy the contained directory - EARwithWAR-handmade
      3) Check the deployment info (in EmbJopr) - a WAR contained inside appears
      4) In the deploy dir, add '.ear' to the name of 'EARwithWAR-handmade' - rename to 'EARwithWAR-handmade.ear'
      5) Now check the deployment info in EmbJopr. You will see:

      • the WAR is DOWN
      • new EAR appeared, but is also down
        6) After invoking the Start op on EAR, everything gets to the right state.

      (18:14:46) ozizka: emuckenhuber: I've noticed one interesting thing. AS 5 deployment scanner first scans what's new and then what was removed. Shouldn't it be the opposite way?
      (18:20:34) emuckenhuber: ozizka: well it first scans for removal and then for additions - where do you see that ?
      (18:20:47) ozizka: I've tried it this way:
      (18:21:18) ozizka: It scans recursively, so I've created an exploded ear directory, only without the .ear suffix.
      (18:21:28) ozizka: So AS scanned, found the .war inside this dir,
      (18:21:34) ozizka: and deployed it.
      (18:21:49) ozizka: Then I renamed the directory - added the .ear suffix,
      (18:22:01) ozizka: so what should happen IMO is first undeploying WAR,
      (18:22:11) ozizka: and then deploying newly found exploded EAR
      (18:22:24) ozizka: I know it's not usual use case
      (18:22:45) ozizka: But instead, the WAR is reported to be DOWN (in EmbJopr)
      (18:23:15) ozizka: and ear appears, but is DOWN too
      (18:24:22) ozizka: When I invoke the Start operation on the ear, everything gets to normal, that is, EAR UP, standalone WAR disappears and Embedded WAR appears and is UP
      (18:26:02) ozizka: emuckenhuber: And to add why I think that deployment is done first is this:
      (18:26:02) ozizka: java.lang.IllegalStateException: jboss.web.deployment:war=/hellothere-inEAR is already installed.
      (18:26:19) ozizka: that happens after the rename

        Gliffy Diagrams




              • Assignee:
                emuckenhuber Emanuel Muckenhuber
                ozizka Ondrej Zizka
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: