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