tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan_Pie...@seagram.com (Jonathan Pierce)
Subject Re[2]: WAR Files
Date Mon, 24 Jan 2000 16:02:32 GMT
It is important to me that I be able to continue to deploy web applications by
copying war files into the specified directory, without using and special deploy
tool.  I don't care whether files are served directly from the war file, or
whether the servlet container expands the war file into a work directory when
the servlet container starts up or the first time the servlet is called.

I agree that it is okay to remove the loading from war functionality from the
core as long as it is replaced with equivalent functionality that uses expansion
of the war and doesn't require a special deployment tool or process.

-Jonathan
____________________Reply Separator____________________
Subject:    Re: WAR Files
Author: tomcat-dev@jakarta.apache.org
Date:       1/23/00 12:23 PM

> > 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"

What I wanted to say is that the spec doesn't _require_ such a feature.
An application can use whatever internal representation it choose. In the
current tomcat, and most web servers ( including Apache) files live in a
file system. 

It may be very interesting to explore serving from WAR ( or from a 
database), but I don't think we should spend too much time on it when we
have so many features that are (IMHO) more important ( like
authentication, etc). Of course, if someone wants to maintain this portion
of the code and finish it - it would be probably useful in some cases.

> > - code is complex - take a look at the code, there are too many
> > special cases added all over the code
> 
> label this feature "bad" based on the way the code ?looks? is flatly
> short sighted taking all considerations into context.

The argument was for not supporting that feature in the current code.
It may be a good feature or not - but the code is complex ( it has to deal
with the "WAR" case in many places).

It is ok to have this feature as a pluggable module. Assuming someone
wants to serve from a database - is he supposed to add another set of
"ifs" and URL rewriting ?  

> the current code is proto. what looks bad to one may not be true for all.

Almost everyone agree we should keep doing experiments and protos, but the
core shouldn't be affected by that. If it can be done in a module - it is
ok ( even if that means changes in core to be able to plug it in ).

IMO we shouldn't have "proto" code in core, and not in the code that is
executed in "default" setup. 
 
I argue for removing the code from core, I will not argue against any
feature that is provided as a module ( if someone writes and maintain it).

> 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.

James, I don't think any code is "bad", and most of the tomcat code has a
very good quality.

My statement was that the WAR handling is adds complexity, and the main
complaint of people was that the code is hard to understand. I also don't
think a "proto" code should be in the core classes, but in a module. 

I'm not rejecting a feature - I'm just suggesting that moving it in a
module will improve the readability of the code, and that's more important
than the feature itself.

( think about adding "serve-from-database" handler - do you think it's a
good idea to add it in the same way as WAR ? Wouldn't be better to
abstract it and have modules to deal with that, and core handle only the
simple and common case? )


> i don't believe the code to properly 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.

Jar from a jar still doesn't work.( i.e. libs). But again - if someone
make it work (as a module), it may be a useful feature.

Costin


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


Mime
View raw message