You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Nick Bauman <ni...@cortexity.com> on 2001/01/19 02:19:42 UTC

Catalina + Apache

Hello Jakarta Tribe,

We are targeting Tomcat 4.0 for a project to be released within 30
days. We currently have an app in production at Exodus in Chicago that
utilizes many megabits of throughput and runs on multiple webservers that 
are load balanced using TC 3.1 and Apache 1.3. This is a new release of
this app.

I have some questions:

1) If we are choosing to go with 4.0, should we also be taking a look at
Apache 2.0? How far has the integration come on that front?

2) Using the mod_webapp.so, do we need to specify a "Tomcat
Standalone" service with our ROOT context, or is the
"Tomcat-Apache" all we need (and we should define the ROOT context int
there)

Thanks,

-Nick Bauman
(The guy running BugRat for Jakarta)



Re: Catalina + Apache

Posted by Arshad Mahmood <ar...@rohas.com>.
Can you recommend any documents for trying to understand the architecture of
mod_webapp and catalina connectors, or is the source the best place.

I am fairly keen in getting involved in this area, so any indication of
where to get started would be gratefully received. I am a fairly good 'C'
and Java programmer.

Regards,
Arshad

----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <to...@jakarta.apache.org>
Sent: Friday, January 19, 2001 8:21 PM
Subject: Re: Catalina + Apache


