Re: Installing a web change (was: importing a rpg orsqlrpg)

Joe asked:

>Is it your experience that the sequence of 
>events for tweaking a WebFaced screen is:
>
>1. Make a tweaks to the WebFaced JSP in WDSC
>2. Export the EAR file containing the entire application
>3. Stop WebSphere
>4. Uninstall the old EAR file
>5. Install the newly exported EAR file
>6. Restart WebSphere
>7. Test the application
>
>I'm not even doing webfacing, just some simple 
>servlets using WDSC, and I'm finding that most 
>of my time is spent stopping and restarting 
>websphere and uninstalling/reinstalling the 
>EAR file.  Is this what you're finding?

In a word, no.  There is a lot of background that I'm going to skip because
it's meaningless to the general list because I work in a Synon/COOL:2E shop.

If I need to change a JSP, I edit it in situ, either with WRKLNK or Code
(mapped drive).  Simply editing the JSP is all that needs to happen.  The
next time someone loads the JSP, WAS detects that it was changed, compiles
it and presents it.

The WAR/EAR file is really only required for the initial deployment.  If I'm
making changes to a single screen, I can export the single screen's objects
as a file system (mapped drive to IFS) and then call a CL program to copy
them onto their respective WAS tree.  Again, simply requesting the classes
gets me the changes without stopping/starting WAS.

On the topic of WAS, I strongly recommend creating your own server instance,
and not use the default instance for your stuff.  By isolating my stuff to
my instance, I was able to stop just my instance, deploy and re-start
without affecting the intranet, which ran in another instance.

Mark said:
>Once a web application is installed, virtually any change can be
>"hot-deployed" by just copying in the changed files.  WebSphere 
>will pick up the changes and automatically restart.  

"Restart" might be a misnomer.  My experience with WAS 3.5 and 4.0 indicates
that JSPs get recompiled on the fly, and changed classes get reloaded on the
fly.  I agree that the general idea is that changes to existing objects is
easy.  Just replace the object and you're good to go.

>Exceptions are mainly when creating new EJB's.  
>New/changed servlets or JSP's are a piece of cake,
>even most changes to the web.xml.

Another point of agreement.

Joe said:
>So you use a manual (drag and drop) intervention that basically 
>subverts the EAR/WAR deployment process.

Yes, for replacing existing objects.  As far as "manual" goes, I use CL
programs as much as physically possible.  A mass change (like a version
upgrade) gets the full EAR treatment.

>Remember, a typical web-faced display with,
>say, four record formats requires about 20 objects.  
>So those 20 objects get reloaded - how can you be 
>sure somebody doesn't accidentally get the old
>version of one object and the new version of another?  

You can't.  If user 1 opens her browser at 9.00 AM and leaves her desk to go
to a meeting and I change the objects, she is using the old stuff until the
next time she asks for that page.

>I suppose it's just timing and keeping your fingers crossed 
>that nobody actually accesses the system while you're changing 
>files.  

It is precisely the same issue as deploying an updated 5250 display file.
There is no development tool that can avoid this that I know of.  If I
deploy a change at the precise moment someone asks for the object, there
will be a collision.  Either the user gets the old object and the deployment
waits, or the user waits while the deployment updates the object.  Multiple
objects per "panel" means the possibility that the deployment will have
updated some, but not all of the required objects while the user is
requesting them.  In such a case, the user gets an error because the beans
don't match.  Level check, in essence.

>> For changes to servlets or supporting JAR files, or web.xml
>> it will restart the web module.
>
>Does this include the individual class files WebFacing generates?  
>Do those force a restart of the web module?

If it does a restart, it is so completely invisible that I have never
noticed it.  There is a small performance hit as the JSP gets recompiled,
but I haven't seen a hit for changed class files.

For the record, we have decided not to use WebFacing, so my practical
experience with WF and WAS is at an end.

  --buck