1 2 Previous Next 16 Replies Latest reply on Nov 25, 2008 9:28 AM by ips

    how to redeploy exploded wars

    ips

      In AS4, I could edit myconfig/deploy/jboss-web.deployer/context.xml and add the reloadable="true" attribute to the Context element, and then any exploded wars would get automatically redeployed if I touched their web.xml file.

      In AS5, setting reloadable="true" in myconfig/deploy/jbossweb.sar/context.xml does not appear to have the same effect. After doing so (and restarting the app server), touching web.xml or jboss-web.xml in an exploded war does not cause the war to be redeployed.

      Can you tell me how I can trigger redeploys on exploded wars?

      Thanks,
      Ian

        • 1. Re: how to redeploy exploded wars
          jaikiran

           

          "ips" wrote:

          In AS5, setting reloadable="true" in myconfig/deploy/jbossweb.sar/context.xml does not appear to have the same effect.

          For redeployment of exploded war (or ears), i did not have to do any configuration changes, neither in AS4 nor AS5.

          "ips" wrote:

          After doing so (and restarting the app server), touching web.xml or jboss-web.xml in an exploded war does not cause the war to be redeployed.



          Touching the web.xml (inside the WAR/WEB-INF folder) should have redeployed the application. Which exact AS5 version are you using?

          Finally, do you have the Hot deployment disabled? The hot deployment configuration is set in %JBOSS_HOME%\server\< serverName>\conf\profile.xml

          <!-- Hotdeployment of applications -->
           <bean name="HDScanner"
           class="org.jboss.system.server.profileservice.hotdeploy.HDScanner">
           <property name="mainDeployer"><inject bean="MainDeployer"/></property>
           <!-- Workaround for JBMICROCONT-176
           -->
           <property name="controller"><inject bean="jboss.kernel:service=KernelController"/></property>
           <!-- Broken due to JBMICROCONT-176
           <property name="controller"><inject bean="jboss.kernel:service=Kernel" property="controller"/></property>
           -->
           <property name="profileService"><inject bean="ProfileService"/></property>
           <property name="scanPeriod">5000</property>
           <property name="scanThreadName">HDScanner</property>
           </bean>


          • 2. Re: how to redeploy exploded wars
            jaikiran

            One more question - Which version and vendor of Java do you use? And which operating system?

            • 3. Re: how to redeploy exploded wars
              alesj

               

              "ips" wrote:
              Can you tell me how I can trigger redeploys on exploded wars?

              It's this bean
               <bean name="ProfileService" class="org.jboss.system.server.profileservice.basic.MetaDataAwareProfileService">
              

              in profile.xml that makes this possible.
              - http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profile/basic/MetaDataAwareProfile.java

              • 4. Re: how to redeploy exploded wars
                ips

                Correction: for standalone wars in AS4, I didn't have to do the reloadable="true" thing in context.xml in order for redeploy to work; I could just touch web.xml. It's only for wars within ears that the reloadable="true" was necessary (if I didn't want to touch the ear's application.xml and cause the entire ear to be redeployed).

                I haven't changed anything in my profile.xml. The MetaDataAwareProfileService and the HDScanner are both deployed.

                Note, hot redeploy does work fine for zipped wars, just not for exploded wars.

                Here's my environment info:

                OS: Windows XP SP3
                Java: Sun 1.6.0_10
                JBAS: Implementation-Version: 5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=20
                0811070836)

                • 5. Re: how to redeploy exploded wars
                  jaikiran

                   

                  "ips" wrote:
                  just not for exploded wars.

                  Here's my environment info:

                  OS: Windows XP SP3
                  Java: Sun 1.6.0_10
                  JBAS: Implementation-Version: 5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=20
                  0811070836)


                  I remember that in AS5, for exploded WARs inside exploded EARs, touching the web.xml would indeed redeploy the application.

                  You seem to be using the JBossAS5 trunk. Let me see how it behaves there.


                  • 6. Re: how to redeploy exploded wars
                    jaikiran

                    Updated the JBossAS trunk and there's definitely a change (atleast from deployment perspective) in the hot deployer bean. It no longer is in the %JBOSS_HOME%/server/< serverName>/conf/profile.xml. It has now been moved to %JBOSS_HOME%/server/< serverName>/deploy/profileservice-jboss-beans.xml.

                    And for some reason, the HDScanner does not pick up the changes to even the top level deployment descriptor. Touching the application.xml of the EAR too does not work in the trunk. However deleting the exploded deployment and putting it back, does trigger the redeployment. Will have to dig into code to see what changed.


                    • 7. Re: how to redeploy exploded wars
                      jaikiran

                      A bit of debugging shows that the HDScanner uses the profileservice which then uses the SerializableDeploymentRepository to getModified applications through getModifiedDeployments() method. This method looks for the changes to the "root" of the deployment which turns out to be the EAR file itself. Any changes to the application.xml or the deployment descriptors are not identified. Not sure how this was handled in the released versions.

                      • 8. Re: how to redeploy exploded wars
                        jaikiran

                         

                        This method looks for the changes to the "root" of the deployment which turns out to be the EAR file itself. Any changes to the application.xml or the deployment descriptors are not identified


                        To be more clear - The profile service uses the root.hasBeenModified() VFS API on the VirtualFile. So i guess, something changed in the VFS which is resulting in this issue.


                        • 9. Re: how to redeploy exploded wars
                          emuckenhuber

                           

                          "jaikiran" wrote:

                          To be more clear - The profile service uses the root.hasBeenModified() VFS API on the VirtualFile. So i guess, something changed in the VFS which is resulting in this issue.


                          Hmm the metadata awareness Ales was mentioning is used in the MetaDataAwareProfileService.
                          This still needs to be ported to the repository one - the SerializableDeploymentRepository you were mentioning
                          I've created a jira some time ago to track this: https://jira.jboss.org/jira/browse/JBAS-6148

                          But still - using the MetaDataAwareProfileService, should redeploy your .war by just touching the web.xml


                          • 10. Re: how to redeploy exploded wars
                            peterj

                             

                            It no longer is in the %JBOSS_HOME%/server/< serverName>/conf/profile.xml. It has now been moved to %JBOSS_HOME%/server/< serverName>/deploy/profileservice-jboss-beans.xml.


                            Yes, the musical chairs being played by the the files in the app server since CR2 had been indeed a sight to behold!

                            • 11. Re: how to redeploy exploded wars
                              ips

                               

                              This method looks for the changes to the "root" of the deployment which turns out to be the EAR file itself.


                              This gave me an idea for a workaround. If the scanner looks at the last modified time of the war directory itself, that just needs to be updated. Creating or deleting a file or directory inside a directory causes that directory's mtime to be updated. So a simple workaround is to just create a 0-byte file or empty directory directly inside the war dir. I do the following in the Ant script I use to push out modified files to my exploded deployment (the commented out lines are the ones I used to use):

                              <!--
                              <echo>*** Touching &lt;warDir&gt;/WEB-INF/web.xml to force redeploy...</echo>
                              <touch file="${warDir}/WEB-INF/web.xml" />
                              -->
                              <echo>*** Deleting then touching <warDir>/redeploy-trigger.txt to force redeploy...</echo>
                              <delete file="${warDir}/redeploy-trigger.txt" quiet="true" />
                              <touch file="${warDir}/redeploy-trigger.txt" />
                              


                              Thanks for your help.

                              -Ian


                              • 12. Re: how to redeploy exploded wars
                                jaikiran

                                 

                                "PeterJ" wrote:
                                It no longer is in the %JBOSS_HOME%/server/< serverName>/conf/profile.xml. It has now been moved to %JBOSS_HOME%/server/< serverName>/deploy/profileservice-jboss-beans.xml.


                                Yes, the musical chairs being played by the the files in the app server since CR2 had been indeed a sight to behold!


                                You will find something more (which i think you might have to add to your waiting to be published book), if you update to the latest JBoss AS trunk ;-) The lib folder under each server profile (default, all etc...) is now empty and all the jar files are now moved to a %JBOSS_HOME%/common/lib folder. Going by what i saw in one other forum thread, this common/lib will act as a parent to all server/< serverName>/lib.

                                P.S: Sorry for hijacking the topic.

                                • 13. Re: how to redeploy exploded wars
                                  jaikiran

                                   

                                  "ips" wrote:

                                  This gave me an idea for a workaround. If the scanner looks at the last modified time of the war directory itself, that just needs to be updated. Creating or deleting a file or directory inside a directory causes that directory's mtime to be updated. So a simple workaround is to just create a 0-byte file or empty directory directly inside the war dir.


                                  That's good workaround till this is fixed. Thanks for sharing :-) This will come in handy for me while playing with some sample applications on JBoss AS trunk.

                                  • 14. Re: how to redeploy exploded wars
                                    peterj

                                     

                                    The lib folder under each server profile (default, all etc...) is now empty and all the jar files are now moved to a %JBOSS_HOME%/common/lib folder.


                                    Yes, this is one of the things I have been monitoring on the developers mailing list. They were going to put the jars at server/lib (and I have a checkout of trunk that has this) until I squawked and then they decided that common/lib might be less confusing (though they might have gotten around to this eventually even without my complaining because common/lib was one of the places they had considered earlier). And this is in the list of musical chairs items. Unfortunately, the earlier chapters of the book where we discuss these things are cast in concrete (who would have thought that such radical changes would be made between the final CR and GA?) so we now have a new appendix with these changes and I seem to be adding to it daily based on changes I see in trunk and in the dev mailing list.

                                    And please also accept my apologies for hijacking this topic.

                                    1 2 Previous Next