5 Replies Latest reply on Mar 2, 2009 6:44 AM by jaikiran

    Help in understanding deployment of war's

    soimafreak

      Hi,

      I'm pretty new to jboss, have seen and touched it and even installed it (RHEL systems) but other than that I don't know much else.

      I know that to deploy an application I can put it in the default/deploy directory but I don't know much more than that, I know that on a RHEL4/5 system in /etc/sysconfig/ you can set the java home, jboss home directory, bind address etc. I know there's some sort of context path set but not sure of the importance of this or even where to set them. Likewise I'm not sure of the importance of the war file name etc etc.

      I'm trying to in general increase my general awareness of jboss hence visiting the site to trawl through some documents.

      Normally this is all taken care of our Development teams and we just deploy them. Which is great until you have issues.

      At this moment in time I have a rather specific query.

      If possible I'd like to know what might happen if file1.war was copied and renamed to file2.war but left within the deploy directory. Could this cause issues?

        • 1. Re: Help in understanding deployment of war's
          peterj

          If you rename server/xxx/deploy/file1.war to server/xxx/deploy/file2/war, then the application with context "/file1" would be undeployed and the application with context "/file2" would be deployed.

          • 2. Re: Help in understanding deployment of war's
            soimafreak

            Thanks for the reply.

            I'll be honest I don't understand, why do they both not deploy with their own individual contexts?

            • 3. Re: Help in understanding deployment of war's
              jaikiran

              Any deployable applications (ex: .war files) that are in the deploy folder of JBoss, will be picked up by the server and deployed. In case of .war files, each war file represents an application and has its own "context". The "context" is used to access the application. In JBoss the context name for each war file by default is the name of the war file. So if your war is named file1.war then it's context by default is file1 (you can use the jboss-web.xml to give a different context name, but let's not get to that yet). Then you can access the application at http://localhost:8080/< contextName> (in this example: http://localhost:8080/file1).

              So as Peter said, when you create a copy of file1.war and let the file2.war remain in the deploy folder, the server will deploy the file2.war at the context "file2".

              • 4. Re: Help in understanding deployment of war's
                soimafreak

                so you should be able to run two applications that are the same with different context paths. But I imagine it depends how the application is written?

                So a "hello world" war could be deployed multiple times with different file names. But what if it was a more complicated application? I guess the question is, is a war isolated from any other war, or can they interact/utilise the same resources?

                Cheers for the info, it's nice to finally be understanding some of this :)

                • 5. Re: Help in understanding deployment of war's
                  jaikiran

                   

                  "soimafreak" wrote:
                  so you should be able to run two applications that are the same with different context paths. But I imagine it depends how the application is written?
                  So a "hello world" war could be deployed multiple times with different file names. But what if it was a more complicated application?

                  In theory yes, it should be possible. But finally its upto the way the application is written.

                  "soimafreak" wrote:

                  I guess the question is, is a war isolated from any other war, or can they interact/utilise the same resources?


                  By default yes, each WAR has its own classloader (but these are things that can be configured to application server configuration files).