Re: WAR Files

[co...@costin.dnt.ro]

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

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.

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.

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

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


Costin

Jikes for JSP compilation is broken

[Hans Bergsten <ha...@gefionsoftware.com>]

The support for using Jikes to compile JSP pages, added through the PluginJavaCompiler 
class, was broken by the latest changes done in org.apache.jasper.compilerCompiler
submitted by Preston, committed by Sam (version 1.6).

The change is described as "Additional EBCDIC support". What breaks Jikes support
is that the -encode option is now always passed as a compiler argument, and Jikes
doesn't support it. This particular change is marked as "perhaps debatable?". Does
this mean it can be removed without breaking EBCDIC support again?

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: WAR Files

[Jason Hunter <jh...@acm.org>]

costin@costin.dnt.ro wrote:

> > Since it's executable code it will do *something* when there's a
> > space in the filename, whether we plan for it or not.  I figure
> > it would be good if we thought about it beforehand.
> 
> Ignore ? Yes, we need to have a plan for that, but probably we
> shouldn't make the code too complex from start, but wait for feedback.

I think if we do nothing special in the code we get good behavior -- we
simply get a context prefix with a space in it so /some+root/ and
/some%20root/ both resolve to that web app.

Only open issue now is, what name to choose for the default web app?
.../webapps/default?  .../webapps/root?

-jh-

Re: WAR Files

[co...@costin.dnt.ro]

> > The convention should be: if you use cp as delpoy-tool, the file name
> > will be the java-encoded path ( I think that's / replaced with %2F -
> > or any other convention you want ).
> 
> Since it's executable code it will do *something* when there's a 
> space in the filename, whether we plan for it or not.  I figure 
> it would be good if we thought about it beforehand.

Ignore ? Yes, we need to have a plan for that, but probably we 
shouldn't make the code too complex from start, but wait for feedback.

> > It is not completely possible - if you add a context to tomcat,
> >  it will not be visible in apache unless you restart apache too
> > ( the good news - restart in apache doesn't mean stop and start,
> > it will be a smooth restart ).
> 
> That sounds fine to me.  Add a context, restart both servers.  You
> mentioned a "deploycheck" trick so that starting Apache and then 
> Tomcat will work.  How's "deploycheck" work?

I don't know yet all the details, just that we need something that
will generate apache configs for tomcat, and we need something 
to restart apache if a context changes. 

Costin

Re: WAR Files

[Jason Hunter <jh...@acm.org>]

costin@costin.dnt.ro wrote:
> 
> > Excellent point!  But it makes me wonder what we should do if the
> > filename has a space or other URL-unfriendly character in it?  Seems
> > we could still make the filename the context prefix path, but client
> > requests will have to URL-encode the space and other characters. 
> > That should work, eh?
> 
> Well, let's solve the common and simple case, and let special cases
> to server.xml ( with the hope that normal users will not get into
> this kind of situations ).
> 
> The convention should be: if you use cp as delpoy-tool, the file name
> will be the java-encoded path ( I think that's / replaced with %2F -
> or any other convention you want ).

Since it's executable code it will do *something* when there's a 
space in the filename, whether we plan for it or not.  I figure 
it would be good if we thought about it beforehand.

> It is not completely possible - if you add a context to tomcat,
>  it will not be visible in apache unless you restart apache too
> ( the good news - restart in apache doesn't mean stop and start,
> it will be a smooth restart ).

That sounds fine to me.  Add a context, restart both servers.  You
mentioned a "deploycheck" trick so that starting Apache and then 
Tomcat will work.  How's "deploycheck" work?

-jh-

Re: WAR Files

[co...@costin.dnt.ro]

> Excellent point!  But it makes me wonder what we should do if the
> filename has a space or other URL-unfriendly character in it?  Seems 
> we could still make the filename the context prefix path, but client
> requests will have to URL-encode the space and other characters.  That
> should work, eh?

Well, let's solve the common and simple case, and let special cases 
to server.xml ( with the hope that normal users will not get into 
this kind of situations ).

The convention should be: if you use cp as delpoy-tool, the file name
will be the java-encoded path ( I think that's / replaced with %2F - or
any other convention you want ). 

> > - a "deploycheck" will start tomcat with no connectors, so that
> > expansion and apache config happens.
> > - when you start apache and tomcat, everything is set up, including
> > the apache side.
> > 
> > What do you think?
> 
> Does this solution allow you to start and stop Apache and Tomcat 
> fully independently of each other as is currently possible?

It is not completely possible - if you add a context to tomcat,
 it will not be visible in apache unless you restart apache too
( the good news - restart in apache doesn't mean stop and start,
it will be a smooth restart ).

