mod_webapp and php

[Sam De Francesco]

Hi,

I'm trying to set up a virtual host that will allow the
user to have both JSP/Servlets and PHP running concurrently,
using mod_webapp. I'm using apache 1.3.20 and tomcat 4.

Should I be able to mix .php and .jsp files in the same
directory using mod_webapp, and have apache/tomcat figure
out who will handle it automatically? Or am I being optimistic?
Or must I separate them out into different directories so
that apache will know what to handle locally and what to pass
on to Tomcat? But if I have the / path being handled by tomcat, eg
as follows:


WebAppConnectionconnwarp  localhost:8006
WebAppDeployROOTconn  /


is it possible to have php files parsed correctly
at all using this configuration? If so, do I need
to tell Apache to handle php files by itself, and how?

One other question, does a new WebAppDeploy line need to
be added to httpd.conf for every new webapp that gets
added?

Sorry for all the questions, just trying to increase my
understanding of how it all hangs together.

Regards and thanks,
Sam.



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: mod_webapp and php

[Anton Brazhnyk]

Hi!
 
> Should I be able to mix .php and .jsp files in the same
> directory using mod_webapp, and have apache/tomcat figure
> out who will handle it automatically? Or am I being optimistic?
> Or must I separate them out into different directories so
> that apache will know what to handle locally and what to pass
> on to Tomcat?
 
I think mod_webapp should serve only resources mentioned in web.xml
The other question is if Apache will serve php with its mod_php.
So you should look through your web.xml
 
There is another way. You can implement PHPServlet 
(like CGIServlet or SSIServlet already implemented).
I think it will be greatly appreciated by Tomcat-dev team.

> 
> One other question, does a new WebAppDeploy line need to
> be added to httpd.conf for every new webapp that gets
> added?
> 
 
yes and no, WebAppDeploy line should be added for every new
context (like a folder). But your root context will cover any of them, I think

> Sorry for all the questions, just trying to increase my
> understanding of how it all hangs together.
> 
 
No need to be sorry, isn't this the purpose of this list
to increase our understanding? :))

> Regards and thanks,
> Sam.
> 
> 
Anton



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: mod_webapp and php

[Nikola Milutinovic]

> > Should I be able to mix .php and .jsp files in the same
> > directory using mod_webapp, and have apache/tomcat figure
> > out who will handle it automatically? Or am I being optimistic?
> > Or must I separate them out into different directories so
> > that apache will know what to handle locally and what to pass
> > on to Tomcat?
>  
> I think mod_webapp should serve only resources mentioned in web.xml
> The other question is if Apache will serve php with its mod_php.
> So you should look through your web.xml

mod_webapp will just direct a request to WARP connection when it detects a matching 
URL. I don't know if it will enter the response resource into the Apache chain of 
request. It might.

> There is another way. You can implement PHPServlet 
> (like CGIServlet or SSIServlet already implemented).
> I think it will be greatly appreciated by Tomcat-dev team.

I think I saw it someplace or a mention of it. Search the Web.

Nix.

Re: mod_webapp and php

[Anton Brazhnyk]

- Original Message - 
From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, January 17, 2002 12:07 PM
Subject: Re: mod_webapp and php


> > I think mod_webapp should serve only resources mentioned in web.xml
> > The other question is if Apache will serve php with its mod_php.
> > So you should look through your web.xml
> 
> mod_webapp will just direct a request to WARP connection when it detects a matching 
>>URL. I don't know if it will enter the response resource into the Apache chain of 
>request. It >might.

So, what about all that autoconfiguring staff said of mod_webapp?

> 
> Nix.

Anton

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: mod_webapp and php

[Nikola Milutinovic]

> > mod_webapp will just direct a request to WARP connection when it detects a 
>matching >URL. I don't know if it will enter the response resource into the Apache > 
>> chain of request. It >might.
> 
> So, what about all that autoconfiguring staff said of mod_webapp?

What stuff and siad where? Are there new docs on mod_webapp?

Nix.

Re: mod_webapp and php

[Anton Brazhnyk]

- Original Message - 
From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, January 17, 2002 1:51 PM
Subject: Re: mod_webapp and php


> > > mod_webapp will just direct a request to WARP connection when it detects a 
>matching
> > >URL. I don't know if it will enter the response resource into the Apache 
> > > chain of request. It might.
> > 
> > So, what about all that autoconfiguring staff said of mod_webapp?
> 
> What stuff and siad where? Are there new docs on mod_webapp?
> 
> Nix.

It seems to me I've read it somewhere in tomcat-dev mail list archives.
I'm positive on Apache servicing the static content even inside context
mentioned in WebAppDeploy

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: mod_webapp and php

[Nikola Milutinovic]

> > > > mod_webapp will just direct a request to WARP connection when it detects a 
>matching
> > > >URL. I don't know if it will enter the response resource into the Apache 
> > > > chain of request. It might.
> > > 
> > > So, what about all that autoconfiguring staff said of mod_webapp?
> > 
> > What stuff and siad where? Are there new docs on mod_webapp?
> > 
> > Nix.
> 
> It seems to me I've read it somewhere in tomcat-dev mail list archives.
> I'm positive on Apache servicing the static content even inside context
> mentioned in WebAppDeploy

No way. Apache can serve only what is inside it's defined DocumentRoot-s. Suppose 
Tomcat was on one host and Apache on other, connected via Warp (it can be done), how 
would Apache serve *.html from within Tomcat, if not through Warp?

