4 Replies Latest reply on Apr 8, 2012 2:36 PM by vineet.reynolds

    Redeploying WAR in an existing EAR in remote Weblogic with Arquillian

    goshki

      I've noticed that Arquillian remote Weblogic client uses weblogic.Deployer to deploy shrink-wrapped archives. I was wondering if it's possible to use the shrink-wrapped WAR for redeployment of a WAR defined in an existing EAR. Has anyone tried to do it?

        • 1. Re: Redeploying WAR in an existing EAR in remote Weblogic with Arquillian
          vineet.reynolds

          Just so that I understand this question correctly, you desire to have Arquillian update an already running deployment, or a part of it. Is that right?

           

          Given the way weblogic.Deployer is used by Arquillian, this is not possible at the moment. The Arquillian-WLS adapter fires a "weblogic.Deployer ... -deploy ..." for deployment of archives and "weblogic.Deployer ... -undeploy ..." for undeployment of archives. If you have a good enough reason, I could add a feature request, wherein the adapter would fire a "weblogic.Deployer ... -redeploy ..." instead of performing a fresh deployment.

           

          There is of course the part about undeployment of archives, and whether they should occur given that Arquillian is not managing the deployment entirely, but merely updating an existing one. I'm undecided about this aspect, primarily because there is no allowance of a rollback to a previous version of the application.

          • 2. Re: Redeploying WAR in an existing EAR in remote Weblogic with Arquillian
            goshki

            Thanks for your answer and I understand your concerns about the undeployment.

             

            To shed a little more light on my case and why I asked about redeployment: I have a local Weblogic with EAR application configured and running. My task is to add a new web application running within this EAR (for various reasons, mainly dependencies on EJBs, LDAP, targeting of data sources, etc.). First I've tried to deploy the new web application with Arquillian test just as a WAR in no way connected to the EAR but it failed and I've got HTTP error 404 from the test (couldn't find out why, maybe because one of the WARs in the EAR maps the '/' URI but that's a wild guess). Therefore I thought of deploying the test WAR built by Arquillian as a module of the existing EAR but this also failed (also got HTTP error 404 from the test). So the third option I've come up with is having a dummy WAR in the existing EAR and redeploy this WAR by an web archive built by Arquillian. But as you say, it's impossible at the moment.

            • 3. Re: Redeploying WAR in an existing EAR in remote Weblogic with Arquillian
              vineet.reynolds

              goshki wrote:

              ...

              First I've tried to deploy the new web application with Arquillian test just as a WAR in no way connected to the EAR but it failed and I've got HTTP error 404 from the test (couldn't find out why, maybe because one of the WARs in the EAR maps the '/' URI but that's a wild guess).

              This is similar to the scenario described in ARQ-642. Arquillian uses a servlet within the deployment to commandeer execution of tests, and if it cannot issue HTTP requests to this servlet because of the path mapping, then it is likely to see the response issued by your servlet, which might be a HTTP 404 going by your observation. But before I make hasty conclusions, can I see your code or a representation of it that I could execute to reproduce your problem. I'm not sure if issuing a redeployment on a running app would help in this case, since the primary problem here is that the client is unable to reach the Arquillian ServletTestRunner via HTTP.

              • 4. Re: Redeploying WAR in an existing EAR in remote Weblogic with Arquillian
                vineet.reynolds

                I've given this some more thought. Maybe the JMX protocol would help, but I need to verify if this would work seamlessly with WLS; as far as I know, only the JBoss AS containers use the Arquillian JMX protocol at the moment.