( reason - you can't change the config at runtime in apache ).

The intention is to shield the user from dealing with apache
or tomcat config if he doesn't want to do something really special.

Costin

Re: WAR Files

[Jason Hunter <jh...@acm.org>]

costin@costin.dnt.ro wrote:

> Yes, except one thing - for /multi/level contexts you can use the
> java encoded path if you don't want to edit server.xml.
> That means cp will work for all cases, not only "first" level.

Excellent point!  But it makes me wonder what we should do if the
filename has a space or other URL-unfriendly character in it?  Seems 
we could still make the filename the context prefix path, but client
requests will have to URL-encode the space and other characters.  That
should work, eh?

> The implementation will read the files at startup - and probably
> will also generate apache config info.
> One problem I found is that apache will read the config info only
> at startup - so I'll try the following trick:
> 
> - a "deploycheck" will start tomcat with no connectors, so that
> expansion and apache config happens.
> - when you start apache and tomcat, everything is set up, including
> the apache side.
> 
> What do you think?

Does this solution allow you to start and stop Apache and Tomcat 
fully independently of each other as is currently possible?

-jh-

Re: WAR Files

[co...@costin.dnt.ro]

> Great!  The way I see it is that server_root/webapps is the directory
> base for web apps that are to be auto-detected.  .../webapps/foo would
> contain the "/foo" web app.  .../webapps/bar.war would contain the
> "/bar" web app.  In case of collision with webapps/bap and
> webapps/bap.war, the directory wins (cuz it's an arbitrary choice and
> reading from a dir is easier because it avoids the WAR expansion).
>
> The server will read the contents of webapps at startup but not
> afterward.  There will be no way to assign a "/multi/level" context
> prefix except by editing server.xml.
>
> Sound like the right approach to everyone?  Does this match what you had
> in mind, Costin?

Yes, except one thing - for /multi/level contexts you can use the
java encoded path if you don't want to edit server.xml.
That means cp will work for all cases, not only "first" level.

The implementation will read the files at startup - and probably
will also generate apache config info.
One problem I found is that apache will read the config info only
at startup - so I'll try the following trick:

- a "deploycheck" will start tomcat with no connectors, so that
expansion and apache config happens.
- when you start apache and tomcat, everything is set up, including
the apache side.

What do you think?

Costin

Re: WAR Files

[James Todd <jw...@pacbell.net>]

i'd like to see the implementation to support both internal expansion
(as it defaults today) and running from a war. the code to support
this shouldn't be that intrusive if coupled with some other refactoring
initiatives ... imho.

hope this helps,

- james

Jason Hunter wrote:

> > Yes, I agree the user shouldn't edit any config file or shouldn't
> > unjar any file.
> > ( and it's very simple to do that - using a deploy program )
>
> I think "cp" is a file deploy program.  :-)  Copy one file to the
> standard location, and things just work.  Slick!
>
> > Expanding the war at startup is a good solution ( which should work
> > with the current tomcat ).
>
> Right, and no one but us server implementors need to know that
> internally we expand it.  Think of the expansion like an on-disk cache.
> :-)
>
> > What I don't like is the  code that tries to deal with serving out of
> > unexpanded war files, and all classloader tricks ( loading a jar file
> > from a jar for libs, special cases in mappings, etc).
>
> I agree that's a pain.  Cool, but not mandatory.
>
> > We still have most of the code in, if someone wants to fix
> > it, but I would be very happy if we could just remove it -
> > we have more important things to fix.
>
> James Todd will know best on whether we should leave that code in or
> not.
>
> > > I liked your idea of a "webapps" directory where (by default) all direct
> > > subdirs were automatically treated as individual web apps.  We could do
> > > the same with WAR files.  A webapps/foo.war would default manage the
> > > /foo context.  No configuration would be required, unless you wanted
> > > something custom.
> >
> > > What's the status of that effort, by the way?
> >
> > After we burn M1 we can start doing changes again, and since
> > nobody said -1, probably the change will be done very soon.
>
> Great!  The way I see it is that server_root/webapps is the directory
> base for web apps that are to be auto-detected.  .../webapps/foo would
> contain the "/foo" web app.  .../webapps/bar.war would contain the
> "/bar" web app.  In case of collision with webapps/bap and
> webapps/bap.war, the directory wins (cuz it's an arbitrary choice and
> reading from a dir is easier because it avoids the WAR expansion).
>
> The server will read the contents of webapps at startup but not
> afterward.  There will be no way to assign a "/multi/level" context
> prefix except by editing server.xml.
>
> The auto-detected contexts should have default values for
> defaultSessionTimeOut, isWorkDirPersistent, etc that match those
> currently used for the default context.  If the user wants to override
> these values, an entry can be made to server.xml.
>
> Sound like the right approach to everyone?  Does this match what you had
> in mind, Costin?
>
> -jh-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: WAR Files

