Re: jsp deployment-- Clarification of Invoker
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp deployment-- Clarification of Invoker
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-nameset_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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp deployment-- Clarification of Invoker
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-nameset_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
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-nameset_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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
