2 Replies Latest reply on May 6, 2014 4:41 PM by gkelly01

    Migration issues, deployment and lib/resource files

    gkelly01

      I'm currently migrating an app from glassfish to wildfly 8 (w/ee7 and richfaces) and have stumbled on a issue I cannot quite figure out.  What I'm looking for is a best recommended approach for this issue -- as I'm sure I'm not the only one.

       

      My application creates an image file, on-demand, after selecting several users options and would write the new image file in the resources directory relative to the web root.  This has always worked fine and seemed like a straight forward approach.  For example, using <h:graphicImage library="chartImages" name="myChart.png"></h:graphicImage> would have a dir named ChartImages under the resources dir where all the files would be written to and accessed from.

       

      I use the CLI to deploy my app using: [~] deploy -f /myApp/dist/myApp.war.  This works perfectly fine and everything works except that its not an exploded deployment, so I do not have access to write to my resources directory.  I have seen and read about the tmp directory but  can't find detailed info how this exactly works, reading/writing/accessing...

       

      How do I specify that I want to deploy this as an exploded deployment??  I'd like to continue using this deployment method if possible.  Also, if I set auto-deploy-exploded="true" in my standalone.xml file and copy an exploded dir into the deployments directory, wildfly goes into an infinite loop deploying and undeploying the app.

       

      Lastly, what is the recommended design for writing/creating on-demand and accessing them w/html?

        • 1. Re: Migration issues, deployment and lib/resource files
          jaikiran

          Writing content at runtime to locations within the web application is always risky for various reasons. Consider a case where the images (for examples) have been uploaded/written to the deployed web app and now the development team comes up with a new version of the .war that you need to deploy. How do you manage the older war without losing contents that have been added to it?

           

          One way to deal with this is to write them out to some static location outside of the web context and then use something like this Re: wildfly hot deploy of static content. That way your runtime uploaded content isn't affected when you have to deploy new versions of the application. Furthermore, you won't even have to worry about where the .war deployment resides or how it is deployed (filesystem vs management API).

          • 2. Re: Migration issues, deployment and lib/resource files
            gkelly01

            Thanks so much for the reply/answer.  This is exactly what I was looking for!!