1) Check the ServletContext class, it has a getContext method to get a ServletContext object of another web app on the same container. You can get a RequestDispatcher on that ServletContext object.
2) I don't necessarily agree with the second answer...
@ankit - the first one i got it absolutely. thanks
the second one - try to understand this question
URL rewritting is used by using the encodeURL and encodeRedirectURL methods. But when you are submitting a form you use action="url string" thats it. you cannot encode your url from here can you?
From what i read in whizlabs is that while FORM submit one has to use Hidden Variable to keep state and while using hyperlinks one has to use URL rewritting.(given cookies are disabled)
Marcus Tiwari wrote:But when you are submitting a form you use action="url string" thats it. you cannot encode your url from here can you?
You can encode (rewrite) the URL. You can use c:url tag.
From what i read in whizlabs is that while FORM submit one has to use Hidden Variable to keep state and while using hyperlinks one has to use URL rewritting.(given cookies are disabled)
Hidden form fields cannot be used to maintain the normal session behavior that we use. The session ID value can either be sent using Cookie (the cookie's name is JSESSIONID) or URL rewriting. When you use a hyperlink, then cookies are not disabled. The browser sends the JSESSIONID cookie to the server when you click on a hyperlink too...
Frits Walraven
,
Creator of Enthuware JWS+ V6
staff
Hidden form fields cannot be used to maintain the normal session behavior that we use.
In normal circumstances you would use either URL rewriting or Cookies for session management, but there is another way of maintaining state and that is by using hidden fields. It seems Whizlabs doesn't explain how that works. Let me try to give you an idea how that works:
Where you would normally store an object in the HttpSession object, you now serialize it into a String and send it all the way to the jsp (where you let it be submitted back with the next form submit as an hidden field). In the next action you will get the String object from the request and deserialize into an Object again. The web-container has no idea that those two requests belong to the same session (if Cookies are switched off and URL rewriting is not used) as you are maintaining the state, hence HttpServletRequest.isRequestedSessionIdFromCookie() and HttpServletRequest.isRequestedSessionIdFromURL() are both false.
so Frits sets it up that Hidden Fields can be used to maintain state.
But Frits the question is
Rewritten URLs is not an efficient method used for state management is case the client submits an HTML form rather than clicking an hyperlink?
True / False
Frits Walraven
,
Creator of Enthuware JWS+ V6
staff
Ankit Garg wrote:1) Check the ServletContext class, it has a getContext method to get a ServletContext object of another web app on the same container. You can get a RequestDispatcher on that ServletContext object.
By specs this is allowed to return null.
If we talk about tomcat, then you need to set crossContext=true (false by default) in order to get the Context of another app within the same container.
I am using Tomcat 5.5. In the following code I am trying to get ServletContext for another
application "appl2" but it is returning null. Current application is "appl1".
Hi Frits , it seems like i got what the authors of the writers meant when they were saying efficiency while submitting FORM
Rewritten URLs is not an efficient method used for state management is case the client submits an HTML form rather than clicking an hyperlink?
Look it is problematic to use Rewritten URLs when using FORM BASED authentication as spec says
Form based login and URL based session tracking can be problematic to implement.
Form based login should be used only when sessions are being maintained by
cookies or by SSL session information.
So i think on this they made this question.
Frits Walraven
,
Creator of Enthuware JWS+ V6
staff
Hmm, I see, but if they meant that part of the specs they should have talked about FORM based authentication instead of submitting a HTML form.
I don't think BASIC and FORM based authentication should be used outside a SSL enviroment anyway because of the lack of encryption of the username and password....
Regards,
Frits
Post by:autobot
Oh, sure, you could do that. Or you could eat some pie. While reading this tiny ad:
a bit of art, as a gift, the permaculture playing cards