Building and deploying your WebLogic domain Part 2

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Hussein Badakhchani's Blog | December 30, 2006  12:36 AM | Comments (8)

I'll start this entry by briefly recapping the two metrics I used to measure the performance of our old build process discussed in my last entry:

• Build time. If it takes you longer than a few minutes to build your domain, you should be asking why?
• Work time. If it takes you longer than a few minutes to make a configuration change to your domain, you should be asking why?

I have yet to hear a valid reason why a standard WLS domain (e.g. not a Portal domain) should take longer than a few minutes to build, if you think you've got one please post a comment on this entry. The main reason I come across is that the build process is "Dynamic" i.e the domain is created using WLSHELL or WLST. In my experience these domains take between 10 - 40 minutes to build. If you use these tools to build your domains please post a comment on the time it takes you. If you're happy with this time and it meets your requirements, well thats marvelous. After about the fourth time I rebuilt and deployed a domain of ours to fix multiple configuration issues, a process that took about 90 minutes (after two days spent trying to figure out exactly where to make the changes), It was plain to me that a 20 minute cycle was not acceptable for us. So there you have it, this is why I believe these two metrics are important. As the old cliche mandates time is money.

The third metric I want to discuss falls under the category of complexity, specifically the number of files in your build process that it takes to build your domain. I appreciate that measuring complexity in this way is blunt to say the least but we have start somewhere and in my experience it is a worthwhile measure. Latter on I'll discuss another form of complexity that is can't be measured easily but can be avoided. In my original rant I noted that our build process had no less than 69 files to describe a our WLS domain, thats property files and templates. How many files does your build process use?

In an effort to cap the number of files required to build our domain we came up with the following directory structure for Choom (the version on Choom that will be released in codeshare will be even simpler):

Choom stores property files in the properties directory and templates in, erm, the templates directory, no surprises there. In my last entry I described the hierarchical nature of the properties, this hierarchy is observed in the directory structure.

Directly under the properties directory we find common.properties. You guessed it, these properties are common to ALL our domains. Now there aren't many properties in this file but this does not diminish its importance, you see, the more properties you can define in this file, the more standardised your domans will be and standardised domains mean less maintenance effort.

Under the domains directory we store the properties for the various domains. Each domain type is named, for instance, we can see depicted the mydomain type. Typically the domain type is named after the project it belongs to. Domain level properties are stored under the domain type directory. As before the more poperties we store at this level as opposed to the environment level the more standardised our domains become.

The templates generally follow the same naming and oragnisational conventions. If you read my last entry on this subject you may have noticed that the use nomenclature is a key tool in reducing complexity. By adhering to some simple conventions for naming files, properties and tokens it becomes easy to locate and make changes to configuration values.

When we first embarked on creating our new build process I wanted to make sure that we stuck to just that, creating a process to build our domains rather than an application that builds our domains. This is why I really wanted to use Ant rather than a programming language. I have come across home made build applications written in Java, Lisp, Scheme and of course Jython/WLST and in almost every instance you find a build team that is not only responsible for environment provisioning but also has to support their miserable build application, yet another reinvented square wheel. This is a surefire way to inject a huge amount of complexity into your build process and I maintain it is completely unnecessary for the vast majority of WLS domains. I should qualify this by saying that Jython and WLST have an extremely valuable role in build verification and environment prooving and my next entry will describe how we exploited these features in choom.

Comments

• An interesting article. I have used some of your suggestions in the building and deploying of my WLS application. I was wondering what you use for release control of application builds from the source control system. I was wondering if you had any thoughts about Maven. All my current build is done using ant command line scripts. I am looking for a tool or framework to formalize the release of a build into testing and production. Thanks Ramdas

  Posted by: ramdas on March 6, 2007 at 3:45 PM

• Thanks for the feedback Ramdas I hope you found the suggestions useful. We do use a source code control system but in a very simple fashion. I have found building infrastructure components does not require the same level of source control as application source code. For example we typically find there is no need for branching. Curretly we have clearcase setup to automatically update everyones views as soon as one person makes a change and we deliver code to the build users view every night.

  We all build from the trunk and the build always marches forward, every time we finish a new template we label the build and continue moving forward. One day we may require more sophisticated use of CM but to be honest I see no requirement for this.

  With respect to Maven it may be useful for keeping track of and building software products but I don't see it being of any use in building infrastructure or applications. I may be wrong but if I can live without it now I have to ask what does it have that I am missing? I'm not interested in integration with eclipse ;)

  If you're interested I have started a project on codeshare called genesis that takes choom to the next level. We are in the planning phase right now and your feedback would be most welcome.

  Posted by: hoos on March 10, 2007 at 4:44 AM