[Jason Hunter <jh...@acm.org>]

> Yes, I agree the user shouldn't edit any config file or shouldn't
> unjar any file.
> ( and it's very simple to do that - using a deploy program )

I think "cp" is a file deploy program.  :-)  Copy one file to the
standard location, and things just work.  Slick!

> Expanding the war at startup is a good solution ( which should work
> with the current tomcat ).

Right, and no one but us server implementors need to know that
internally we expand it.  Think of the expansion like an on-disk cache. 
:-)

> What I don't like is the  code that tries to deal with serving out of
> unexpanded war files, and all classloader tricks ( loading a jar file
> from a jar for libs, special cases in mappings, etc).

I agree that's a pain.  Cool, but not mandatory.

> We still have most of the code in, if someone wants to fix
> it, but I would be very happy if we could just remove it -
> we have more important things to fix.

James Todd will know best on whether we should leave that code in or
not.

> > I liked your idea of a "webapps" directory where (by default) all direct
> > subdirs were automatically treated as individual web apps.  We could do
> > the same with WAR files.  A webapps/foo.war would default manage the
> > /foo context.  No configuration would be required, unless you wanted
> > something custom.
> 
> > What's the status of that effort, by the way?
> 
> After we burn M1 we can start doing changes again, and since
> nobody said -1, probably the change will be done very soon.

Great!  The way I see it is that server_root/webapps is the directory
base for web apps that are to be auto-detected.  .../webapps/foo would
contain the "/foo" web app.  .../webapps/bar.war would contain the
"/bar" web app.  In case of collision with webapps/bap and
webapps/bap.war, the directory wins (cuz it's an arbitrary choice and
reading from a dir is easier because it avoids the WAR expansion).  

The server will read the contents of webapps at startup but not
afterward.  There will be no way to assign a "/multi/level" context
prefix except by editing server.xml.  

The auto-detected contexts should have default values for
defaultSessionTimeOut, isWorkDirPersistent, etc that match those
currently used for the default context.  If the user wants to override
these values, an entry can be made to server.xml.

Sound like the right approach to everyone?  Does this match what you had
in mind, Costin?

-jh-

Re: WAR Files

[co...@costin.dnt.ro]

> > What I don't like is the  code that tries to deal with serving out of
> > unexpanded war files, and all classloader tricks ( loading a jar file
> > from a jar for libs, special cases in mappings, etc).
> 
> sorry the code causes you such distress. i believe if we ran on jdk1.2.x
> that the class loader would be much cleaner. this was my intention.

I like many of the tricks in the code ( I always like tricks and hacks),
but not in the core! That's all I want with the unexpanded war - move it
to a module.

Do you think serving from unexpanded WAR is simpler ? What about tomcat
integrated with Apache or another web server?  Right now serving files
from the file system is something familiar for most people - that's the
way most servers work. I think that should be the default for tomcat too.

Do we want to deal with multiple internal representations ? Yes, I would
be interested in a module that will pick files from a database, but not in
the core, in a module. 

The reason starting from scratch is such a popular alternative is that
tomcat is too complex - and some people believe a better architecture
will keep it from becoming complex. But the complexity in the current code
is mostly due to features and requirements in the servlet API ( request
dispatcher, etc) - and removing features from core and moving  to 
modules is good. 

Costin

Re: WAR Files

[James Todd <jw...@pacbell.net>]

costin@costin.dnt.ro wrote:

