You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Parsons Technical Services <pa...@earthlink.net> on 2004/02/15 07:51:07 UTC
Re: jsp deployment-- Clarification of Invoker
My understanding of invoker and my attempt to explain invoker and mapping.
Please correct any error I have made.
Jerry Ford wrote:
> I don't fully understand the invoker servlet myself, but here's what I
> think I know:
>
> The invoker mapping only applies to servlets, not html or jsps, and the
> servlets are working (at least through Apache).
True. But if you have any links in the html or jsp page, it can prevent them
from being displayed, at least this was true in my case.
>If the invoker mapping
> specifies /servlets/* then "servlets" must be included in the URL. By
> taking it out of the invoker mapping, it does not need to be included in
> the URL. So, http://localhost/servlets/do_something is required if the
> mapping is as you say it should be, and http://localhost/do_something is
> the URL if the mapping is as I have it.
My current understanding is that without the invoker you have to use the
full path including the package designation. Unless.. See below.
With the invoker it will run ANY servlet in you app by entering the desired
or undesired URL. IE it is a security issue. http://localhost/servlets/?
when a value matching any of your servlets is entered it is run.
As I stated earlier I wastn't hitting any servlets directly from the URL so
I cannot attest to if this will work as you have it. All I know at this
point is that my setup would not work this way /* but did with /servlet/*.
But you are correct that you must have servlet in the URL in order for it to
match the pattern with it my way.
Now for the kicker. As stated above, the invoker is considered a security
risk and should not be used. Instead you should define mapping for your
servlets. Once this is done you can access only servlets that you want to be
available from the outside and protect the ones you don't. And on top of
that you can use any name you wish rather then the name of the servlet.
>From you web.xml you have:
<servlet>
<servlet-name>
set_config
</servlet-name>
<servlet-class>
catseye.ebook.set_config
</servlet-class>
</servlet>
This can be mapped by:
<servlet-mapping>
<servlet-name>set_config</servlet-name>
<url-pattern>/sconfig</url-pattern>
<servlet-mapping>
You can the call this servlet from within a html or jsp page with ./sconfig
(don't miss leading period) or from the URL with
http://localhost/EBook/sconfig . As pointed out in several articles if you
change the name of the servlet the only change you have is in the mapping.
All references will still point to sconfig that is mapped to the desired
servlet.
And yes I had code issues that cause me to require the invoker. Once I
changed them to ./name the mapping then worked
and I was able to remove the invoker completely.
Sorry for the long post but thought I would pass along what I found out.
Hope it helps.
Doug Parsons
www.parsonstechnical.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: jsp deployment-- Clarification of Invoker
Posted by BAO RuiXian <ru...@pp.inet.fi>.
Unable to check all the mails. But, glad to hear you and Doug together
solved your problem.
Cheers
Bao
Jerry Ford wrote:
> Well, that was certainly fun :)
>
> I have made it work, and I think I sort of know how. Not *why* the
> fix works, just *how* to get my app functional once again.
>
> And you are correct, Doug, in aiming me at the invoker servlet as the
> culprit.
>
> The solution that worked for me is to remove the invoker
> servlet-mapping element from my web app and map each servlet
> individually. (Though beware---all servlets must be defined before
> any mapping elements are added to the web.xml file, or else the parser
> will throw an exception. Spent a good couple of hours or more
> fighting that little firefight on the sidelines.)
>
> Don't understand why the presence of the invoker should foul up the
> operation of the jsp, but when I removed it and got the
> servlet/servlet-mapping order straight, suddenly the webapp worked,
> including the jsp, and both using Tomcat by itself and going through
> Apache.
>
> Thanks for all who helped.
>
> Jerry
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: jsp deployment-- Clarification of Invoker
Posted by Parsons Technical Services <pa...@earthlink.net>.
Jerry,
This is one of the main reasons I'm on this list. It peaks my curiosity to
learn about the how's and whys. Currently I only have one machine running
for development but that can change at any time and its little things like
this that help prepare me. Also another caveat of the invoker, if you app
requires it there is a good chance that it won't work on non-tomcat systems
(like who would even run anything but) as so I read.
I have a theory and maybe someone can poke holes in it. If your pages have
links to servlets then TC will choke on the page because it can't find the
servlet and thus the page won't compile. If you have debugging turned up you
will see it in your logs, I think. For TC looks at the mapping to find the
servlet unless you have used the full URL or the invoker which mimics a
classpath and says you can find any servlet you are looking for in
...../servlet/ directory.
As for needing to define them first, sorry for not mentioning it. Just for
reference you must group the definitions first and then all the mapping. The
is a certain order to the web.xml that must be followed.
Glad to be of help.
Doug Parsons
www.parsonstechnical.com
> Well, that was certainly fun :)
>
> I have made it work, and I think I sort of know how. Not *why* the fix
> works, just *how* to get my app functional once again.
>
> And you are correct, Doug, in aiming me at the invoker servlet as the
> culprit.
>
> The solution that worked for me is to remove the invoker servlet-mapping
> element from my web app and map each servlet individually. (Though
> beware---all servlets must be defined before any mapping elements are
> added to the web.xml file, or else the parser will throw an exception.
> Spent a good couple of hours or more fighting that little firefight on
> the sidelines.)
>
> Don't understand why the presence of the invoker should foul up the
> operation of the jsp, but when I removed it and got the
> servlet/servlet-mapping order straight, suddenly the webapp worked,
> including the jsp, and both using Tomcat by itself and going through
Apache.
>
> Thanks for all who helped.
>
> Jerry
>
> Parsons Technical Services wrote:
>
> >My understanding of invoker and my attempt to explain invoker and
mapping.
> >Please correct any error I have made.
> >
> >Jerry Ford wrote:
> >
> >
> >
> >>I don't fully understand the invoker servlet myself, but here's what I
> >>think I know:
> >>
> >>The invoker mapping only applies to servlets, not html or jsps, and the
> >>servlets are working (at least through Apache).
> >>
> >>
> >
> >True. But if you have any links in the html or jsp page, it can prevent
them
> >from being displayed, at least this was true in my case.
> >
> >
> >
> >>If the invoker mapping
> >>specifies /servlets/* then "servlets" must be included in the URL. By
> >>taking it out of the invoker mapping, it does not need to be included in
> >>the URL. So, http://localhost/servlets/do_something is required if the
> >>mapping is as you say it should be, and http://localhost/do_something is
> >>the URL if the mapping is as I have it.
> >>
> >>
> >
> >My current understanding is that without the invoker you have to use the
> >full path including the package designation. Unless.. See below.
> >
> >With the invoker it will run ANY servlet in you app by entering the
desired
> >or undesired URL. IE it is a security issue. http://localhost/servlets/?
> >when a value matching any of your servlets is entered it is run.
> >
> >As I stated earlier I wastn't hitting any servlets directly from the URL
so
> >I cannot attest to if this will work as you have it. All I know at this
> >point is that my setup would not work this way /* but did with
/servlet/*.
> >
> >But you are correct that you must have servlet in the URL in order for it
to
> >match the pattern with it my way.
> >
> >Now for the kicker. As stated above, the invoker is considered a security
> >risk and should not be used. Instead you should define mapping for your
> >servlets. Once this is done you can access only servlets that you want to
be
> >available from the outside and protect the ones you don't. And on top of
> >that you can use any name you wish rather then the name of the servlet.
> >
> >>From you web.xml you have:
> > <servlet>
> > <servlet-name>
> > set_config
> > </servlet-name>
> > <servlet-class>
> > catseye.ebook.set_config
> > </servlet-class>
> > </servlet>
> >
> >This can be mapped by:
> ><servlet-mapping>
> > <servlet-name>set_config</servlet-name>
> > <url-pattern>/sconfig</url-pattern>
> ><servlet-mapping>
> >
> >You can the call this servlet from within a html or jsp page with
./sconfig
> >(don't miss leading period) or from the URL with
> >http://localhost/EBook/sconfig . As pointed out in several articles if
you
> >change the name of the servlet the only change you have is in the
mapping.
> >All references will still point to sconfig that is mapped to the desired
> >servlet.
> >
> >And yes I had code issues that cause me to require the invoker. Once I
> >changed them to ./name the mapping then worked
> >and I was able to remove the invoker completely.
> >
> >Sorry for the long post but thought I would pass along what I found out.
> >
> >Hope it helps.
> >
> >Doug Parsons
> >www.parsonstechnical.com
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: jsp deployment-- Clarification of Invoker
Posted by Jerry Ford <jf...@katzenjammer.us>.
Well, that was certainly fun :)
I have made it work, and I think I sort of know how. Not *why* the fix
works, just *how* to get my app functional once again.
And you are correct, Doug, in aiming me at the invoker servlet as the
culprit.
The solution that worked for me is to remove the invoker servlet-mapping
element from my web app and map each servlet individually. (Though
beware---all servlets must be defined before any mapping elements are
added to the web.xml file, or else the parser will throw an exception.
Spent a good couple of hours or more fighting that little firefight on
the sidelines.)
Don't understand why the presence of the invoker should foul up the
operation of the jsp, but when I removed it and got the
servlet/servlet-mapping order straight, suddenly the webapp worked,
including the jsp, and both using Tomcat by itself and going through Apache.
Thanks for all who helped.
Jerry
Parsons Technical Services wrote:
>My understanding of invoker and my attempt to explain invoker and mapping.
>Please correct any error I have made.
>
>Jerry Ford wrote:
>
>
>
>>I don't fully understand the invoker servlet myself, but here's what I
>>think I know:
>>
>>The invoker mapping only applies to servlets, not html or jsps, and the
>>servlets are working (at least through Apache).
>>
>>
>
>True. But if you have any links in the html or jsp page, it can prevent them
>from being displayed, at least this was true in my case.
>
>
>
>>If the invoker mapping
>>specifies /servlets/* then "servlets" must be included in the URL. By
>>taking it out of the invoker mapping, it does not need to be included in
>>the URL. So, http://localhost/servlets/do_something is required if the
>>mapping is as you say it should be, and http://localhost/do_something is
>>the URL if the mapping is as I have it.
>>
>>
>
>My current understanding is that without the invoker you have to use the
>full path including the package designation. Unless.. See below.
>
>With the invoker it will run ANY servlet in you app by entering the desired
>or undesired URL. IE it is a security issue. http://localhost/servlets/?
>when a value matching any of your servlets is entered it is run.
>
>As I stated earlier I wastn't hitting any servlets directly from the URL so
>I cannot attest to if this will work as you have it. All I know at this
>point is that my setup would not work this way /* but did with /servlet/*.
>
>But you are correct that you must have servlet in the URL in order for it to
>match the pattern with it my way.
>
>Now for the kicker. As stated above, the invoker is considered a security
>risk and should not be used. Instead you should define mapping for your
>servlets. Once this is done you can access only servlets that you want to be
>available from the outside and protect the ones you don't. And on top of
>that you can use any name you wish rather then the name of the servlet.
>
>>>From you web.xml you have:
> <servlet>
> <servlet-name>
> set_config
> </servlet-name>
> <servlet-class>
> catseye.ebook.set_config
> </servlet-class>
> </servlet>
>
>This can be mapped by:
><servlet-mapping>
> <servlet-name>set_config</servlet-name>
> <url-pattern>/sconfig</url-pattern>
><servlet-mapping>
>
>You can the call this servlet from within a html or jsp page with ./sconfig
>(don't miss leading period) or from the URL with
>http://localhost/EBook/sconfig . As pointed out in several articles if you
>change the name of the servlet the only change you have is in the mapping.
>All references will still point to sconfig that is mapped to the desired
>servlet.
>
>And yes I had code issues that cause me to require the invoker. Once I
>changed them to ./name the mapping then worked
>and I was able to remove the invoker completely.
>
>Sorry for the long post but thought I would pass along what I found out.
>
>Hope it helps.
>
>Doug Parsons
>www.parsonstechnical.com
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org