RE: Re: Re: EAR/WAR Deployment

> From: Mark Phippard
>
> As for deployment, while it is true I use my tool, I was mainly referring
> to the technique of copying the files in the IFS.  I do not
> understand why
> you object to this method?  IBM supports the concept, if they didn't then
> they wouldn't have all of that documentation I pointed to.

Mark, this is not support.  Let's look at the IBM documentation:

"Locate your expanded application files. The application files are in the
directory you specified when installing the application or, if you did not
specify a custom target directory, are in the default target directory,
install_root/installedApps/cell_name. Your EAR file,
${APP_INSTALL_ROOT}/cell_name/application_name.ear, points to the target
directory. The variables.xml file for the node defines ${APP_INSTALL_ROOT}."

How do you figure out which objects need to be replaced using this method?
For example, where does cell_name come from?  Or $(APP_INSTALL_ROOT)?  Where
is variables.xml for the node?  What the heck is a node?

My point is that you can probably use this technique if you know exactly
which files are being changed, and are very well versed in the structure of
WebSphere.  With WebSphere 3.5, and to a lesser extent Tomcat, you had
complete control over these locations and could define the directory
structure in a way that made sense to you, and then simply do a one-time
configuration to configure you web application server instance to use it.

Now, you have a very strange and cryptic deployment structure that is
basically hard coded by somebody at IBM with no thought to your business.

Again, the good news is that symbolic links can save the day for the most
part.  The biggest problem is when you want to draw from multiple locations
(like a common area and a custom area).  While this is easy to do in a real
business environment like OS/400 (you simply add a library to your library
list), in Unix it's quite a bit more difficult.  There really is no concept
of a library list for many objects in Unix, especially for web application
objects.  But this is a web thing, not necessarily a WebSphere thing.

In any event, if this were truly supported, you would be able to select a
subset of your web application in WDSC and "hot deploy" it to the iSeries
with a single button.  But since there's no such thing in J2EE, WDSC doesn't
have it.  That's my problem with J2EE and with the WDSC team adhering so
tightly to the J2EE conventions.



> Other than the quantity of files involved, how is this so different from
> manually deploying some "normal" iSeries changes?  You have to
> copy source
> from one source file to another, do recompiles etc...  What does OS/400
> provide for deploying apps that isn't also provided by WebSphere?  There
> are CL commands for everything you need to do, just as there are for
> normal OS/400 changes.  I wish WebSphere came with some CL commands for
> stopping and starting applications and servers, but at least they do have
> a programming language that lets you script changes.

I disagree completely with this statement.  The concept of nested folders
with hardcoded magic names like "WEB-INF" and "cell_name" is completely
different from libraries and library lists.  If you don't recognize the
difference then you've been assimilated.

Joe