Nix.

Re: mod_webapp and php

[Anton Brazhnyk]

- Original Message - 
From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Friday, January 18, 2002 8:36 AM
Subject: Re: mod_webapp and php


> > 
> > It seems to me I've read it somewhere in tomcat-dev mail list archives.
> > I'm positive on Apache servicing the static content even inside context
> > mentioned in WebAppDeploy
> 
> No way. Apache can serve only what is inside it's defined DocumentRoot-s. 
> Suppose Tomcat was on one host and Apache on other, connected via 
> Warp (it can be done), how would Apache serve *.html from within Tomcat, 
> if not through Warp?
> 
> Nix.

Yeah, its interesting question, maybe for Tomcat developers to come up,
besides its marked as FIXME to add some info about the way mod_webapp
work behind the scene. :))

but:

RELEASE-NOTES-4.0-B7.txt
-
Tomcat 4.0 and Apache:
-

The binary distribution for Tomcat 4.0 includes the most recent stable version
of the WARP connector, which is the Tomcat component that talks to mod_webapp
inside Apache 1.3.  The current state of this support is summarized as follows:

* The mod_webapp connector is configured based on the contents of the
  web.xml file for your web application.  The only required per-webapp
  configuration information in your Apache 1.3 httpd.conf file is
  something like this:

WebAppDeploy examples   warpConnection   /examples/

  which causes mod_webapp to automatically recognize all of your servlet
  mappings, security constraints, and other configuration elements.

* Currently, mod_webapp forwards *all* requests under the specified
  context path to Tomcat for processing.  When Tomcat 4.0 final is released,
  it will automatically configure itself to serve static resources
  from Apache *unless* the resource is subject to filtering, or subject
  to a security constraint, as defined in web.xml.  No extra configuration
  in httpd.conf will be required.

and:

RELEASE-NOTES-4.1-dev.txt
-
Tomcat 4.0 and Apache:
-

The binary distribution for Tomcat 4.0 includes the most recent stable version
of the WARP connector, which is the Tomcat component that talks to mod_webapp
inside Apache 1.3.  The current state of this support is summarized as follows:

* The mod_webapp connector is configured based on the contents of the
  web.xml file for your web application.  See the documentation included
  with the connector for configuration requirements.

Anton

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: mod_webapp and php

[Nikola Milutinovic]

> Yeah, its interesting question, maybe for Tomcat developers to come up,
> besides its marked as FIXME to add some info about the way mod_webapp
> work behind the scene. :))
> 
> but:
> 
> RELEASE-NOTES-4.0-B7.txt
> -
> Tomcat 4.0 and Apache:
> -
> 
> The binary distribution for Tomcat 4.0 includes the most recent stable version
> of the WARP connector, which is the Tomcat component that talks to mod_webapp
> inside Apache 1.3.  The current state of this support is summarized as follows:
> 
> * The mod_webapp connector is configured based on the contents of the
>   web.xml file for your web application.  The only required per-webapp
>   configuration information in your Apache 1.3 httpd.conf file is
>   something like this:
> 
> WebAppDeploy examples   warpConnection   /examples/
> 
>   which causes mod_webapp to automatically recognize all of your servlet
>   mappings, security constraints, and other configuration elements.
> 
> * Currently, mod_webapp forwards *all* requests under the specified
>   context path to Tomcat for processing.  When Tomcat 4.0 final is released,
>   it will automatically configure itself to serve static resources
>   from Apache *unless* the resource is subject to filtering, or subject
>   to a security constraint, as defined in web.xml.  No extra configuration
>   in httpd.conf will be required.

I cannot fathom how they plan to do that, since it would violate the view of a "web 
application" as a sealed component on the "servlet container". I mean suppose you have 
a WELCOME.GIF file in your web application, how is Apache supposed to serve it, other 
than through WARP? Pre-caching of all static content upon "Warp Deployment"?

Or perhaps, not pre-caching, but just simple caching? Man, that is dangerous. Suppose 
I keep my GIFs in database and I upload new GIFs. OK, OK, perhaps it is not a good 
idea to remap *.gif to a servlet, since browsers might cache it, too.

Anyway, a web application with a whole lot of static content might need some 
re-modeling?

> and:
> 
> RELEASE-NOTES-4.1-dev.txt
> -
> Tomcat 4.0 and Apache:
> -
> 
> The binary distribution for Tomcat 4.0 includes the most recent stable version
> of the WARP connector, which is the Tomcat component that talks to mod_webapp
> inside Apache 1.3.  The current state of this support is summarized as follows:
> 
> * The mod_webapp connector is configured based on the contents of the
>   web.xml file for your web application.  See the documentation included
>   with the connector for configuration requirements.

I guess they realized that they cannot even make a promise on that.

Whatever happened to Pier Fumagalli (if I remeber the name correctly)? He was the main 
man behind mod_webapp. Last I heard, he was looking for a new job.

Nix.

RE: mod_webapp and php

[Anton Brazhnyk]