• Hoos, Thanks for your thoughts on Maven. On a similar topic, i have been debating where to package the 3rd party JARs when creating and deploying the EAR. Currently i am not consistent - some of the JARs are in the /lib folder and some are packaged in the META-INF/lib folder of the corresponding JARs within the EAR file. I would prefer to have all the stuff packaged in the EAR, but then i noticed that the size of the EAR file was growing given the size of some of these 3rd party JARs - especially these days with opensource frameworks and their dependancies. What are your thoughts on where to have these JARs? Thanks

  Posted by: ramdas on March 12, 2007 at 7:06 PM

• Thats a good question, if your using WLS9+ then consider deploying your jars as seprate libraries. I have not tried this myself due to time constraints but the principle seems sound. Let me know if you do try this out. Otherwise I suggest placing your jars in the APP-INF/lib folder of the EAR and removing them from the orginal EJB/WAR files. Be careful though, make sure you test the app after every change to the packaging.

  When you say your EARs grow in size I'm not sure what the problem is. For instance say you are deploying two EJBs in an ear file and each EJB has it's own copy of a dependant jar in it's META-INF/lib directory then placing one copy of this jar in the APP-INF/lib of the EAR and removing the ones in the EJB should result in an overall decrease in size. Please expain if I have misunderstood you.

  Posted by: hoos on March 12, 2007 at 7:21 PM

• Hoos, I am using WLS9.2 and i have read about the concept of deployable libraries.. will go back to it and see if it fits into my framework. When i said, the size of the EAR is big, i was not referring to 3rd party JARS being duplicated between the various modules within the EAR (viz. WS, UI, EJB) but the fact that if these 3rd party JARS could be removed all together from the EAR and be made available in a place where the WLS servers could load them during startup (viz. /lib). One obvious downside of this is that when deploying such JARS to a cluster, i would have to make sure these 3rd party JARS are sync'd up to all the managed servers in the cluster. If they were all part of a single EAR, I would be limiting the number of files to be deployed to the various managed servers to a smaller number (ideally 1) which would be simpler to administer and manage. Any thoughts? Thanks

  Posted by: ramdas on March 13, 2007 at 12:33 PM

• Ramdas, limiting the number of deployments to clusters is a good idea, and it's good that your thinking about it. I currently have to deal with a cluster onto which we deploy over 20 EARs, I consider this to be plain wrong. It is a perfet example of a lack of appreciation for operational requirements.

  Ensuring the correct version of each application is installed on every machine in the cultser is something our build, installation and deployment processes are responsible for e.g. we use ssh to execute scripts that check the versions of the binaries on all machines before deployment commences.

  On production servers we enable cluster constraints which fails deployments of applications with different deltas.

  Have a read of the various deployment options available, I prefer nostage and external deployment options to staging as I have found staging took a long time, but your situation may be different.

  Posted by: hoos on March 15, 2007 at 3:45 PM

• Hoos, where would you package 3rd party JARS like JSF and other open-source frameworks which are used by the modules within the EAR - these are not necessarily shared between the various modules in the EAR. Currently i have these JARs in many different places(EAR/APP-INF/lib, EAR/WAR/WEB-INF/lib ....). BEA recommends in some places to place 3rd party JARS in the APP-INF/lib folder which is at the EAR level and then at other places in the document i see it recommending to be added to the WEB-INF/lib folder at the web JAR level - and then in some other parts of the doc it says to place these completely outside the EAR but in the Domain system classpath via the /lib folder... i am confused...

  Posted by: ramdas on March 16, 2007 at 7:31 PM

• I wish I had listened to this advice a little more about using ant to build the domain rather than WLST. I've taken us down the WLST path of configuring domain templates and unpacking them to the servers. For the most part it works rather well. Unfortunately there are missing pieces - for instance you can't pre-configure logs to 'rotate on startup' or to limit the number of log files. Oh you may set those values in your template, but they are lost when you unpack or write the domain. I'm also running into similar problems with the assignment of some resources to a target or cluster when configuring the template. So for now we are having to use the console to re-configure after building the domain, and next we'll use WLST to connect to a newly built domain and re-configure then bounce. I want an administration/configuration API that is not deprecated and is fully functional.

  Posted by: ejjohnson on August 6, 2007 at 8:33 AM