> Nick Bauman wrote:
>
> > Craig,
> >
> > These design goals are AWESOME. It makes much more sense to do this
> > way. However, I _did_ do this as you mentioned: I have *.jsp and *.j
> > mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was
> > the output of index.jsp as something Netscape had to download.
telnetting
> > to the webserver port revealed that the index.jsp was being served by
> > Apache, not Catalina.
> >
> > I'll mess around with it this weekend and see if I can get it to work
"as
> > advertised" and report back my results, but I have a couple of guys
> > waiting on a servlet container that works with our *.j framework to test
> > today, so I'm temporarily falling back to 3.2.
> >
> > I'm really happy that this approach is being followed as it's much more
> > (ultimately) intuitive than the way it's done in 3.2 because it's
simpler.
> >
>
> I'm glad you like it, although you should really thank Pier Fumagalli --
it's his vision
> (which I agree with) and effort that has really been working towards this.
>
> As I mentioned several times, what I was describing is the *theory* of
what mod_webapp is
> supposed to accomplish.  To ensure that it becomes *reality*, please feel
free to volunteer
> your time (as you did above) in testing the current connector, identifying
places where
> there are bugs, posting patches, etc.
>
> I know Pier has a bunch of bugfixes currently in his local CVS tree, so
hopefully we will be
> much closer to the "reality" end of the scale soon.
>
> >
> > Thanks again,
> >
> > -Nick
> >
>
> Craig
>
>
> >
> > On Fri, 19 Jan 2001, Craig R. McClanahan wrote:
> >
> > > Nick Bauman wrote:
> > >
> > > > On Fri, 19 Jan 2001, Craig R. McClanahan wrote:
> > > >
> > > > > Nick Bauman wrote:
> > > > >
> > > > > > Uhhh, I just realized something
> > > > > >
> > > > > > With TC 3x, you could map an extension from Apache to the
servlet engine
> > > > > > with an AddHandler directive. I see nothing like this for TC4.
Can someone
> > > > > > enlighten me?
> > > > > >
> > > > >
> > > > > The design goals for mod_webapp say that it should respect web.xml
mappings --
> > > > > in other words, if you added a <servlet-mapping> entry for "*.foo"
to a
> > > > > particular servlet, then that is what would happen at runtime.
> > > >
> > > > I totally do not understand this! I'm dense or something: How does
Apache
> > > > / DSO* know about something in the web.xml?
> > > >
> > >
> > > This is the key architectural difference between mod_webapp and the
current generation
> > > of connectors.  When mod_webapp establishes its initial connection
from Apache to
> > > Tomcat, the configuration information (extracted from the property
getters of the
> > > internal Context object) is sent back to the connector in order to
configure
> > > everything about this particular webapp.
> > >
> > > >From the sysadmin perspective, this means we can forget all about
having to configure
> > > things twice (once in httpd.conf and once in web.xml).  It's also a
requirement of the
> > > 2.3 spec -- if we create a "servlet container" using Apache+Tomcat
together, it (the
> > > combination) must still obey all the servlet spec requirements,
including respecting
> > > things in web.xml.
> > >
> > > >
> > > > If I grok you, this still relies on having /foo mapped to the
servlet
> > > > container in Apache. I'm in a situation where Apache's DocumentRoot
_is
> > > > the same as_ the top level of the WAR, but I want Apache to serve
the
> > > > *.html and *.gif and *.jpg and *.png and I want Tomcat to only do
the *jsp
> > > > and a special mapping (in this case *.j).
> > > >
> > >
> > > Then what you'd want is to configure the ROOT webapp to have a context
base equal to
> > > your Apache document root.  If you want things mapped to servlets,
just do them with
> > > <servlet-mapping> entries *exactly* like you would for Tomcat
stand-alone.  As I
> > > mentioned earlier, the connector takes over the "default servlet"
mapping, so it will
> > > handle everything that is *not* explicitly mapped to a servlet (i.e.
all the static
> > > files).
> > >
> > > Again, this is all the design goals -- I have not tested the current
implementation to
> > > see if it achieves these goals yet.  In particular, I recall seeing
bug reports about
> > > mapping the ROOT context.
> > >
> > > >
> > > > > The primary difference between Tomcat 4.0 stand alone and Tomcat
4.0 behind
> > > > > Apache is the mapping for the "default" servlet.  In the
stand-alone case, this
> > > > > is mapped to the Tomcat servlet that serves static resources.  In
the connected
> > > > > case, they would be served by Apache.
> > > >
> > > > I don't see how this works in my case. I'm being dense, I think.
> > > >
> > >
> > > If you were running Tomcat stand-alone, you would accomplish the goal
of mapping *.j
> > > files to a particular servlet like this (in your webapp's web.xml
file):
> > >
> > >     <servlet>
> > >         <servlet-name>MyServlet</servlet-name>
> > >
<servlet-class>com.mycompany.mypackage.MyServlet</servlet-class>
> > >     </servlet>
> > >
> > >     <servlet-mapping>
> > >         <servlet-name>MyServlet</servlet-mapping>
> > >         <url-pattern>*.j</url-pattern>
> > >     </servlet-mapping>
> > >
> > > and this rule would get applied to all incoming requests -- a request
for "foo.j"
> > > would be sent to your servlet, while a request for "foo.html" would be
handled by the
> > > default file-serving servlet.
> > >
> > > In Tomcat4+Apache, you do *exactly* the same thing.  The only
difference at runtime is
> > > that Apache becomes the "default file-serving servlet" instead of the
servlet inside
> > > Tomcat.
> > >
> > > Does that help?
> > >
> > > >
> > > > > At any rate, this is the theory -- Pier can comment on current
practice.  I know
> > > > > he's working on a bunch of bug fixes for the originally reported
problems.
> > > > >
> > > > > Craig
> > > >
> > > > I would like to have it work in my case, but in order for me to help
make
> > > > it happen, I need to understand the goal, which I don't understand.
If you
> > > > or Pier can nurse me along a bit, I will work on making it happen in
my
> > > > case (I do know C) and give it back to the community.
> > > >
> > > > Thanks a ton anyway, Craig.
> > > >
> > > > --
> > > > Nicolaus Bauman
> > > > Software Engineer
> > > > Simplexity Systems
> > > >
> > >
> > > Craig
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> > >
> >
> > --
> > Nicolaus Bauman
> > Software Engineer
> > Simplexity Systems
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>


Re: Catalina + Apache

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
James Duncan Davidson wrote:

> On 1/19/01 2:03 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
>
> > on 1/19/01 12:21 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> > wrote:
> >
> >> I know Pier has a bunch of bugfixes currently in his local CVS tree, so
> >> hopefully we will be much closer to the "reality" end of the scale soon.
> >>
> > Why isn't development happening in public? Having local CVS tree does not
> > encourage community development.
>
> Before anybody gets freaked out :) there's not an "internal to Sun" CVS
> tree.

