At 01:48 PM 1/8/2003, you wrote:
So you're talking about using the sorts of Filters available as of the
Servlet 2.3 spec?  That actually sounds promising, I'll take a look at it.
Yep.

One thing that bothers me about my current plan though is that I feel like
I'm not making use of some of the functionality potentially provided by
Apache itself, especially in the area of authentication and access control.

There certainly is some overlap between those services as outlined in the
Servlet spec, and the functionality provided by Apache itself.  Are there
any general rules of thumb for when to use
the services of Apache vs. Tomcat in these areas? Or at least some good
resources that go into these issues?
I've never used Apache for much of anything besides static content serving or occasional URL manipulation, so I'm not qualified on the topic. I would say, though, that the vast majority of jsp/servlet applications (and hence the vast majority of people on this list) can fill their funtional needs efficiently and easily without using Apache's "advanced" services. I would personally rather deal with only Tomcat if I had the choice ... and judging from the difficulties people on this list have with the integration of the two, I would venture to say that opinion is probably in the majority.

Perhaps someone else has some more complete thoughts for you...

justin



----- Original Message -----
From: "Justin Ruthenbeck" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 3:40 PM
Subject: Re: Servlet Mapping Strategy w/ user-specific URLs


>
> There's no way to accomplish what you're shooting for using only the
> mappings in the web.xml.  However, you could pretty easily do it through a
> filter running on requests to "/user/*".  If you do this, you could
forward
> any requests that match URI "/user" to your UserServlet and anything that
> matches "/user/*/resource/*" to your ResourceServlet by parsing the URI
> String in your own code.
>
> Hope that helps ... let me know if it's not clear.
>
> justin
>
> At 12:12 PM 1/8/2003, you wrote:
> >I would like to have a url structure of the form:
> >
> >     myplace.com/user/xxx/resource/yyy
> >
> >where "user" and "resource"
> >
> >are handled by individual servlets.  I would like users to have the
> >ability to POST
> >there username/password to /user and have it respond with their personal
> >url, e.g.:
> >
> >     /user/some-user
> >
> >A "UserServlet" would be responsible to setting up the appropriate
> >authentication,
> >so that they could GET/POST (assuming proper authentication) to
> >
> >     /user/some-user/resource
> >
> >Is it possible to setup a servlet mapping such that a UserServlet handles
> >requests to /user/xxx, but a ResourceServlet handles requests to
> >/user/xxx/resource/yyy?
> >
> >I can't think of how to do this and am currently planning on using
mod_rewrite
> >to rewrite the urls as appropriate since I have Apache 2 sitting in front
of
> >Tomcat.
> >
> >Is there perhaps a better way of handling this that I haven't
> >considered?  That
> >is, perhaps taking advantage of some aspect of Apache itself that I
> >haven't thought of?
> >
> >Any help in this regard would be greatly appreciated.
> >
> >- Jeff
> >
>
>
> ____________________________________
> Justin Ruthenbeck
> Software Engineer, NextEngine Inc.
> [EMAIL PROTECTED]
> Confidential -
>     See http://www.nextengine.com/confidentiality.php
> ____________________________________
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

____________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
[EMAIL PROTECTED]
Confidential -
   See http://www.nextengine.com/confidentiality.php
____________________________________


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to