7 Replies Latest reply on Aug 8, 2012 3:52 PM by Abhijit Karpe

    Accessing external files from a war

    Abhijit Karpe Newbie

      Hello,

       

      I need some help understanding the way the following can be done in Jboss 7. I am migrating an application to Jboss and wanted to go with the latest version.

      This application heavily uses an external location to read (configs and dynamic properties) and write files (reports, stats etc..)

       

      I was able to get this working in standalone mode by creating a folder within the application and deployed the application as exploded.

       

      I would however like to go with the domain setup so as to leverage the clustering and load balancing properties. It doesn't look like exploded deployments are supported for domain mode. (Am I wrong here??)

      Also if I give an external location, the files cannot be found.

       

      What is the recommended way for such a funcationality.

       

      I did try searching the forums but was not able to find a solution for this.

       

      Any help is greatly appreciated.

       

      Thanks,

      Abhijit

        • 2. Re: Accessing external files from a war
          Abhijit Karpe Newbie

          Thanks for the response Stephen.

          The issue actually turned out to be a different one. I thought the folders were not accessible in domain mode and were accessible from standalone mode.

          It came out to be system parameters. I have been setting the location of the folder in system path. It seems that they are not being set the same way (command line parameters) as standalone.

           

          What is the best way to set a system parameter (other than changing some server xml)?

          I need to keep it configurable to allow our automated deployments in multiple environments.

          • 3. Re: Accessing external files from a war
            jaikiran pai Master

            Abhijit Karpe wrote:

             

            It came out to be system parameters. I have been setting the location of the folder in system path. It seems that they are not being set the same way (command line parameters) as standalone.

            Command line params for system properties should work. I just tried this in domain mode:

             

            ./domain.sh -Dfoo=bar
            

             

            After the servers started, I used the CLI to check for the system properties on the server:

             

            /host=master/server=server-one/core-service=platform-mbean/type=runtime:read-attribute(name=system-properties)
            

             

            and I see that system property in the output:

             

            {
                "outcome" => "success",
                "result" => {
                    "[Host" => "true",
                    "[Server:server-one]" => "",
                   ...
                    "foo" => "bar",
            
            1 of 1 people found this helpful
            • 4. Re: Accessing external files from a war
              Abhijit Karpe Newbie

              Yes you are right. That did work and I was able to pass the required parameters.

               

              Earlier all these -D parameters were being set to the JAVA_OPTS. In this case the variables are not accessible. If I provide it directly to the domain.bat, it works fine as you showed above.

              This probably is because of the multiple java processes? (Host Controller and individual servers)

               

              However the JAVA_OPTS approach did work in standalone mode. Not sure if it was intentional to not pass on the JAVA_OPTS to the individual server processes?

              • 5. Re: Accessing external files from a war
                jaikiran pai Master

                Abhijit Karpe wrote:

                 

                Yes you are right. That did work and I was able to pass the required parameters.

                 

                Earlier all these -D parameters were being set to the JAVA_OPTS. In this case the variables are not accessible. If I provide it directly to the domain.bat, it works fine as you showed above.

                This probably is because of the multiple java processes? (Host Controller and individual servers)

                 

                From what I know the JAVA_OPTS isn't passed around for the individuals servers in that domain. But I'll have to check with someone who knows more about this.

                • 6. Re: Accessing external files from a war
                  Brian Stansberry Master

                  JAVA_OPTS isn't passed directly through to server processes (e.g. things like -Xmx512M will not be passed through) but system properties should go through.

                   

                  In the next week I'm doing a few tasks related to how command line params and values from domain.conf.bat. I'll have a look at this.

                   

                  Ah! Maybe this is the issue, in domain.conf.bat:

                   

                   

                  rem # JVM memory allocation pool parameters - modify as appropriate.

                  set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M"

                   

                   

                  rem # Reduce the RMI GCs to once per hour for Sun JVMs.

                  set "JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true"

                   

                   

                  That first bit is discarding any JAVA_OPTS coming from the environment. Does adding -Dfoo.bar to that line result in the value being available on the server?

                  • 7. Re: Accessing external files from a war
                    Abhijit Karpe Newbie

                    Yes that does seem to be the problem. I tried putting in my parameter in this location and it did work.

                    So as I understand, any system parameters send under JAVA_OPTS were also intended to be sent to the individual servers?

                    It is just because of this small bug that the JAVA_OPTS was getting overwritten.