Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Date: Sun, 23 Jan 2000 19:50:50 -0800
From: James Todd <jwtodd@pacbell.net>
Subject: Re: WAR Files
To: tomcat-dev@jakarta.apache.org
Message-id: <388BCC1A.903B6156@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <Pine.LNX.4.10.10001180011120.29427-100000@costin>


costin@costin.dnt.ro wrote:

> > I have tried to run the tomcat - tests on my configuration. I found that
> > I had to expand the WAR files to make them work.
> >
> > Is this a known bug? I would like to transfer several web applications
> > from NT to our Enterprise 450, and WAR files would make a difference!
>
> It's not a bug, maybe a missing feature - but it may not be a feature
> we all want to have...
>
> WAR is intended as a way to install and transfer web applications.
> It is not a "run-time" format.

i believe "running a site from a war" does have some merits in addition
to internal expansion and as such i had begun some "exploratory work"
in tomcat to make this happen which looked promising in my opinion.
further, if tomcat was running on jdk 1.2.x, where JarURLConnection
was available, running from a war file, which is just a jar, would be
quite trivial.

that said, i'd estimate that i had this "feature" 75% completed at a "proto-
it works-it may not be pretty" state.

>
>
> The correct mechanism is to use a tool ( like a "deploy-war" program-
> it can be a command-line or a GUI or a web page or anything ), and
> that tool will "install" the war file into your server.

this may be one of the recommended means by which to deploy web
apps but surely it is not the end all ... hence the exploratory work to
make running from a war unexpanded. at some level this is a religious
issue but i want to record my opinion that i don't subscribe to the
supposed absolutes stated here.


>
>
> The current code had an attempt to serve files directly from
> War ( so user can just copy the war and use it) - but this
> is bad from several reasons, and if nobody insists enough on
> having this it will be probably removed.

>
>
> Reasons why serving from war is bad:
> - Apache ( and other servers) - static files are better served
> by apache, tomcat is not optimized for serving static files

one, although important, application configuration.


>
>
> - code is complex - take a look at the code, there are too many
> special cases added all over the code

unfortunately, and i choose not to dwell on this topic ad nauseum, there
are several areas for refactoring ... the module we are discussing at
this moment fell far below the deliverable radar line and as such only
got as much attention as i could afford it between other issues. to
label this feature "bad" based on the way the code ?looks? is flatly
short sighted taking all considerations into context.

the current code is proto. what looks bad to one may not be true for all.
this is a very subjective statement in my book. when working to implement
this feature i discovered, as others have as well, opportunities to
re-factor, clean-up, etc the code ... but i didn't run around bitching
about how "bad" the code is nor did i bias my opion as to the merits
of a feature based on the "quality" of the code. i just put the opportunities
for clean-up on a short list and proceeded accordingly.

i don't believe the code to properely implement running from a war
directly is all that complex assuming 1) a bit of refactoring in the
code base - which is why i back craig's proposal and 2) running on
jdk 1.2.x where JarURLConnection is available.


>
>
> - it is not enough - to install the application, you still
> need a deploy tool ( or manual actions). For example
> editing apache config, editing server.xml.

enough for some, perhaps the majority, but i personally feel
this feature has merits.

>
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org