Thanks James .. I did make a *very* poor choice of words :-(

> I'm sure that Craig meant that they were in Pier's checked out
> sandbox. As to why Pier hasn't been checking in code more often, that's a
> different story.
>

Pier will need to answer that question himself.

>
> --
> James Duncan Davidson                                        duncan@x180.net
>                                                                   !try; do()
>

Craig



Re: Catalina + Apache

Posted by James Duncan Davidson <du...@x180.net>.
On 1/19/01 2:03 PM, "Jon Stevens" <jo...@latchkey.com> wrote:

> on 1/19/01 12:21 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
> 
>> I know Pier has a bunch of bugfixes currently in his local CVS tree, so
>> hopefully we will be much closer to the "reality" end of the scale soon.
>> 
> Why isn't development happening in public? Having local CVS tree does not
> encourage community development.

Before anybody gets freaked out :) there's not an "internal to Sun" CVS
tree. I'm sure that Craig meant that they were in Pier's checked out
sandbox. As to why Pier hasn't been checking in code more often, that's a
different story.

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Re: Catalina + Apache

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/19/01 12:21 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:

> I know Pier has a bunch of bugfixes currently in his local CVS tree, so
> hopefully we will be
> much closer to the "reality" end of the scale soon.

Why isn't development happening in public? Having local CVS tree does not
encourage community development.

-jon


Re: Catalina + Apache

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Nick Bauman wrote:

> Craig,
>
> These design goals are AWESOME. It makes much more sense to do this
> way. However, I _did_ do this as you mentioned: I have *.jsp and *.j
> mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was
> the output of index.jsp as something Netscape had to download. telnetting
> to the webserver port revealed that the index.jsp was being served by
> Apache, not Catalina.
>
> I'll mess around with it this weekend and see if I can get it to work "as
> advertised" and report back my results, but I have a couple of guys
> waiting on a servlet container that works with our *.j framework to test
> today, so I'm temporarily falling back to 3.2.
>
> I'm really happy that this approach is being followed as it's much more
> (ultimately) intuitive than the way it's done in 3.2 because it's simpler.
>

I'm glad you like it, although you should really thank Pier Fumagalli -- it's his vision
(which I agree with) and effort that has really been working towards this.

As I mentioned several times, what I was describing is the *theory* of what mod_webapp is
supposed to accomplish.  To ensure that it becomes *reality*, please feel free to volunteer
your time (as you did above) in testing the current connector, identifying places where
there are bugs, posting patches, etc.

I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be
much closer to the "reality" end of the scale soon.

>
> Thanks again,
>
> -Nick
>

Craig


