|
|
| Article: |
Best Practices for Building Production Quality EAR Files
|
| Subject: |
Some best practices really depend on the project |
| Date: |
2008-03-20 09:06:01 |
| From: |
jcloyd |
|
|
|
|
I think this is a fabulous article, so thanks so much for posting this level of detail. As always, applicable best practices really depend on the specific uses, so I wanted to throw out 2 things I saw as more controversial.
PS001: Deploy applications in exploded format: I often recommend that folks do not do this for a couple of reasons, the most significant of which is you really don't want people to be able to easily modify things on production servers, as it can lead to breaking a disciplined deployment cycle and can easily lead to changes made in production that never make it back into the version control system. Also, deploying as an expanded EAR means you have to handle moving code into the production environment and then expanding it consistently, so you often end up writing scripts to do exactly what is already performed by WebLogic Server. In the extreme case, I've even seen cases involving incorrect file timestamps and versions of JARs left behind throwing things off, which is prevented by moving an entire application as an archive and letting the app server worry about the details.
PS010: Static content must not be included in the EAR: This is a great recommendation for cases where you're already using a proxy plug-in and a web server, but when you're not, I wanted to clarify that it often times doesn't make sense to add a web server just for this reason. Today, more and more traditionally static content is becoming dynamic (e.g., images pulled from a content management system or user-customizable style-sheets), so in those cases there's very little true static content, so adding a web server really just introduces an additional layer of complexity and overhead that can often be best accomplished with the use of a hardware load-balancer off-loading/accelerating SSL.
--joe |
|