-Original Message-
From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 18, 2002 11:36 AM
To: Tomcat Users List
Subject: Re: mod_webapp and php

 
> > * The mod_webapp connector is configured based on the contents of the
> >   web.xml file for your web application.  The only required per-webapp
> >   configuration information in your Apache 1.3 httpd.conf file is
> >   something like this:
> > 
> > WebAppDeploy examples   warpConnection   /examples/
> > 
> >   which causes mod_webapp to automatically recognize all of your servlet
> >   mappings, security constraints, and other configuration elements.
> > 
> > * Currently, mod_webapp forwards *all* requests under the specified
> >   context path to Tomcat for processing.  When Tomcat 4.0 final 
> is released,
> >   it will automatically configure itself to serve static resources
> >   from Apache *unless* the resource is subject to filtering, or subject
> >   to a security constraint, as defined in web.xml.  No extra 
> configuration
> >   in httpd.conf will be required.
> 
> I cannot fathom how they plan to do that, since it would violate 
> the view of a "web application" as a sealed component on the 
> "servlet container". I mean suppose you have a WELCOME.GIF file 
> in your web application, how is Apache supposed to serve it, 
> other than through WARP? Pre-caching of all static content upon 
> "Warp Deployment"?
> 
> Or perhaps, not pre-caching, but just simple caching? Man, that 
> is dangerous. Suppose I keep my GIFs in database and I upload new 
> GIFs. OK, OK, perhaps it is not a good idea to remap *.gif to a 
> servlet, since browsers might cache it, too.
> 
Actually its the only way I can imagine they've done it.
And with the proper implementation it won't be dangerous at all.
And about "sealing violation" you can always consider both Tomcat
and Apache to be container, can't you?

> Anyway, a web application with a whole lot of static content 
> might need some re-modeling?
> 
Who knows?

> I guess they realized that they cannot even make a promise on that.
> 
Well, my guess is they HAVE done this.

> Whatever happened to Pier Fumagalli (if I remeber the name 
> correctly)? He was the main man behind mod_webapp. Last I heard, 
> he was looking for a new job.
> 
> Nix.

This thread is starting to be a little bit large :) and out of its topic.
We can make our guesses forever and the only couple of statements from
developers could make it all cristal clear. Should we post a question to dev-list?
Will they answer just a general question?

Anton.

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: mod_webapp and php

[Nikola Milutinovic]

> Actually its the only way I can imagine they've done it.
> And with the proper implementation it won't be dangerous at all.
> And about "sealing violation" you can always consider both Tomcat
> and Apache to be container, can't you?

Sure, but that way Apache is just a caching mechanism, it doesn't really have much to 
do with Warp, then, or mod_webapp.

> This thread is starting to be a little bit large :) and out of its topic.
> We can make our guesses forever and the only couple of statements from
> developers could make it all cristal clear. Should we post a question to dev-list?
> Will they answer just a general question?

Go ahead.

Nix.

Re: mod_webapp and php

[Craig R. McClanahan]

On Fri, 18 Jan 2002, Nikola Milutinovic wrote:

> Date: Fri, 18 Jan 2002 10:36:29 +0100
> From: Nikola Milutinovic <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: mod_webapp and php
>
> > Yeah, its interesting question, maybe for Tomcat developers to come up,
> > besides its marked as FIXME to add some info about the way mod_webapp
> > work behind the scene. :))
> >
> > but:
> >
> > RELEASE-NOTES-4.0-B7.txt
> > -
> > Tomcat 4.0 and Apache:
> > -
> >
> > The binary distribution for Tomcat 4.0 includes the most recent stable version
> > of the WARP connector, which is the Tomcat component that talks to mod_webapp
> > inside Apache 1.3.  The current state of this support is summarized as follows:
> >
> > * The mod_webapp connector is configured based on the contents of the
> >   web.xml file for your web application.  The only required per-webapp
> >   configuration information in your Apache 1.3 httpd.conf file is
> >   something like this:
> >
> > WebAppDeploy examples   warpConnection   /examples/
> >
> >   which causes mod_webapp to automatically recognize all of your servlet
> >   mappings, security constraints, and other configuration elements.
> >
> > * Currently, mod_webapp forwards *all* requests under the specified
> >   context path to Tomcat for processing.  When Tomcat 4.0 final is released,
> >   it will automatically configure itself to serve static resources
> >   from Apache *unless* the resource is subject to filtering, or subject
> >   to a security constraint, as defined in web.xml.  No extra configuration
> >   in httpd.conf will be required.
>
> I cannot fathom how they plan to do that, since it would violate the
> view of a "web application" as a sealed component on the "servlet
> container". I mean suppose you have a WELCOME.GIF file in your web
> application, how is Apache supposed to serve it, other than through
> WARP? Pre-caching of all static content upon "Warp Deployment"?
>

The original design goal was to make a decision based on the incoming
request URI of each request, by asking the following questions:
* Is this request URI matched by a filter mapping?
* Is this request URI matched by a servlet mapping?
* Is this request URI matched by a security constraint?
If the answer to any of these questions is YES, the request must be served
by Tomcat, to maintain the semantics required by the servlet
specification.

On the other hand, if the answer to all of these questions is NO, there is
no semantic problem with allowing Apache to serve this resource, instead
of the default file-serving servlet in Tomcat.

> Or perhaps, not pre-caching, but just simple caching? Man, that is
> dangerous. Suppose I keep my GIFs in database and I upload new GIFs. OK,
> OK, perhaps it is not a good idea to remap *.gif to a servlet, since
> browsers might cache it, too.
>

If you remap "*.gif" to a servlet, the request would always be served by
Tomcat, in accordance with the rules above.