>
> On Fri, 19 Jan 2001, Craig R. McClanahan wrote:
>
> > Nick Bauman wrote:
> >
> > > On Fri, 19 Jan 2001, Craig R. McClanahan wrote:
> > >
> > > > Nick Bauman wrote:
> > > >
> > > > > Uhhh, I just realized something
> > > > >
> > > > > With TC 3x, you could map an extension from Apache to the servlet engine
> > > > > with an AddHandler directive. I see nothing like this for TC4. Can someone
> > > > > enlighten me?
> > > > >
> > > >
> > > > The design goals for mod_webapp say that it should respect web.xml mappings --
> > > > in other words, if you added a <servlet-mapping> entry for "*.foo" to a
> > > > particular servlet, then that is what would happen at runtime.
> > >
> > > I totally do not understand this! I'm dense or something: How does Apache
> > > / DSO* know about something in the web.xml?
> > >
> >
> > This is the key architectural difference between mod_webapp and the current generation
> > of connectors.  When mod_webapp establishes its initial connection from Apache to
> > Tomcat, the configuration information (extracted from the property getters of the
> > internal Context object) is sent back to the connector in order to configure
> > everything about this particular webapp.
> >
> > >From the sysadmin perspective, this means we can forget all about having to configure
> > things twice (once in httpd.conf and once in web.xml).  It's also a requirement of the
> > 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the
> > combination) must still obey all the servlet spec requirements, including respecting
> > things in web.xml.
> >
> > >
> > > If I grok you, this still relies on having /foo mapped to the servlet
> > > container in Apache. I'm in a situation where Apache's DocumentRoot _is
> > > the same as_ the top level of the WAR, but I want Apache to serve the
> > > *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp
> > > and a special mapping (in this case *.j).
> > >
> >
> > Then what you'd want is to configure the ROOT webapp to have a context base equal to
> > your Apache document root.  If you want things mapped to servlets, just do them with
> > <servlet-mapping> entries *exactly* like you would for Tomcat stand-alone.  As I
> > mentioned earlier, the connector takes over the "default servlet" mapping, so it will
> > handle everything that is *not* explicitly mapped to a servlet (i.e. all the static
> > files).
> >
> > Again, this is all the design goals -- I have not tested the current implementation to
> > see if it achieves these goals yet.  In particular, I recall seeing bug reports about
> > mapping the ROOT context.
> >
> > >
> > > > The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind
> > > > Apache is the mapping for the "default" servlet.  In the stand-alone case, this
> > > > is mapped to the Tomcat servlet that serves static resources.  In the connected
> > > > case, they would be served by Apache.
> > >
> > > I don't see how this works in my case. I'm being dense, I think.
> > >
> >
> > If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j
> > files to a particular servlet like this (in your webapp's web.xml file):
> >
> >     <servlet>
> >         <servlet-name>MyServlet</servlet-name>
> >         <servlet-class>com.mycompany.mypackage.MyServlet</servlet-class>
> >     </servlet>
> >
> >     <servlet-mapping>
> >         <servlet-name>MyServlet</servlet-mapping>
> >         <url-pattern>*.j</url-pattern>
> >     </servlet-mapping>
> >
> > and this rule would get applied to all incoming requests -- a request for "foo.j"
> > would be sent to your servlet, while a request for "foo.html" would be handled by the
> > default file-serving servlet.
> >
> > In Tomcat4+Apache, you do *exactly* the same thing.  The only difference at runtime is
> > that Apache becomes the "default file-serving servlet" instead of the servlet inside
> > Tomcat.
> >
> > Does that help?
> >
> > >
> > > > At any rate, this is the theory -- Pier can comment on current practice.  I know
> > > > he's working on a bunch of bug fixes for the originally reported problems.
> > > >
> > > > Craig
> > >
> > > I would like to have it work in my case, but in order for me to help make
> > > it happen, I need to understand the goal, which I don't understand. If you
> > > or Pier can nurse me along a bit, I will work on making it happen in my
> > > case (I do know C) and give it back to the community.
> > >
> > > Thanks a ton anyway, Craig.
> > >
> > > --
> > > Nicolaus Bauman
> > > Software Engineer
> > > Simplexity Systems
> > >
> >
> > Craig
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> >
>
> --
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org


Re: Catalina + Apache

Posted by Nick Bauman <ni...@cortexity.com>.
Craig,

These design goals are AWESOME. It makes much more sense to do this
way. However, I _did_ do this as you mentioned: I have *.jsp and *.j
mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was
the output of index.jsp as something Netscape had to download. telnetting
to the webserver port revealed that the index.jsp was being served by
Apache, not Catalina.

I'll mess around with it this weekend and see if I can get it to work "as
advertised" and report back my results, but I have a couple of guys
waiting on a servlet container that works with our *.j framework to test
today, so I'm temporarily falling back to 3.2.

I'm really happy that this approach is being followed as it's much more
(ultimately) intuitive than the way it's done in 3.2 because it's simpler.

Thanks again,

-Nick

On Fri, 19 Jan 2001, Craig R. McClanahan wrote:

> Nick Bauman wrote:
> 
> > On Fri, 19 Jan 2001, Craig R. McClanahan wrote:
> >
> > > Nick Bauman wrote:
> > >
> > > > Uhhh, I just realized something
> > > >
> > > > With TC 3x, you could map an extension from Apache to the servlet engine
> > > > with an AddHandler directive. I see nothing like this for TC4. Can someone
> > > > enlighten me?
> > > >
> > >
> > > The design goals for mod_webapp say that it should respect web.xml mappings --
> > > in other words, if you added a <servlet-mapping> entry for "*.foo" to a
> > > particular servlet, then that is what would happen at runtime.
> >
> > I totally do not understand this! I'm dense or something: How does Apache
> > / DSO* know about something in the web.xml?
> >
> 
> This is the key architectural difference between mod_webapp and the current generation
> of connectors.  When mod_webapp establishes its initial connection from Apache to
> Tomcat, the configuration information (extracted from the property getters of the
> internal Context object) is sent back to the connector in order to configure
> everything about this particular webapp.
> 
> >From the sysadmin perspective, this means we can forget all about having to configure
> things twice (once in httpd.conf and once in web.xml).  It's also a requirement of the
> 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the
> combination) must still obey all the servlet spec requirements, including respecting
> things in web.xml.
> 
> >
> > If I grok you, this still relies on having /foo mapped to the servlet
> > container in Apache. I'm in a situation where Apache's DocumentRoot _is
> > the same as_ the top level of the WAR, but I want Apache to serve the
> > *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp
> > and a special mapping (in this case *.j).
> >
> 
> Then what you'd want is to configure the ROOT webapp to have a context base equal to
> your Apache document root.  If you want things mapped to servlets, just do them with
> <servlet-mapping> entries *exactly* like you would for Tomcat stand-alone.  As I
> mentioned earlier, the connector takes over the "default servlet" mapping, so it will
> handle everything that is *not* explicitly mapped to a servlet (i.e. all the static
> files).
> 
> Again, this is all the design goals -- I have not tested the current implementation to
> see if it achieves these goals yet.  In particular, I recall seeing bug reports about
> mapping the ROOT context.
> 
> >
> > > The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind
> > > Apache is the mapping for the "default" servlet.  In the stand-alone case, this
> > > is mapped to the Tomcat servlet that serves static resources.  In the connected
> > > case, they would be served by Apache.
> >
> > I don't see how this works in my case. I'm being dense, I think.
> >
> 
> If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j
> files to a particular servlet like this (in your webapp's web.xml file):
> 
>     <servlet>
>         <servlet-name>MyServlet</servlet-name>
>         <servlet-class>com.mycompany.mypackage.MyServlet</servlet-class>
>     </servlet>
> 
>     <servlet-mapping>
>         <servlet-name>MyServlet</servlet-mapping>
>         <url-pattern>*.j</url-pattern>
>     </servlet-mapping>
> 
> and this rule would get applied to all incoming requests -- a request for "foo.j"
> would be sent to your servlet, while a request for "foo.html" would be handled by the
> default file-serving servlet.
> 
> In Tomcat4+Apache, you do *exactly* the same thing.  The only difference at runtime is
> that Apache becomes the "default file-serving servlet" instead of the servlet inside
> Tomcat.
> 
> Does that help?
> 
> >
> > > At any rate, this is the theory -- Pier can comment on current practice.  I know
> > > he's working on a bunch of bug fixes for the originally reported problems.
> > >
> > > Craig
> >
> > I would like to have it work in my case, but in order for me to help make
> > it happen, I need to understand the goal, which I don't understand. If you
> > or Pier can nurse me along a bit, I will work on making it happen in my
> > case (I do know C) and give it back to the community.
> >
> > Thanks a ton anyway, Craig.
> >
> > --
> > Nicolaus Bauman
> > Software Engineer
> > Simplexity Systems
> >
> 
> Craig
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
> 

-- 
Nicolaus Bauman
Software Engineer
Simplexity Systems



Re: Catalina + Apache

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Nick Bauman wrote:

> On Fri, 19 Jan 2001, Craig R. McClanahan wrote:
>
> > Nick Bauman wrote:
> >
> > > Uhhh, I just realized something
> > >
> > > With TC 3x, you could map an extension from Apache to the servlet engine
> > > with an AddHandler directive. I see nothing like this for TC4. Can someone
> > > enlighten me?
> > >
> >
> > The design goals for mod_webapp say that it should respect web.xml mappings --
> > in other words, if you added a <servlet-mapping> entry for "*.foo" to a
> > particular servlet, then that is what would happen at runtime.
>
> I totally do not understand this! I'm dense or something: How does Apache
> / DSO* know about something in the web.xml?
>

This is the key architectural difference between mod_webapp and the current generation
of connectors.  When mod_webapp establishes its initial connection from Apache to
Tomcat, the configuration information (extracted from the property getters of the
internal Context object) is sent back to the connector in order to configure
everything about this particular webapp.

Re: Catalina + Apache

Posted by Nick Bauman <ni...@cortexity.com>.
On Fri, 19 Jan 2001, Craig R. McClanahan wrote:

> Nick Bauman wrote:
> 
> > Uhhh, I just realized something
> >
> > With TC 3x, you could map an extension from Apache to the servlet engine
> > with an AddHandler directive. I see nothing like this for TC4. Can someone
> > enlighten me?
> >
> 
> The design goals for mod_webapp say that it should respect web.xml mappings --
> in other words, if you added a <servlet-mapping> entry for "*.foo" to a
> particular servlet, then that is what would happen at runtime.

I totally do not understand this! I'm dense or something: How does Apache
/ DSO* know about something in the web.xml?

If I grok you, this still relies on having /foo mapped to the servlet
container in Apache. I'm in a situation where Apache's DocumentRoot _is
the same as_ the top level of the WAR, but I want Apache to serve the
*.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp
and a special mapping (in this case *.j).

> The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind
> Apache is the mapping for the "default" servlet.  In the stand-alone case, this
> is mapped to the Tomcat servlet that serves static resources.  In the connected
> case, they would be served by Apache.

I don't see how this works in my case. I'm being dense, I think.

> At any rate, this is the theory -- Pier can comment on current practice.  I know
> he's working on a bunch of bug fixes for the originally reported problems.
> 
> Craig

I would like to have it work in my case, but in order for me to help make
it happen, I need to understand the goal, which I don't understand. If you
or Pier can nurse me along a bit, I will work on making it happen in my
case (I do know C) and give it back to the community.

Thanks a ton anyway, Craig.

-- 
Nicolaus Bauman
Software Engineer
Simplexity Systems



Re: Catalina + Apache

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Nick Bauman wrote:

> Uhhh, I just realized something
>
> With TC 3x, you could map an extension from Apache to the servlet engine
> with an AddHandler directive. I see nothing like this for TC4. Can someone
> enlighten me?
>

The design goals for mod_webapp say that it should respect web.xml mappings --
in other words, if you added a <servlet-mapping> entry for "*.foo" to a
particular servlet, then that is what would happen at runtime.

The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind
Apache is the mapping for the "default" servlet.  In the stand-alone case, this
is mapped to the Tomcat servlet that serves static resources.  In the connected
case, they would be served by Apache.

At any rate, this is the theory -- Pier can comment on current practice.  I know
he's working on a bunch of bug fixes for the originally reported problems.

Craig



Re: Catalina + Apache

Posted by Nick Bauman <ni...@cortexity.com>.
Uhhh, I just realized something

With TC 3x, you could map an extension from Apache to the servlet engine
with an AddHandler directive. I see nothing like this for TC4. Can someone
enlighten me?

On Thu, 18 Jan 2001, Nick Bauman wrote:

> Hello Jakarta Tribe,
> 
> We are targeting Tomcat 4.0 for a project to be released within 30
> days. We currently have an app in production at Exodus in Chicago that
> utilizes many megabits of throughput and runs on multiple webservers that 
> are load balanced using TC 3.1 and Apache 1.3. This is a new release of
> this app.
> 
> I have some questions:
> 
> 1) If we are choosing to go with 4.0, should we also be taking a look at
> Apache 2.0? How far has the integration come on that front?
> 
> 2) Using the mod_webapp.so, do we need to specify a "Tomcat
> Standalone" service with our ROOT context, or is the
> "Tomcat-Apache" all we need (and we should define the ROOT context int
> there)
> 
> Thanks,
> 
> -Nick Bauman
> (The guy running BugRat for Jakarta)
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
> 

-- 
Nicolaus Bauman
Software Engineer
Simplexity Systems