> > I believe strongly that servers must support installing web apps as a
> > single archive file.  In fact, I think the spec makes this a requirement
> > (though my PDF viewer on this machine is failing so I can't be sure).
>
> Yes, I agree the user shouldn't edit any config file or shouldn't
> unjar any file.
> ( and it's very simple to do that - using a deploy program )
>
> Expanding the war at startup is a good solution ( which should work
> with the current tomcat ).

this was and probably still is working. there is some "internal request
mapping" hackery which was needed to pull this off which some may
think is bad/ugly/yadaYadaYada/booHooBooHoo ... but the fact is
the feature works and contingent upon other refactoring initiatives
could use some tlc as well.


>
>
> What I don't like is the  code that tries to deal with serving out of
> unexpanded war files, and all classloader tricks ( loading a jar file
> from a jar for libs, special cases in mappings, etc).

sorry the code causes you such distress. i believe if we ran on jdk1.2.x
that the class loader would be much cleaner. this was my intention.

further, with a bit'o refactoring in the DefaultServlet (and associated
kin) the fact that the war is expanded or not would be virtually
transparent.


>
>
> We still have most of the code in, if someone wants to fix
> it, but I would be very happy if we could just remove it -
> we have more important things to fix.

if it doesn't break anything and someone is interested in picking
it up why remove it?

>
>
> > > - 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.
> >
> > I liked your idea of a "webapps" directory where (by default) all direct
> > subdirs were automatically treated as individual web apps.  We could do
> > the same with WAR files.  A webapps/foo.war would default manage the
> > /foo context.  No configuration would be required, unless you wanted
> > something custom.
>
> > What's the status of that effort, by the way?
>
> After we burn M1 we can start doing changes again, and since
> nobody said -1, probably the change will be done very soon.
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: WAR Files

[co...@costin.dnt.ro]

> I believe strongly that servers must support installing web apps as a
> single archive file.  In fact, I think the spec makes this a requirement
> (though my PDF viewer on this machine is failing so I can't be sure).

Yes, I agree the user shouldn't edit any config file or shouldn't
unjar any file.
( and it's very simple to do that - using a deploy program )

Expanding the war at startup is a good solution ( which should work
with the current tomcat ).

What I don't like is the  code that tries to deal with serving out of
unexpanded war files, and all classloader tricks ( loading a jar file
from a jar for libs, special cases in mappings, etc).

We still have most of the code in, if someone wants to fix
it, but I would be very happy if we could just remove it -
we have more important things to fix.


> > - 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.
>
> I liked your idea of a "webapps" directory where (by default) all direct
> subdirs were automatically treated as individual web apps.  We could do
> the same with WAR files.  A webapps/foo.war would default manage the
> /foo context.  No configuration would be required, unless you wanted
> something custom.

> What's the status of that effort, by the way?

After we burn M1 we can start doing changes again, and since
nobody said -1, probably the change will be done very soon.

Costin

Re: WAR Files

[Jason Hunter <jh...@acm.org>]

costin@costin.dnt.ro wrote:
> 
> 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.

I believe strongly that servers must support installing web apps as a
single archive file.  In fact, I think the spec makes this a requirement
(though my PDF viewer on this machine is failing so I can't be sure).

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

So let Apache internally expand the WAR.  That's fine, so long as to the
user's perspective it appears like the WAR file is being used directly. 
This internal expansion is what Tomcat used to do.  I don't think that
changed.  That's what the isWARExpanded flag's about.

Costin's point about serving directly from a WAR is true on some
servers, but that doesn't mean we can't imitate it from the user's
perspective.  That's what's important.
 
> - code is complex - take a look at the code, there are too many
> special cases added all over the code

Internally expanding makes for elegant code, and if we had designed the
server with WAR expansion in mind it could have been elegant. 
Meanwhile, I don't mind inelegant code if it makes the user's life
easier.  Single file installs are just cool!  :-)

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

I liked your idea of a "webapps" directory where (by default) all direct
subdirs were automatically treated as individual web apps.  We could do
the same with WAR files.  A webapps/foo.war would default manage the
/foo context.  No configuration would be required, unless you wanted
something custom.

What's the status of that effort, by the way?

-jh-

Re: WAR Files

[co...@costin.dnt.ro]

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

Re: WAR Files

[James Todd <jw...@pacbell.net>]

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

Re: WAR Files

[James Todd <jw...@pacbell.net>]

Wolfgang Werner wrote:

> > 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.
>
> This says: It is working (yet) - so why not at my site? Are there other
> constraints / rules to be followed, magic wisdom?
>
> > 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.
>
> OK, but IMHO the ease of use of a war file is a much bigger gain.
>
> > - code is complex - take a look at the code, there are too many
> > special cases added all over the code
>
> As of know I do not have too much insight in the code - but is this not only
> a question of a 'knowing' class/file loader?

yep ... that's where it got weird. on the upside though (as i don't like
to dwell on "how bad the world is") i do believe this feature would
barely mucky things up at on in the class loader space if one chooses
to support JarURLConnection as provided in jdk 1.2.x. making this
happen in a jdk1.1.x world, with other issues at hand, was a pain and
highlighted things that needed to be refactored.

>
>
> > - 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.
>
> Yes, but better two manual task than three, gee?

yep. i'm sure  there are other reasons as well.


>
>
> It appears to me as if the servlet v2.2 spec is written with the idea of serving
> from a war file in mind?

my interpretation is that an implementation is free to expand internally
as long as the pristine war is all that is delivered. on that note, i'd like
to see the need for this internal expansion an option.

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

RE: WAR Files

[Wolfgang Werner <ww...@picturesafe.de>]

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

This says: It is working (yet) - so why not at my site? Are there other
constraints / rules to be followed, magic wisdom?

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

OK, but IMHO the ease of use of a war file is a much bigger gain.

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

As of know I do not have too much insight in the code - but is this not only
a question of a 'knowing' class/file loader?

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

Yes, but better two manual task than three, gee?

It appears to me as if the servlet v2.2 spec is written with the idea of serving
from a war file in mind?

Wolfgang