Uploading new GIFs, and expecting them to be served, would "violate the
view of a 'web application' as a sealed component on the 'servlet
container'" :-).

> Anyway, a web application with a whole lot of static content might need
> some re-modeling?
>

I don't see why.

> > and:
> >
> > RELEASE-NOTES-4.1-dev.txt
> > -
> > Tomcat 4.0 and Apache:
> > -
> >
> > The binary distribution for Tomcat 4.0 includes the most recent stable version
> > of the WARP connector, which is the Tomcat component that talks to mod_webapp
> > inside Apache 1.3.  The current state of this support is summarized as follows:
> >
> > * The mod_webapp connector is configured based on the contents of the
> >   web.xml file for your web application.  See the documentation included
> >   with the connector for configuration requirements.
>
> I guess they realized that they cannot even make a promise on that.
>
> Whatever happened to Pier Fumagalli (if I remeber the name correctly)?
> He was the main man behind mod_webapp. Last I heard, he was looking for
> a new job.
>

Still the case, as far as I know.  (BTW, that's also the answer to your
question about why mod_webapp isn't done yet).

> Nix.
>

Craig



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: mod_webapp and php

[Nikola Milutinovic]

Craig R. McClanahan wrote:

> 
>>I cannot fathom how they plan to do that, since it would violate the
>>view of a "web application" as a sealed component on the "servlet
>>container". I mean suppose you have a WELCOME.GIF file in your web
>>application, how is Apache supposed to serve it, other than through
>>WARP? Pre-caching of all static content upon "Warp Deployment"?
> 
> The original design goal was to make a decision based on the incoming
> request URI of each request, by asking the following questions:
> * Is this request URI matched by a filter mapping?
> * Is this request URI matched by a servlet mapping?
> * Is this request URI matched by a security constraint?
> If the answer to any of these questions is YES, the request must be served
> by Tomcat, to maintain the semantics required by the servlet
> specification.
> 
> On the other hand, if the answer to all of these questions is NO, there is
> no semantic problem with allowing Apache to serve this resource, instead
> of the default file-serving servlet in Tomcat.


So, there is only one bit unclear to me. How was Apache supposed to serve it? 
Basically, my webapp directory is not within Apache's DocumentRoot. Is Apache 
going to cache the static content or what?


>>Or perhaps, not pre-caching, but just simple caching? Man, that is
>>dangerous. Suppose I keep my GIFs in database and I upload new GIFs. OK,
>>OK, perhaps it is not a good idea to remap *.gif to a servlet, since
>>browsers might cache it, too.
> 
> If you remap "*.gif" to a servlet, the request would always be served by
> Tomcat, in accordance with the rules above.


Yes.


> Uploading new GIFs, and expecting them to be served, would "violate the
> view of a 'web application' as a sealed component on the 'servlet
> container'" :-).


Indeed. :-)


>>Anyway, a web application with a whole lot of static content might need
>>some re-modeling?
> 
> I don't see why.


Why is it a "web application" if it has a lot of static content in it? Let 
Apache be burdened with static part of your presentation and keep truly dynamic 
parts as web apps.


> Still the case, as far as I know.  (BTW, that's also the answer to your
> question about why mod_webapp isn't done yet).

Sad to hear that.

Nix.


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: mod_webapp and php

[Craig R. McClanahan]

On Sat, 19 Jan 2002, Nikola Milutinovic wrote:

> Date: Sat, 19 Jan 2002 17:58:35 +0100
> From: Nikola Milutinovic <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: mod_webapp and php
>
> Craig R. McClanahan wrote:
>
> >
> >>I cannot fathom how they plan to do that, since it would violate the
> >>view of a "web application" as a sealed component on the "servlet
> >>container". I mean suppose you have a WELCOME.GIF file in your web
> >>application, how is Apache supposed to serve it, other than through
> >>WARP? Pre-caching of all static content upon "Warp Deployment"?
> >
> > The original design goal was to make a decision based on the incoming
> > request URI of each request, by asking the following questions:
> > * Is this request URI matched by a filter mapping?
> > * Is this request URI matched by a servlet mapping?
> > * Is this request URI matched by a security constraint?
> > If the answer to any of these questions is YES, the request must be served
> > by Tomcat, to maintain the semantics required by the servlet
> > specification.
> >
> > On the other hand, if the answer to all of these questions is NO, there is
> > no semantic problem with allowing Apache to serve this resource, instead
> > of the default file-serving servlet in Tomcat.
>
>
> So, there is only one bit unclear to me. How was Apache supposed to serve it?
> Basically, my webapp directory is not within Apache's DocumentRoot. Is Apache
> going to cache the static content or what?
>

If you've ever configured a web connector (such as mod_jk) for Tomcat, you
know how this works -- you set up an alias, or a path prefix, in Apache
that matches the context root of a Tomcat webapp, and then set up the
configuration directives telling Apache to forward only the things Tomcat
needs to care about -- everything else is served by Apache just as if
Tomcat wasn't there.  The key issue is making your Apache document root
and Tomcat document root match.

The only thing different about the way mod_webapp was intended to work is
that all the configuration stuff was supposed to get done for you
automatically, instead of needing a complex autogenerated include file for
httpd.conf that doesn't always get all the details right.

>
> >>Or perhaps, not pre-caching, but just simple caching? Man, that is
> >>dangerous. Suppose I keep my GIFs in database and I upload new GIFs. OK,
> >>OK, perhaps it is not a good idea to remap *.gif to a servlet, since
> >>browsers might cache it, too.
> >
> > If you remap "*.gif" to a servlet, the request would always be served by
> > Tomcat, in accordance with the rules above.
>
>
> Yes.
>
>
> > Uploading new GIFs, and expecting them to be served, would "violate the
> > view of a 'web application' as a sealed component on the 'servlet
> > container'" :-).
>
>
> Indeed. :-)
>
>
> >>Anyway, a web application with a whole lot of static content might need
> >>some re-modeling?
> >
> > I don't see why.
>
>
> Why is it a "web application" if it has a lot of static content in it? Let
> Apache be burdened with static part of your presentation and keep truly dynamic
> parts as web apps.
>

