How to package static content outside of web application

java-eemaven

Our web application has static content packaged as part of WAR. We have been planning to move it out of the project and host it directly on Apache to achieve the following objectives.

It's getting too big and bloating the EAR size resulting in slower deployment across nodes. Faster deployment times.
Take the load of Application Server
Host the static content on a sub domain allowing some browsers (IE) to load resources simultaneously
Give us an option to use further caching such as Apache mod_cache apart from the cache headers we send out to browsers.

We use yuicompressor-maven-plugin to aggregate and minimize JS file.

My question is how to package and manage this static content outside of the web application?

My current options are:

New maven war project. Still use the same plugin for aggregation and compression.
Just a plain directory in SVN and use YUI/Google compressor directly.

Or is there a better technology out there to manage static content as a project?

Best Answer

It sounds like the static resources change rarely, if ever, and require significant additional space and time to process.

I would have a separate WAR file. There are several benefits to doing this:

You can easily hook into automated processes such as build servers, artifact repositories, and deployments. For example, you could add a Maven dependency to your parent POM and Jenkins can easily build and deploy the new project with minimal configuration changes.
The distribution file is still a single archive in a standard format. That makes it easy to maintain and easy to pass around if necessary.
You can update static resources and the web application independently, saving time for both when they update. Code updates do not require packaging a ton of static resources: resource updates do not require compiling code and running code unit tests.
By reusing existing deployment processes you maintain the same number of failure points while not increasing the training work load.

Related Solutions

Java EE – Heavy Use of Static Methods in Web Applications

I would say that just by reading your analysis, you're saying there are alot of static methods and singletons. Static methods shouldn't be an issue by themselves, but if they're being used to proxy calls to the singleton objects, I would work on making those either rock solid, or replacing them with a more sane object model.

Static methods are useful for purely functional purposes, and you'll find both the Scala and Clojure programming languages to use them alot, mostly because they don't need to worry about mutable state.

Reading from this blog post on Java Static/Class methods(I've highlighted a relevant bit):

Static methods use no instance variables of any object of the class they are defined in. If you define a method to be static, you will be given a rude message by the compiler if you try to access any instance variables. You can access static variables, but except for constants, this is unusual. Static methods typically take all they data from parameters and compute something from those parameters, with no reference to variables. This is typical of methods which do some kind of generic calculation. A good example of this are the many utility methods in the predefined Math class. (See Math and java.util.Random).

Java web application folder structure

The standard structure for a WAR file is:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven generates this for you using your src/main/java, resources, webapp and your dependencies (placing them in /lib) in the maven-webapp-plugin, but that's implementation. The important thing to realize is that anything you put in WEB-INF is not externally accessible, whereas everything in the root directory of the WAR is public.

Generally you don't want to put much in the root, since you want your application to handle all access using the servlets and filters you define in web.xml. It's common to see an index.html (or .jsp) in the root that redirects to a servlet, for instance a Struts action.

Typical MVC implementations such as Stripes or Struts recommend against user's accessing JSPs directly, preferring that JSPs be view-only. They recommend creating controllers that forward to JSPs after processing the request, and the JSPs merely render the result. For instance, submitting a form to /login will run an action that processes the login request, creates the user's session, and forwards the user to the logged-in view of the home page JSP.

Best Answer

Related Solutions

Java EE – Heavy Use of Static Methods in Web Applications

Java web application folder structure

Related Topic