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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
