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