Some simple rules for deliverables.

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Hussein Badakhchani's Blog | August 22, 2007   2:42 AM | Comments (9)

My first thoughts were OMFGBBQ. Then I settled down to see exactly what the 60mb EAR file that I opened had inside it. To cut a long story short I'll list what I expect to see in and EAR and what I don't want to find. The said EAR broke every rule. I wont elaborate too much on the reasoning behind the rules except to say that they improve the stability, performance, security and operational agility:

• No static content. I don't want image files, html files or any other static content in an EAR. All static content should be seperated an deployed to the Web servers. This is a standard requirment for both security and performance reasons. It also greatly reduces the size of EAR files which means faster and more stable deployment.
• No JSPs, uncompiled annotations or any other source files. Having a compiler configured on live servers is a security risk, as is having tools.jar on the system classpath. Therefore all artifacts in the EAR must be compiled. Use appc and apt respectively.
• No duplicate jar files. I don't want to see xxxx.jar under WEB-INF/lib in a WAR file and then again under APP-INF/lib in the parent EAR.
• No jar files that are supplied by containers system classpath. I found database drivers, Servlet APIs and a bunch of other jars that where "cleverly" included by their Maven build process which are supplied by WLS and any other Java EE containter for that matter.
• Ensure the EAR has weblogic-application.xml and WARs/EJBs also have their respective weblogic deployment descriptors, these must be well formed and functional.
• No Maven files. I don't want to see any pom.xml files.
• Configuration files must be consistanly named and located. I don't want to see environment.properties, env.properites, envi.properties or myapp.prop in ten different locations in the EAR or WAR file. Stick to a consistent naming convention and location for application configuration files.

Anyway it seems Maven has big issues with appc and apt apart, from that the build team seem confident that they can meet the criteria I have stipulated for them. If anyone else has any good rules I could add to my list I would like to hear them.

Comments

• All pretty common sense rules, but you do seem to have a real beef with Maven ;-) What ever happened to the old days of package specs ? Do people still do them any more ? As a web-hosting team you guys should really not have to worry about the contents of packages as that should be a job for the developers, but in this case they are clearly being quite lax. A personal pet-hate of mine is properties files inside JARs inside WARs, inside the EAR. Having unzip multiple archives in development to change a property in a poorly configured application is just messy.

  Posted by: t_g_nielsen on August 22, 2007 at 3:06 AM

• Package specs would be great, in fact any specs at all would be nice. Agile development seems to have changed since I signed the manifesto all those years ago. It now seems to stand for creating a pile of rubbish with eclipse and lobbing it over the fence all the while hoping the pressure of the tight deadline you said you would meet will ensure all the quality gate that may have hampered your progress are blown open. Yes it was cheap and quick to develop and as no one is counting the support costs your an IT hero, welldone! I'm off to restart another failed server now...

  Posted by: hoos on August 22, 2007 at 3:49 AM

• Yikes Hoos. As I was reading this, I thought you were being a bit, you know, picky :-) But I realize that you are speaking from a sys admins point of view - and this kinda makes sense. If you're going to be given a *production* time EAR - it better adhere to these items. Would make a nice article if you flesh it out a little ;-)

  Posted by: jonmountjoy on August 22, 2007 at 7:36 AM

• A draft will be on it's way to you shortly :).

  Posted by: hoos on August 22, 2007 at 8:04 AM

• Hoos - I think these are good guidelines, but not hard rules. Two items specifically:

  1. APP-INF/lib is not always a viable solution. Some JARs need the classloader isolation of WEB-INF/lib. Here is an example (look for APP-INF on the page).

  2. Static files - some orgs like the encapsulated nature of an EAR as a unit of deployment. Their QA team signs off on the EAR, and then they can be sure what goes to prod is what was tested. If you deploy statics outside the EAR, what was QA'd is not as clear cut. That being said, as you point out it is best practice to put most of that stuff on a web server in high load environments.

  Regards - PJL

  Posted by: plaird on August 22, 2007 at 12:53 PM

• Peter, thanks for the comments. You're right to point out exceptions and there will always be exceptions!

  With respect to deploying static content separately, it does increase the number of delivery artifacts, complicates deployment and that puts greater demand on release management, I guess it depends on the organisation in question if their priority is simpler release management and deployment over performance and the security benefits of decoupling static and dynamic content. I should point out that a lot of the deployment complexity can be mitigated by an automated build and deployment process.

  Posted by: hoos on August 22, 2007 at 6:39 PM

• Can you always identify static content within an EAR? Or perhaps in a manifest. It should be easy enough to write something that extracts and repackages without the static content? (I'm trying to keep QA happy, and Hoos happy)

  Posted by: jonmountjoy on August 23, 2007 at 12:42 AM

• Yes, I think what is important in these cases is to have a repeatable process. Delivery artifacts > 1, but if it is scripted that may be acceptable.

  As an aside, WebLogic Portal has this issue also with configuration. A fair bit of the configuration of a WLP app is done in the database. So when promoting a WLP app to production, the EAR and static content are not the only artifacts. The configuration (called an inventory) must also be moved. WLP has a tool called the Propagation Tool to solve this aspect of the problem.

  Posted by: plaird on August 23, 2007 at 10:28 AM

• It should be straight forward for any build process and certainly those that use ANT to seperate static content from a deployable file such as an EAR. Typically you can use the fitering option in the copy command and set up patterns for html, htm, xtml, images, css, etc etc.

  Posted by: hoos on August 24, 2007 at 10:15 AM