Great, now I am confused... :)
No, what you read in my comments is correct...
The fact that both "quiz" and "Quiz" are accepted in the URL is entirely
dependent on the implementation of the InvokerInterceptor. Other
servlet containers may or may not have such an interceptor configured.
Containers configured for production use (including tomcat) probably
will not.
To comply with the servlet spec, a servlet must be mapped to a
url-pattern in a <servlet-mapping> in web.xml like
<servlet-mapping>
<servlet-name>quiz</servlet-name>
<url-pattern>/quiz</url-pattern>
</servlet-mapping>
Relying on the presence of a /servlet/* interceptor would be
non-portable.
Luc
P.s.: Apparently you are on GMT-6, I'm on GMT+1. Don't count on fast
replies :)
> > <servlet-mapping>
> > <servlet-name>quiz</servlet-name>
> > <url-pattern>/quiz</url-pattern>
> > </servlet-mapping>
Jacob Kjome wrote:
>
> Thanks, Luc
>
> But I'm not sure if you answered my question or not.
>
> I understand the /servlet/ stuff and that you can even leave out any
> registration of a servlet and see that servlet under, for example,
> /servlet/Quiz (as long as the class is named Quiz.class with case being
> meaningful).
>
> The thing I'm seeing, but not sure why, is that when actaully
> registering a servlet like:
>
> <servlet>
> <servlet-name>quiz</servlet-name>
> <servlet-class>Quiz</servlet-class>
> </servlet>
>
> you can now reference the serlvet in question by calling it with the
> spelling in either the <servlet-name> or <servlet-class>.
>
> Maybe that is what you just said.
>
> The thing is, you can throw out the fact that Tomcat uses /servlet/ in
> the default settings for the RequestInterceptor in server.xml. That
> path can be different among servlet runners. As long as the URL in your
> HTML is relative and is written like href="./quiz", you will be on
> target either way. Now, if you've gotten to the servlet successfully
> already, the URL referencing back to itself will always be correct.
>
> The issue now becomes only "will other servlet runner
> RequestInterceptor's recognize the spellings of both <servlet-name> and
> <servlet-class> to invoke the Quiz.class servlet"?
>
> I think you may have answered the above question by saying that Tomcat's
> RequestInterceptor, specifically, accepts both the <serlvet-name> and
> <servlet-class> spellings when referencing the servlet (that is
> referencing Quiz.class as /Quiz or /quiz) in a URL but that this is NOT
> a behavior that can be counted on by other servlet runner
> RequestInterceptor's.
>
> Am I reading you correctly?
>
> Jake
>
> -----Original Message-----
> From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 03, 2001 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: curious behavior - pseudo servlet-mapping with mod_jk
>
> That's because you're using the InvokerInterceptor that is mapped to all
> /servlet/ requests.
>
> In your server.xml file you'll see the entry:
> <RequestInterceptor
> className="org.apache.tomcat.request.InvokerInterceptor"
> debug="0" prefix="/servlet/" />
>
> It is just a handy tool to use during development that allows you to
> call any servlet without having to register it in <servlet-mapping>.
> Apparently it accepts both the class name and the servlet name to invoke
> a servlet. For servlets that are defined within a package, you'd use
> http://localhost/mycontext/servlet/xxx.yyy.mypackage.Quiz (could be that
> it must be http://localhost/mycontext/servlet/xxx/yyy/mypackage/Quiz,
> not sure) with Quiz being in the appropriate sub-/sub-/subdirectory
> under /WEB-INF/classes.
>
> Most servlet-containers will have a similar mechanism, but I don't think
> there's really a standard, so for production you'd better use the
> standard <servlet-mapping> entries.
>
> Luc Vanlerberghe
>
> Jacob Kjome wrote:
> >
> > I just noticed something that seems to work for me, but I can't
> determine
> > quite why? Maybe someone can confirm that this is expected behavior
> or
> > not.....
> >
> > I am running Tomcat 3.2.1 on Windows 2000
> >
> > It seems that if you have a servlet registered in web.xml like this:
> >
> > <servlet>
> > <servlet-name>quiz</servlet-name>
> > <servlet-class>Quiz</servlet-class>
> > </servlet>
> >
> > AND you have the default values in mod_jk.conf:
> >
> > JkMount /mycontext/*.jsp ajp13
> > JkMount /mycontext/servlet/* ajp13
> >
> > you are able to access the above servlet at either of the following
> URL's:
> >
> > http://localhost/mycontext/servlet/Quiz
> > http://localhost/mycontext/servlet/quiz
> >
> > Notice the case difference in Quiz/quiz
> >
> > It seems that the <servlet-name> provides a rudimentary amount of
> servlet
> > mapping.
> >
> > I tested this theory by changing the <servlet-name> to "quiza" and
> testing
> > that. After I did that, "Quiz" and "quiza" worked, but "quiz" did
> not.
> >
> > NOTE: This was done WITHOUT servlet mapping tags such as:
> >
> > <servlet-mapping>
> > <servlet-name>quiz</servlet-name>
> > <url-pattern>/quiz</url-pattern>
> > </servlet-mapping>
> >
> > So, it seems you can very simply (without complex servlet mappings)
> make
> > your servlet case insensitive; that is in First letter upper case java
> > style class naming syntax OR all lower case.
> >
> > HOWEVER,
> >
> > I am not sure if this is portable accross servers!!!!!!!!!
> >
> > Can someone confirm that this isn't just a quirk of Tomcat? Should it
> work
> > this way based on the servlet spec???? Is it portable across servlet
> > runners???? Does this work on Tomcat 4.0????
> >
> > Jake
> >
> > ---------------------------------------------------------------------
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
