- Deploy as a war file (as opposed to ear files)
- Avoid dependencies on container setup (such as datasources, JMS queues, authentication, ...)
Deploy as a war file
A war file is relatively simple and easy to understand. In addition to this, it is faster to build as opposed to assembling ear files.
Keeping with war files for deployment will force you out of some technologies, like ejbs for instance, and most of the time, this is a "good thing". Most of time, there are good alternatives. This is where the lightweight stack technologies like spring and hibernate comes in.
Having a war file as the end product also opens up for a much larger container choice in deployment. Tomcat, Jetty, Resin, Weblogic, ..., whereas an earfile requires a complete J2EE container.
Avoid dependencies on container setup
This is all about avoiding "stuff that needs to be setup beforehand" in the deployment phase. Ideally, the war file should be able to be dropped right into any freshly installed container, and just work.
An example is the use of
Another example is authentication. In the web.xml file, you could use the
What is the catch then?
Of course there is a catch. Having the datasource defined external to the application deployment makes it easy to switch what database you are pointing at, without redeploying. Having the container do the authentication makes the container know your principal and roles internally, enabling things like HttpServletRequest.getUserPrincipal() to answer sane values.
But, much of the deployment descriptor requirement of mapping some "made up" name to real resources, comes from J2EEs concept of a developer role, an assembler role and a deployer role. More often than not, you, the developer, has all the roles.
Try keeping it simple for yourself!