This post originated from an RSS feed registered with Java Buzz
by Vinny Carpenter.
Original Post: WebLogic Deployment Bug or Feature?
Feed Title: Vinny Carpenter's Blog
Feed URL: http://www.j2eegeek.com/error.html
Feed Description: Welcome to my blog. I am a total Java geek that lives in Milwaukee, making my living as an architect/developer, spending all my time with Java, J2EE, OO, Linux, and open source. In my spare time, when I am not in front of my computers, I spend every other minute with my other loves: My wife, books, music, guitars, Formula-1 racing and StarGate. Check out my blog @ http://www.j2eegeek.com/blog
If you've haven't run into this issue yet, you'll appreciate this little nugget. I'm not sure if this is a feature or a bug in WebLogic's deployment infrastructure. I ran into this issue a while back and completely forgot about it, till I ran into it this weekend.
A little background first: Most people that deploy WebLogic in a corporate environment take advantage of the concept of domains, admin and managed servers. A domain is the basic administration unit for WebLogic Server instances and consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. For application deployment mode, WebLogic offers the ability to 'stage' your applications on the Administration server, which determines how the deployment files (ear, war, etc) are made available to target servers. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode. I personally prefer and use the stage mode where the admin server first copies the deployment unit source files to the staging directories of target servers. The target (managed) servers then deploy using their local copy of the deployment files using the redeploy feature or via a simple staggered restart. This allows for clean deployment across the cluster and HttpSession replication allows users to failover without taking an outage of the application.
This really works well unless you add another ejb jar or war file to your existing, deployed and targeted application. So I just added a new customer.war file to my existing ear file and modified the application.xml to appropriately list the new web module. You would think that deploying the new ear file with the new war file would work as expected, but alas it doesn't. WebLogic will redeploy the new ear file but not target and deploy the new war file as it wasn't explicitly deployed using the WebLogic deploy tool or the console. The managed or target servers will have the new code but the new war or ejb jar just won't be targeted and deployed on that server. Bizarre, right? I think so but I am not sure if this is a bug or a feature. To correctly target and deploy a new module that's part of an existing and currently targeted/deployed application, you will need to use weblogic.Deployer tool to tell WebLogic about the new addition to the existing ear file. Sample command:
Previous Topic
