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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
