Nic, Please notice that I prefaced my comment "from an operations perspective". Prior to the "ear" way of doing things, any servlet mappings, security mappings, etc, needed changes in the application server configuration as well as the corresponding code changes. We found this to be an error prone way of doing application code migrations (from test, to qa, to prod). We eventually got xml configuration scripts put together that eliminated most of the human intervention required for each code migration, but not all.
By virtue of having deployment descriptors embedded in the application "ear" file, we were able to completely script code migrations from our source code management tool. You are correct in that it makes more work for the application developers. It can be a pain to create a new "version" to correct a typo in a jsp, however, many of our developers use tools such as WebSphere Studio to generate all the deployment artifacts which are checked in as part of the application then have ant scripts that actually build the ear. We then have "online forms" that the "authorized signers" use to invoke our scripted "deploy" process. The developers now need to understand more of the configuration & mapping aspects of there application than they did before in order to create the deployment descriptors, but it helps to provide a consistent "configuration" of the applications from the unit testing environments clear through to production. Also, prior to the "ear" way of doing things, we had seen several instances of our various lines of businesses development teams taking several changes to test, then qa, without taking them to prod. Then when they decided to take a particular new feature into prod, they might miss some dependent class and have difficulty determining why prod was acting "flaky". Granted, this is really a version control issue, but with "ear" files, if the application was tested in qa, then the same "ear" file was deployed in prod. -----Original Message----- From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED] Behalf Of Nic Ferrier Sent: Wednesday, October 20, 2004 9:16 AM To: [EMAIL PROTECTED] Subject: Re: (New subscriber) "Busy Page" Zerbe John W <[EMAIL PROTECTED]> writes: > Nic > From an operations perspective, I happen to like the "ear" files. > In a shop running 30-40 distinct J2EE (WebSphere)applications in > three "clustered" environments (test, qa, prod), ear files are > much easier to version, track, and deploy/distribute than what > we used to have to manage prior to their existence. Don't you find that the versions balloon when you start using them? I found it more difficult to keep track of version control. But I'm guess I'm used to doing things in a particular way and I try to make ears fit into that rather than changing the way I do things to the 'ear way'. > Yes, it can be a pain to assemble your first ear file, but you > generally script it as part of your application build process. I find it a pain every time I do it. And I've done 50 or 60 times now. /8-> Nic ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator.(A) ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