The days when things were always 100% static or 100% dynamic are pretty
far behind us.  The theory behind the way web connectors for Tomcat work
is to let Apache serve the static part, and Tomcat serve the dynamic part,
so you can have any desired combination of static and dynamic content
seamlessly.


>
> Nix.
>

Craig


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: mod_webapp and php

[Nikola Milutinovic]

> > So, there is only one bit unclear to me. How was Apache supposed to serve it?
> > Basically, my webapp directory is not within Apache's DocumentRoot. Is Apache
> > going to cache the static content or what?
> >
> 
> If you've ever configured a web connector (such as mod_jk) for Tomcat, you
> know how this works -- you set up an alias, or a path prefix, in Apache
> that matches the context root of a Tomcat webapp, and then set up the
> configuration directives telling Apache to forward only the things Tomcat
> needs to care about -- everything else is served by Apache just as if
> Tomcat wasn't there.  The key issue is making your Apache document root
> and Tomcat document root match.

I was afraid of that. I hate keeping things in two places at the same time. I know I 
can "use Ant", but I wanted to remove shell access from my machine for ordinary web 
developers.

Nix.

RE: mod_webapp and php

[Anton Brazhnyk]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 18, 2002 7:52 PM
> To: Tomcat Users List
> Subject: Re: mod_webapp and php
> 
> 
> > I cannot fathom how they plan to do that, since it would violate the
> > view of a "web application" as a sealed component on the "servlet
> > container". I mean suppose you have a WELCOME.GIF file in your web
> > application, how is Apache supposed to serve it, other than through
> > WARP? Pre-caching of all static content upon "Warp Deployment"?
> >
> 
> The original design goal was to make a decision based on the incoming
> request URI of each request, by asking the following questions:
> * Is this request URI matched by a filter mapping?
> * Is this request URI matched by a servlet mapping?
> * Is this request URI matched by a security constraint?
> If the answer to any of these questions is YES, the request must be served
> by Tomcat, to maintain the semantics required by the servlet
> specification.
> 
> On the other hand, if the answer to all of these questions is NO, there is
> no semantic problem with allowing Apache to serve this resource, instead
> of the default file-serving servlet in Tomcat.
> 

Thanks for clarification, Craig
But then again, what if the static content (e.g. some html pages) resides inside 
web-app, 
is it than considered static?
Will Apache serve it from there directly (I believe not, cause it could be on a 
different host)
or will mod_webapp pre-cache it in some place Apache is aware of
or will such content be served by Tomcat? (that is what I think for now)


Anton

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: mod_webapp and php

[Craig R. McClanahan]

On Mon, 21 Jan 2002, Anton Brazhnyk wrote:

> Date: Mon, 21 Jan 2002 12:59:23 +0200
> From: Anton Brazhnyk <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: RE: mod_webapp and php
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 18, 2002 7:52 PM
> > To: Tomcat Users List
> > Subject: Re: mod_webapp and php
> >
> >
> > > I cannot fathom how they plan to do that, since it would violate the
> > > view of a "web application" as a sealed component on the "servlet
> > > container". I mean suppose you have a WELCOME.GIF file in your web
> > > application, how is Apache supposed to serve it, other than through
> > > WARP? Pre-caching of all static content upon "Warp Deployment"?
> > >
> >
> > The original design goal was to make a decision based on the incoming
> > request URI of each request, by asking the following questions:
> > * Is this request URI matched by a filter mapping?
> > * Is this request URI matched by a servlet mapping?
> > * Is this request URI matched by a security constraint?
> > If the answer to any of these questions is YES, the request must be served
> > by Tomcat, to maintain the semantics required by the servlet
> > specification.
> >
> > On the other hand, if the answer to all of these questions is NO, there is
> > no semantic problem with allowing Apache to serve this resource, instead
> > of the default file-serving servlet in Tomcat.
> >
>
> Thanks for clarification, Craig But then again, what if the static
> content (e.g. some html pages) resides inside web-app, is it than
> considered static? Will Apache serve it from there directly (I believe
> not, cause it could be on a different host) or will mod_webapp pre-cache
> it in some place Apache is aware of or will such content be served by
> Tomcat? (that is what I think for now)
>

Your impression of how it works seems to be inaccurate.  There is no
caching going on anywhere.

Let's look at the Tomcat stand-alone case first, and then examine the
combined case.

