Best Practices for Building Production Quality EAR Files
by Hussein Badakhchani
In this article I examine the options available for packaging and deploying Java EE applications. I will start by reviewing the Java EE 5 specifications pertaining to application assembly and deployment. Next I will set out packaging specifications for production EAR files and review some of the techniques you can use to implement and enforce them.
This article is aimed at those responsible for creating or enforcing standards and those who regularly troubleshoot application deployments. The primary audience will therefore be BEA WebLogic administrators; however, anyone who has an interest in ensuring application deployments run smoothly will benefit from reading this article.
Packaging applications for deployment onto production servers is an integral part of Java EE projects. As more and more projects are developed offshore, the requirement for clear and justifiable packaging specifications becomes even more relevant. Incorrectly packaged applications can lead to subtle errors that require experts to resolve through lengthy analysis. Such problems are often intermittent—for example, different deployment mechanisms (and there are several available for WebLogic Server) can either mask or trigger deployment errors.
These problems are compounded by a general ignorance of the nature of the problems that can be caused by poor packaging and lack of clear error messages when they occur. All too often, the causes of deployment failures are overlooked due to the pressure to get the application deployed. A good WebLogic administrator will find a workaround and complete the deployment even if that means simply redeploying the application. However, if the root cause of the failure is not identified and resolved, the defect will resurface in latter test phases, where it can be costly and time consuming to resolve and can increase the risk of delivering the project on time. In the worst case, scenario deployment failures are not even considered defects but simply accepted as part of the behavior of the application.
Java EE Application Assembly and Deployment
Before we begin to look at the details of the Java EE 5 specification relating to deployment, we need to understand the goals of the specification. Chapter 8 of the specification, "Application Assembly and Deployment," states the goals clearly as "This chapter specifies Java Platform, Enterprise Edition (Java EE) requirements for assembling, packaging, and deploying a Java EE application. The main goal of these requirements is to provide scalable and modular application assembly, and portable deployment of Java EE applications into any Java EE product."
In general terms, the specification is concerned with balancing the needs of the stakeholders it identifies using platform roles, for example the deployer, the system administrator, and the tool provider. This balancing act, or perhaps more unkindly, the compromise, affords some flexibility to the end user but at a cost. As the details of packaging are left up to the user to decide, a high degree of variance can occur in the packaging of different applications, especially if they have been created by desperate project teams. We need to be familiar with the specification to ensure we adhere to it where necessary and justify any restrictions we impose on it.
The Java EE Application
The Java EE application is composed of up to four types of Java EE modules and an optional application deployment descriptor. The modules are:
Like their parent application component, all of these modules have specific directory structures and deployment descriptors that are expected by all Java EE containers. There is also a provision to include container-specific deployment descriptors. As an example, the Web application module can contain a
Packaging Best Practices for Production Environments
When deploying applications onto production environments, security, performance, and operational agility are overriding concerns. WebLogic administrators need to be able to deploy applications quickly and with minimal manual intervention. These requirements can be satisfied without code changes using a combination of deployment descriptor and application server configurations as well as packaging applications properly and consistently across all projects.
The following packaging best practices we will review are a culmination of best practices that help to ensure applications deployed to WebLogic domains will deploy. Whether or not an application actually works after it is deployed is, of course, the concern of the developers.
Obviously, not all the specifications will apply to you or your organization, and you may not agree with all of them; what is important is to have some packaging specifications in the first instance and to be able to justify them.
PS001: Deploy applications in exploded format
Deploying applications in exploded format provides the following benefits:
If the deployment time of your application is a factor in service down time, then deploying in exploded format can reduce the risk of an SLA breach as most of deployment time is consumed by the container unzipping each application component. This benefit is magnified if you are deploying lots of separate applications or large application packages onto your servers routinely. If, on the other hand, application deployment does not cause any down time, is an uncommon activity, or you have a policy of signing your JAR files, you may not want to use this practice.
PS002: No duplicate JAR files in EARs
WebLogic follows a delegate class-loading model. Classes are loaded in the following order:
This means that JAR files placed in
Ideally, all JAR files should be defined in
For more information, refer to WebLogic Server's classloading mechanism.
PS003: JSPs, unprocessed/uncompiled annotations and source files must not be included in the EAR
Configuring WebLogic servers with a compiler on production environments is a security risk, as is including
For these reasons, all artifacts in the EAR must be fully compiled before they are deployed. JSPs must be compiled using the latest version of BEA's Appc tool that is compatible with the version of WebLogic being used by your project. Annotations must be processed and compiled using the version of apt supplied by the JDK version being used by the project.
Interestingly, one of the objections to this practice came from a developer who insisted that annotations are not compiled. I pointed him to Sun's apt tool Web site, which reads "apt first runs annotation processors that can produce new source code and other files. Next, apt can cause compilation of both original and generated source files, thus easing the development cycle." Funny how pedantic some developers can be. To be clear, the semantics of compilation or processing are a distraction. The point is to ensure only versioned binaries are deployed to live servers.
I have worked on projects where
PS004: JAR files that are supplied by the system or WebLogic classpath should not be included in the EAR
Including JAR files that are on the system or WebLogic classpath in applications can cause class-loading issues if the JAR files on these class loaders are upgraded by the infrastructure team. It also increases the size of the deliverables and increases deployment times (see PS001 and PS002). If you ever have to deploy a JAR file onto the system classpath, you should ensure that there is a valid reason for doing it. Managing JAR files on the system classpath is an overhead that is best avoided.
PS005: Ensure all EAR files include a