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

> From: Mark Phippard
>
> Except for the WEB-INF part, which I think came from Tomcat, I do not
> agree.

Then we're going to disagree.  I think any deployment model that makes
assumptions about your system architecture and file layouts is wrong.

>  The deployment model is designed to make it easy for an
> application
> vendor to package up a complex application (using the deployment
> descriptors) in a way that makes it easy for the recipient of the
> application to install it.

Hmmm.  Which is easier and more copmrehensive?  EAR/WAR or InstallShield?
Even RPM is smarter than EAR/WAR, which is little more than a big fat ZIP
file.


> The architecture works exceptionally well at this.  What
> it is not particularly well suited for is the sort of internally developed
> applications that are commonly seen in the iSeries world.

Again, I submit that if you want an example of good deployment, use
something like InstallShield, and with none of the braindead limitiations.


> Also, in a simple JSP/Servlet application there is a degree of overkill to
> it, but the architecture was clearly designed at a point in time when it
> looked like EJB's were going to be more widely used.  It would be
> extremely
> difficult to install an app containing EJB's without this architecture.

Whoo, now you're talking my language... so we're saddled with a fat,
overblown installation mechanism that nobody needs because it was designed
to support a fat, overblown architecture that nobody uses.  Yeah, them's
good reasons, alright.


> Wrong.  WebSphere and every other app server I know of absolutely support
> this.  Once the application is installed the first time it can then be
> updated by simply copying in the changed files.

Gz Louise!  This is a MANUAL operation!  I am dumbfounded that you think
this makes sense - use a fat, overengineered installation program that
limits your architecture, and which can only be updated by manually copying
files.  I cannot fathom this - evidently I developed applications in some
alternate universe where we actually thought about the end user.


> > Or shared resources between WAR files, or any of a number of
> other things
> > that are required for real application development.
>
> At least in 5.0 (which might be a newer J2EE version) there is a place in
> the EAR file structure to put common code in the form of JAR files.

Ooh goodie!  One level of shared files!  Now what if I want two EARs to
share files?  I'm sorry, but the hierarchical design of EAR/WAR doesn't fit
in with the concept of a development environment where different resources
are shared among different parts of the application.  And heaven help us if
I want to somehow integrate two DIFFERENT applications.

Hey... if four applications use the same JAR file, and I install all four,
how many copies of the JAR file do I have?


> I will admit that when WebSphere 4 first came out I didn't understand the
> change, but it is about standards and compatibility.

This is the mantra that is going to KILL us.  These are NOT standards, they
are conventions, and they are BAD conventions at that!  You are willing to
live with WEB-INF because some Jolt-hyped Unix geek thought it was a good
name.


> I can take an
> application that I develop for WAS 4 or 5 and very easily package it in an
> EAR file and deploy it on Tomcat, WebLogic, Sun One or any other
> J2EE-compliant server.

Great.  But if you did it with a little forethought, then you'd be able to
do it without a stupid ZIP file.


> I assume you are talking about how you would have designed it, not the
> reality.  Because, at least with WebSphere, you cannot in fact deploy your
> application this way.  Even a PSC/400 app must be packaged as a
> WAR or EAR.

Wrong.  WebSphere 3.5 required no EAR/WAR file.  WebSphere 5 does, but only
because there's no decent way to configure it.  So far I have found no way
around having to create a dummy application with nothing in it just so I can
access my directory structure.  Stupid, stupid, stupid.


> I do not know the fine details of your architecture, but I will
> bite.  What
> if I want to do some customizations to the JSP?  How do I then deploy my
> changes from QA to Production?  Eventually, whether it is WebFacing or
> PSC/400 or homegrown, I need to know the files I changed so they can be
> managed properly.

Easy.  PSC/400 has an API that will return a list of generated objects.  YOU
can choose whether these objects are generated into QA or directly into
production, so you can tailor the process to your development cycle.  You
don't tailor your development cycle to my idea of what an application is.
That would be STUPID.

As you might guess, I think this concept of "standards" is simply a crutch
used by really laxy programmers to justify not doing the work of developing
a real application environment.  And this is not a WebFacing thing, it's a
J2EE thing.  The entire J2EE architecture was designed by people who have
little or no concept of deploying and maintaining living, breathing
applications in a real world environment.

Anyway, you're as unlikely to change my mind as I am yours.  I am stuck
dealing with this junk because people like you think your job should be
easy.  Fine.  I'll do it.  But I don't have to like it.  And when your job
is outsourced to someone who make five bucks an hour because they can push
the buttons as good as you can, don't come whining to me.

Joe