Technically, from the point of view of Tomcat 4 (details are slightly
different in 3.3), there is no such thing as "static content" -- all
requests are handled by a servlet.  If you look in the
$CATALINA_HOME/conf/web.xml file, which defines default configuration
settings for all webapps, you will see a servlet named "default" that is
mapped to the URL pattern "/".  This pattern means, "use the 'default'
servlet whenever no other servlet is matched by a particular request URI".
So, requests for things like "index.html" and "logo.jpg" don't match any
of your application servlets or JSP pages, so they are handled by the
default servlet -- which simply serves the contents of the corresponding
file back to the client.

Now, let's consider what happens when you put Apache and a web connector
in front of Tomcat (the concepts apply equally to mod_jk and mod_webapp,
only the configuration details differ).  Essentially, what people try to
do is make Apache itself be the default file-serving servlet, instead of
the one built in to Tomcat.

This is accomplished in your configuration directives, where you tell
Apache which requests to forward (and by implication, all other requests
are handled by Apache itself in the usual way).  Thus, when we add a
diretive that says "forward all *.jsp requests to Tomcat", we are telling
Apache that any request that ends with ".jsp" MUST be forwarded to Tomcat
for processing.  Apache acts like a proxy server for these requests -- it
just calls Tomcat and then copies back the response Tomcat creates to the
original client.

If you do not have any such configuration directives for "*.html" and
"*.jpg" patterns, then Apache serves them directly, based on your Apache
configuration directives in httpd.conf.  It is NOT an issue of pre-caching
or anything like that -- the request either gets forwarded to Tomcat or it
doesn't.

Now, if you configure Apache so that the directory being served by the
"/foo" request URI prefix is the same as the directory defined as the
context root of the "/foo" web app in Tomcat, you've accomplished the goal
-- Tomcat serves all the requests that Apache forwards to it, and Apache
serves all the requests that it doesn't forward.  But your application
code is identical in either case.

