wsadmin scripting (updating modules)

[Tom Parker]

Hi all,

I have been working with the wsadmin scripts recently and found a lot of
cool information, including the 5 part Tech Journal series, Barry Searles
examples, Info center docs, and some sample scripts. I can do much of what I
want, except I have a few general questions and one major issue.

The major issue is updating an existing application. An ear that contains
several web mostly modules already exists and are deployed. Over time,
individual war files need to be updated, but we want to deploy individual
modules rather than the whole ear. I first worked with this script:
AdminApp.update('MyEar', 'modulefile', "[-operation update -contents
"+appPath+" -contenturi MyWar.war -verbose -cluster
"+cluster+" -distributeApp]")
But this seems to replace the installed ear with the war file, definatly not
what I want.

Then I re-read part 5 of The Tech Journal: system management for websphere
app server v6 and it seemed to say I really need want to do a partial update
using this script instead
AdminApp.update('EMDEONEAR', 'partialapp', '[-contents '+appPath+']')
Currently when I do run this particular command I get an out of memory error
so I can't confirm this works or not until I solve that issue.

Does any one have any suggestions on what I need to update an entire web
module?

My other questions are the steps that are needed to complete the update.
Using Barry Searles scripts as a guide it seems I need something similar to
this:
1 Update app (using the AdminApp.update())
2 Save the config (using AdminConfig,save())
3 Stop Server (using AdminControl.stopServer())
4 Synch Servers (using AdminControl.invoke()
5 Start Servers ( using AdminControl.startServer()

although, that same artical suggested I could do the whole thing with:
AdminTask.updateAppOnCluster ('[-ApplicationNames app1 -timeout 600 ]')It is
all a bit confussing. Thanks for taking the time to read this postTom

[Paul Ilechko]

Tom Parker wrote:

> The major issue is updating an existing application. An ear that contains
> several web mostly modules already exists and are deployed. Over time,
> individual war files need to be updated, but we want to deploy individual
> modules rather than the whole ear.

I'm not a scripting expert, but it's a best practice to re-deploy the
EAR, not parts of it. If you have a good build process this shouldn't be
an issue.

[Tom Parker]

Hi Paul,

Thanks for your advice. I am not sure I quite agree... based on what I
understand. Atleast according to what IBM says it supports. WebSphere 6
supposedly supports fine grain deployment that allows individual modules or
subcomponents to be updated. With each war having it's own classloader, you
should be able to redeploy an individual war file without having to redepoly
the entire application, which means a host of troubles trying to restart
(getting all the users off of that machine). Why would best practices
dictate that this isn't a smart thing to do? Is there an issue with this
sort of deployment within WebSphere that I should be aware of? So far this
approach seems to work well enough in the admin console. But I would be VERY
interested in any potential issues.

Tom

"Paul Ilechko" <paul.i...@us.ibm.com> wrote in message
news:eqv6ij$is28$2...@news.boulder.ibm.com...

[Ben_]

I'm sure you understand that each and every supported feature does not
qualify for "Best Practice".

BP is that you should deploy a complete archive.

It's easier to guarantee consistency of the platform and to setup a new
environment or re-build in case of disaster.

In a year of two, when you'll need to setup an extra platform, will you be
happy to have to deploy the baseline + a dozen of incremental updates ?

Rapid deployment / hot deployment is a feature of WebSphere.

It's convenient but it has its own limitations.

Use it for what its worth: development or hot deployment in case of problem.
Not for regular updates.

If you don't have a maintenance window for down time due to the required
availability, then you need a highly-available environment, which means
redundance. And then you have the means to bring a complete application
server down without interruption of service for the users and so you have a
maintenace window.

[Paul Ilechko]

Tom Parker wrote:
> Hi Paul,
>
> Thanks for your advice. I am not sure I quite agree... based on what I
> understand. Atleast according to what IBM says it supports. WebSphere 6
> supposedly supports fine grain deployment that allows individual modules or
> subcomponents to be updated. With each war having it's own classloader, you
> should be able to redeploy an individual war file without having to redepoly
> the entire application, which means a host of troubles trying to restart
> (getting all the users off of that machine). Why would best practices
> dictate that this isn't a smart thing to do? Is there an issue with this
> sort of deployment within WebSphere that I should be aware of? So far this
> approach seems to work well enough in the admin console. But I would be VERY
> interested in any potential issues.
>
> Tom

Ben pretty much gave you my answer. It's really all about consistency,
and knowing what you have in a given build.

[Tom Parker]

Hi Ben
Thanks for responding. Interesting information that I wasn't quite aware of.
Can you go into why this is best practice, as I am not sure I follow. What
exactly would become inconsitant? The applications, the server, or both? For
an application, I would argue that Clear Case (or any code repository)
should manage the module versions and each server simply runs the most
uptodate version. Each module is kept upto date and a new platform gets
deployed with a complete ear with all the current Modules. Exisiting servers
get updated only as needed via a new war. There are no installs plus
incremental patches. Maintenance is pretty simple. So if I understand what
your saying correctly, I don't see inconsistency from an application
perspective. Am I missing something?.

What may be an issue is how does the server restart and can their be issues
from deploying and restarting only a module. I think there could be
potential problems with dependencies in that case. But I am not sure and
havn't heard of any. But for me, finding some of this info is difficult.

I guess what I am getting at is I would like to know what are the issues
explicitly so I can account for them. I would like to deploy the entire
application if given the choice, but the powers that be prefer to run
minimal updates. I suppose the less items that change equals the less risk.
If I update only one module, the chances other modules having an issue is
less that reinstalling the complete app.More potential for something going
wrong.

Are there any resources I could look at that discuss these issues? Nothing I
found seemed to discuss this. The closest is Barry Searls, and that actually
talked about the issues of bringing the whole server down and how to get the
requests off the machine onto another along with several other concerns with
updating an entire application.

Thanks for taking the time.
Tom

"Ben_" <re...@newsgroup.com> wrote in message
news:erfg2b$1io18$1...@news.boulder.ibm.com...

[Tom Parker]

Thanks Paul,

What is in any given build should be what version is in the SCM system. I
don't see the inconsistancy in this approach.

Tom

"Paul Ilechko" <paul.i...@us.ibm.com> wrote in message

news:erfijo$1jk24$1...@news.boulder.ibm.com...

[Ben_]

Answer this one for yourself: when you rebuild the environment, will you be
happy to have to deploy the baseline (EAR) + a dozen of incremental updates
(WAR) and will you stand without fear to have forgotten a patch ?

[Tom Parker]

Thanks Ben. Unfortunatly I don't think we are talking on the same page. The
ear is always rebuilt and current, there are no patches. For example, assume
I install a new ear project and randomly update each war module every week.
Then your saying I need to reinstall that ear and apply all those patches to
a new system, correct? That is not correct in my case. A SCM system manages
our code. Each module allways contains the current version in the SCM. The
ear is always built out of SCM complete with major and minor versions (minor
being patches). If I install a new system, I don't save a copy of the ear
file that was deployed weeks or months ago, then install the patches, I
simply create an ear out of every thing in the ClearCase repository. No
forgotten patch. Or are we talking something different?

But in any case, back to the topic on hand, I take it that scripting an
update is not common and I need to work it out if I want to actually do it?

Thanks for your input and patients
Tom

"Ben_" <re...@newsgroup.com> wrote in message

news:ergs2s$1ro7m$1...@news.boulder.ibm.com...

[Peter Bennett]

http://websphere.sys-con.com/read/48335.htm
is an interesting article in this area.
It also points to: -
http://www-128.ibm.com/developerworks/websphere/library/samples/SampleScripts.html
Which is handy

Peter
DSPS
"Tom Parker" <tpa...@qacps.com> wrote in message
news:eqtbut$1a02i$1...@news.boulder.ibm.com...

[Peter Bennett]

Tom, have you looked at WebSphere Rapid Deployment rather than
doing it from wsadmin?
I know that does classes, modules or whole EARs.

Peter Bennett
Distributed Systems Professional Services Ltd.

"Tom Parker" <tpa...@qacps.com> wrote in message
news:eqtbut$1a02i$1...@news.boulder.ibm.com...