4 Replies Latest reply on Jan 27, 2009 11:35 AM by employeebean

    properties file not deployed in WAR

    employeebean

      I have a problem with our properties files.

      Changes in the files are not deployed when I restart the server. It works for my .ear projects (when the properties files are in a jar) but not in the web project (WAR file). I have tried to put the properties file under WEB-INF/classes and also tried directly in the WAR file root but the only way to update the file is to delete the entire jboss catalog and reinstalling it! The old properties file is deployed somewhere in jboss memory. I have tried to stop jboss and remove everything under work and tmp and removed the war file from deploy. When the server is started again the application is still running. I use jboss application server 4.2.3.

      How do I force jboss to redeploy the file?

        • 1. Re: properties file not deployed in WAR
          peterj

          I think you might have to give a specific example. This example should indicate the exact content of the properties file (doesn't have to be the whole file, only a property or two will do), the exact location of the properties file, exactly how that property is used in your app, and exactly what behavior you expect to see when the property is changed and what you are seeing instead.

          Also, indicate if you deploy a WAR file, or an exploded WAR directory.

          Why am I asking for the above? Because of your statement "The old properties file is deployed somewhere in jboss memory". That "memory" is the "tmp" directory, which is where JBoss AS unpacks WAR files. Yet you have stated that even when you remove that directory, the old property values are still used.

          Some possible causes are:
          a) Your code is storing the property value elsewhere and retrieving from that location. Perhaps in a database. If you are using hsqldb, it stores its data in the data directory.
          b) The property is being used by a display items, and that item is being cached by the browser, and refreshing the browser page might pull up the updated item.

          • 2. Re: properties file not deployed in WAR
            employeebean

            Right now the properties file is located in the root directory of the war file. the war file is exported from eclipse.

            To retrieve a value I use the code:
            if ("true".equals(ConfigRegistry.getProperty("vpweb",
            "security.validate.bks")))

            in the properties file (vpweb.properties):
            security.validate.bks=true

            I use the default server instance. It doesn't matter if I export a new war and put it in the deploy directory or if I change the war file on the spot. When the server is restarted it creates a work and a tmp directory which I have deleted to try to force a deploy of the entire war file.

            The best thing would be if the property could be modified by just modifying the properties file and maybe republish the app. The customer wants to change the properties himself so it should be as easy as possible.

            Thanks for answering

            • 3. Re: properties file not deployed in WAR
              peterj

              I suspect that the properties file is being read from the tmp directory because that is where the WAR file is exploded into.

              To get the results you are looking for, you could deploy the WAR as an exploded directory. Then the file would be located at server/xxx/deploy/xxx.war/vpweb.properties. The customer could then update the file as needed (without having to rebuild the WAR file). But one more step is required - The ConfigRegistry class, which I assume is a helper class for reading the properties file, will have to periodically check to see if the properties file was updated. JBoss AS does a similar thing to notice if someone changes the jboss-log4j.xml file - you could use that code as an example.

              • 4. Re: properties file not deployed in WAR
                employeebean

                I finally looked into it again and switched the code that reads the file with apache commons configuration and that made the trick!