Keep in mind that the ACTUAL directory pathname of your webapp doesn't
need to have anything at all to do with the "/foo" prefix on requiest
URIs.  Both Apache (via the &q

Re: mod_webapp and php

[Nikola Milutinovic]

> > Thanks for clarification, Craig But then again, what if the static
> > content (e.g. some html pages) resides inside web-app, is it than
> > considered static? Will Apache serve it from there directly (I believe
> > not, cause it could be on a different host) or will mod_webapp pre-cache
> > it in some place Apache is aware of or will such content be served by
> > Tomcat? (that is what I think for now)
> >
> 
> Your impression of how it works seems to be inaccurate.  There is no
> caching going on anywhere.
> 
> Let's look at the Tomcat stand-alone case first, and then examine the
> combined case.
> 
> Technically, from the point of view of Tomcat 4 (details are slightly
> different in 3.3), there is no such thing as "static content" -- all
> requests are handled by a servlet.  If you look in the
> $CATALINA_HOME/conf/web.xml file, which defines default configuration
> settings for all webapps, you will see a servlet named "default" that is
> mapped to the URL pattern "/".  This pattern means, "use the 'default'
> servlet whenever no other servlet is matched by a particular request URI".
> So, requests for things like "index.html" and "logo.jpg" don't match any
> of your application servlets or JSP pages, so they are handled by the
> default servlet -- which simply serves the contents of the corresponding
> file back to the client.

That was my understanding, too.

> Now, let's consider what happens when you put Apache and a web connector
> in front of Tomcat (the concepts apply equally to mod_jk and mod_webapp,
> only the configuration details differ).  Essentially, what people try to
> do is make Apache itself be the default file-serving servlet, instead of
> the one built in to Tomcat.

Because it is faster, yes.

> This is accomplished in your configuration directives, where you tell
> Apache which requests to forward (and by implication, all other requests
> are handled by Apache itself in the usual way).  Thus, when we add a
> diretive that says "forward all *.jsp requests to Tomcat", we are telling
> Apache that any request that ends with ".jsp" MUST be forwarded to Tomcat
> for processing.  Apache acts like a proxy server for these requests -- it
> just calls Tomcat and then copies back the response Tomcat creates to the
> original client.
> 
> If you do not have any such configuration directives for "*.html" and
> "*.jpg" patterns, then Apache serves them directly, based on your Apache
> configuration directives in httpd.conf.  It is NOT an issue of pre-caching
> or anything like that -- the request either gets forwarded to Tomcat or it
> doesn't.

This means, that if I'm developing a web application which uses static content, like 
GIFs and similar stuff, I have a slight problem. I would make source paths to such 
content in my JSP file a relative one and my "web development tool" (Dreamweaver in 
this case) will place them in the web-app directory. Upon deploying, I need to make 
copies to Apache's DocumentRoot tree.

I know I can use Ant for this, but it requires a login to the server in question. Not 
to mention that a configuration where Tomcat and Apache are not on the same host adds 
an additional layer of "fun".

Is there a way to accopmlish upload and "division of static/dynamic" content 
autmagically? Web-DAV?

> Now, if you configure Apache so that the directory being served by the
> "/foo" request URI prefix is the same as the directory defined as the
> context root of the "/foo" web app in Tomcat, you've accomplished the goal
> -- Tomcat serves all the requests that Apache forwards to it, and Apache
> serves all the requests that it doesn't forward.  But your application
> code is identical in either case.

Yes, it's the uploading that worries my, not to mention packaging? Is ther a way to 
make *one* WAR that would deploy itself both to static and dynamic paths? Hmm, I don't 
think so, but a build.xml that would take a few parameters should do the trick...

> Keep in mind that the ACTUAL directory pathname of your webapp doesn't
> need to have anything at all to do with the "/foo" prefix on requiest
> URIs.  Both Apache (via the "Alias" directive) and Tomcat (via the
> "docBase" attribute of the  element) let you map that prefix to
> whatever real directory you want -- the secret is to make sure they both
> point at the same place.
> 
> Lastly, I want to emphasize again, NONE of this is new to mod_webapp --
> the mod_jserv and mod_jk connectors have worked this way for around five
> years.  The only new thing mod_webapp was supposed to bring to the table
> was automatic configuration of the httpd.conf directives that make all of
> this happen, instead of requiring the sysadmin to do it all yourself.

I wish it was someplace in capital letters, saying "Dear newbie, this is the way we 
would recomend doing Tomcat/Apache setup...".

Nix.

RE: mod_webapp and php

[Anton Brazhnyk]

Hi and thank you very much, Craig.

Actually I didn't expect such an complete answer.
I think it could replace that FIXME in (...)/tomcat-docs/config/warp.html

Would you answer one more question, please?
I have posted it here recently and then in dev-list.
It was about "Client connection closing".

I believe that situation is mentioned in 
RFC 2616 "HTTP 1.1 protocol"
and both sides of connection should watch if 
the connection is still alive.
As far as I understand server programmers should 
be able to detect connection closing (e.g. Stop button
in browser was pressed).
Did I get it right or, if not, where is my mistake?

BTW, I'm considering to do it myself and if it seems
useful to Tomcat users and developers I'd like to
discuss the way such feature should be done since
I don't see a way to find a place for it in the present specs.


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 21, 2002 7:58 PM
> To: Tomcat Users List
> Subject: RE: mod_webapp and php
> 
> 
> >
> > Thanks for clarification, Craig But then again, what if the static
> > content (e.g. some html pages) resides inside web-app, is it than
> > considered static? Will Apache serve it from there directly (I believe
> > not, cause it could be on a different host) or will mod_webapp pre-cache
> > it in some place Apache is aware of or will such content be served by
> > Tomcat? (that is what I think for now)
> >
> 
> Your impression of how it works seems to be inaccurate.  There is no
> caching going on anywhere.
> 
> Let's look at the Tomcat stand-alone case first, and then examine the
> combined case.
> 
> Technically, from the point of view of Tomcat 4 (details are slightly
> different in 3.3), there is no such thing as "static content" -- all
> requests are handled by a servlet.  If you look in the
> $CATALINA_HOME/conf/web.xml file, which defines default configuration
> settings for all webapps, you will see a servlet named "default" that is
> mapped to the URL pattern "/".  This pattern means, "use the 'default'
> servlet whenever no other servlet is matched by a particular request URI".
> So, requests for things like "index.html" and "logo.jpg" don't match any
> of your application servlets or JSP pages, so they are handled by the
> default servlet -- which simply serves the contents of the corresponding
> file back to the client.
> 
> Now, let's consider what happens when you put Apache and a web connector
> in front of Tomcat (the concepts apply equally to mod_jk and mod_webapp,
> only the configuration details differ).  Essentially, what people try to
> do is make Apache itself be the default file-serving servlet, instead of
> the one built in to Tomcat.
> 
> This is accomplished in your configuration directives, where you tell
> Apache which requests to forward (and by implication, all other requests
> are handled by Apache itself in the usual way).  Thus, when we add a
> diretive that says "forward all *.jsp requests to Tomcat", we are telling
> Apache that any request that ends with ".jsp" MUST be forwarded to Tomcat
> for processing.  Apache acts like a proxy server for these requests -- it
> just calls Tomcat and then copies back the response Tomcat creates to the
> original client.
> 
> If you do not have any such configuration directives for "*.html" and
> "*.jpg" patterns, then Apache serves them directly, based on your Apache
> configuration directives in httpd.conf.  It is NOT an issue of pre-caching
> or anything like that -- the request either gets forwarded to Tomcat or it
> doesn't.
> 
> Now, if you configure Apache so that the directory being served by the
> "/foo" request URI prefix is the same as the directory defined as the
> context root of the "/foo" web app in Tomcat, you've accomplished the goal
> -- Tomcat serves all the requests that Apache forwards to it, and Apache
> serves all the requests that it doesn't forward.  But your application
> code is identical in either case.
> 
> Keep in mind that the ACTUAL directory pathname of your webapp doesn't
> need to have anything at all to do with the "/foo" prefix on requiest
> URIs.  Both Apache (via the "Alias" directive) and Tomcat (via the
> "docBase" attribute of the  element) let you map that prefix to
> whatever real directory you want -- the secret is to make sure they both
> point at the same place.
> 
> Lastly, I want to emphasize again, NONE of this is new to mod_webapp --
> the mod_jserv and mod_jk connectors have worked this way for around five
> years.  The only new thing mod_webapp was supposed to bring to the table
> was automatic configuration of the httpd.conf directives that make all of
> this happen, instead of requiring the sysadmin to do it all yourself.
> 
> Craig
> 
> 


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

About mod_webapp and php...

[Romain Bertucelli]

Dear all,

I have just read the explanation of Craig R. McClanahan about the way
mod_warp works. (mod_webapp and php)
The following part of the README seems to indicate that the mod_webapp will
change

* Currently, mod_webapp forwards *all* requests under the specified
  context path to Tomcat for processing.  When Tomcat 4.0 final is released,
  it will automatically configure itself to serve static resources
  from Apache *unless* the resource is subject to filtering, or subject
  to a security constraint, as defined in web.xml.  No extra configuration
  in httpd.conf will be required.


Actually, I run a webapp under tomcat 3.2.3 and mod_jk that I mount as
/feedback.
I also use php pages in the folder /feedback/chat. All is ok with mod_jk

I am now evaluating tomcat4 and mod_webapp. Mod_webapp configuration is
REALLY excellent: I face many problems to run jetspeed with tomcat3, it runs
at the first time on tomcat 4 ! BUT php pages do not run anymore: the
mod_webapp reads the php3 files directly instead of letting mod_php manage
them. This is normal: it is how the "default" servlet works if I well
understand what Craig has said.

I have tried first to change the global web.xml to add the mime type for php
but it was a bad idea. I also test the PHP Servlet SAPI, I still hang on it
but it does not seem to be a good idea for me.

The very best solution, you will tell me is to put the php pages elsewhere.
True but far less "portable" when I have to replace the server or to install
another test server.
Does the  jakarta-connectors's team plan include to correct this kind of
mixt situation in some times or do I have to accept the idea to really
separate PHP and Java ?


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

About mod_webapp and php

[Romain Bertucelli]

Dear all,

I have just read the explanation of Craig R. McClanahan about the way
mod_warp works. (mod_webapp and php)
The following part of the README seems to indicate that the mod_webapp will
change

* Currently, mod_webapp forwards *all* requests under the specified
  context path to Tomcat for processing.  When Tomcat 4.0 final is released,
  it will automatically configure itself to serve static resources
  from Apache *unless* the resource is subject to filtering, or subject
  to a security constraint, as defined in web.xml.  No extra configuration
  in httpd.conf will be required.


Actually, I run a webapp under tomcat 3.2.3 and mod_jk that I mount as
/feedback.
I also use php pages in the folder /feedback/chat. All is ok with mod_jk

I am now evaluating tomcat4 and mod_webapp. Mod_webapp configuration is
REALLY excellent: I face many problems to run jetspeed with tomcat3, it runs
at the first time on tomcat 4 ! BUT php pages do not run anymore: the
mod_webapp reads the php3 files directly instead of letting mod_php manage
them. This is normal: it is how the "default" servlet works if I well
understand what Craig has said.

I have tried first to change the global web.xml to add the mime type for php
but it was a bad idea. I also test the PHP Servlet SAPI, I still hang on it
but it does not seem to be a good idea for me.

The very best solution, you will tell me is to put the php pages elsewhere.
True but far less "portable" when I have to replace the server or to install
another test server.
Does the  jakarta-connectors's team plan include to correct this kind of
mixt situation in some times or do I have to accept the idea to really
separate PHP and Java ?



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: About mod_webapp and php...

[Anton Brazhnyk]

Hi,

> -Original Message-
> From: Romain Bertucelli [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 28, 2002 1:47 PM
> To: Tomcat Users List
> Subject: About mod_webapp and php...
> 
> 
> Dear all,
> 
> I have just read the explanation of Craig R. McClanahan about the way
> mod_warp works. (mod_webapp and php)
> The following part of the README seems to indicate that the 
> mod_webapp will
> change
> 
> * Currently, mod_webapp forwards *all* requests under the specified
>   context path to Tomcat for processing.  When Tomcat 4.0 final 
> is released,
>   it will automatically configure itself to serve static resources
>   from Apache *unless* the resource is subject to filtering, or subject
>   to a security constraint, as defined in web.xml.  No extra configuration
>   in httpd.conf will be required.
> 
> 

This is a part of some old RELEASE-NOTES right? Course mod_webapp
"is configured based on the contents of the  web.xml file for your web application"
since Tomcat 4 beta 7.

> Actually, I run a webapp under tomcat 3.2.3 and mod_jk that I mount as
> /feedback.
> I also use php pages in the folder /feedback/chat. All is ok with mod_jk
> 
> I am now evaluating tomcat4 and mod_webapp. Mod_webapp configuration is
> REALLY excellent: I face many problems to run jetspeed with 
> tomcat3, it runs
> at the first time on tomcat 4 ! BUT php pages do not run anymore: the
> mod_webapp reads the php3 files directly instead of letting mod_php manage
> them. This is normal: it is how the "default" servlet works if I well
> understand what Craig has said.
> 

It seems that with equal configurations mod_jk should serve php3 the same way
as TC4 does, according to Craig's "the mod_jserv and mod_jk connectors have 
worked this way for around five years"

> I have tried first to change the global web.xml to add the mime 
> type for php
> but it was a bad idea. I also test the PHP Servlet SAPI, I still 
> hang on it
> but it does not seem to be a good idea for me.
> 

But it still looks like the right idea if you really
want phps inside your application.

> The very best solution, you will tell me is to put the php pages 
> elsewhere.
> True but far less "portable" when I have to replace the server or 
> to install
> another test server.
> Does the  jakarta-connectors's team plan include to correct this kind of
> mixt situation in some times or do I have to accept the idea to really
> separate PHP and Java ?
> 

Maybe to suggest a new directive to mod_webapp? Something like
WebAppIgnore?

Anton.

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>