After reading this topic it may appear that a lot of little pieces are required in order to deploy EJB 3 components. That may not be all that far from the truth. The reality, though, is that you don’t have to keep track of all the pieces yourself; tools provided by the application servers help, and much of the glue code can be automated. You need to keep in mind some key principles, regardless of which components your application makes use of and which server you plan to deploy it to.
Packaging and deployment best practices
The following list of best practices can make your life easier while you’re building and deploying your applications:
■ Understand your application and its dependencies. Make sure that resources are configured before you deploy the application in your target environment. If an application requires a lot of resources, it is a good idea to use the deployment descriptor to communicate the dependencies for the deplorer to resolve before attempting to deploy the application. Improper packaging of classes and libraries causes a lot of class-loading issues. You also need to understand the dependency of your applications on helper classes and third-party libraries and package them accordingly. Avoid duplication of libraries in multiple places. Instead, find a way to package your applications, and configure your application server such that you can share common libraries from multiple modules within the same application.
■ Avoid using proprietary APIs and annotations. Don’t use vendor-specific tags or annotations unless it’s the only way to accomplish your task. Weigh doing so against the disadvantages, such as making your code less portable. If you are depending on proprietary behavior, check whether you can take advantage of a proprietary deployment descriptor.
■ Leverage your DBA. Work with your DBA to automate creation of any database schemas for your application. Avoid depending on the automatic table creation feature for entities, as it may not meet your production deployment requirement. Make sure that the database is configured properly, and that it does not become a bottleneck for your application. Past experience indicates that making friends with the DBA assigned to your project really helps! If your application requires other resources such as a JMS provider or LDAP-compliant security provider, then work with the appropriate administrators to configure them correctly. Again, using O/R mapping with XML and resource dependencies with XML descriptors can help you troubleshoot configuration issues without having to fiddle with the code.
Now that you have some best practices in place, what do you do when that’s still not enough? We’ll let you in on a few secrets from the trenches that will make solving those packaging problems easier.
Troubleshooting common deployment problems
This section examines some common deployment problems that you may run into. Most can be addressed by properly assembling your application.
■ ClassNotFoundException occurs when you’re attempting to dynamically load a resource that cannot be found. The reason for this exception can be a missing library at the correct loader level; you know, the JAR file containing the class that can’t be found. If you’re loading a resource or property file in your application, make sure that you use Thread.currentThread().get-ContextClassLoader().getResourceAsStream().
■ NoClassDefFoundException is thrown when code tries to instantiate an object, or when dependencies of a previously loaded class cannot be resolved. Typically, you run into this issue when all dependent libraries are not at the same class loader level.
■ ClassCastException normally is the result of duplication of classes at different levels. This occurs in the same-class, different-loader situation; that is, you try to cast a class loaded by class loader (L1) with another class instance loaded by class loader (L2).
■ NamingException is typically thrown when a JNDI lookup fails, because the container tries to inject a resource for an EJB that does not exist. The stack trace for this exception gives the details about which lookup is failing. Make sure that your dependencies on DataSources, EJBs, and other resources resolve properly.
■ Your deployment may fail due to an invalid XML deployment descriptor. Make sure that your descriptors comply with the schema. You can do this by using an IDE to build your applications instead of manually editing XML descriptor files.
Summary
At the heart of Java EE applications lies the art of assembly and packaging enterprise applications. This topic briefly introduced the concepts of class loading and code sources used by various application archives. We also explained how to package all of the EJB types, including persistence entities. You learned about the deployment descriptor of an EJB-JAR module, and how you can use descriptors to override settings specified in metadata annotations. You saw that persis-tence.xml is the only required deployment descriptor in Java EE 5. We also tackled persistence modules and the various configurations required for a persistence unit, as well as O/R mapping with XML.
Finally, we provided some best practices on packaging, and identified some common deployment issues that you may run into. In the next topic we discuss how you can use EJBs across tiers.
