Hi, there!
To both browser and Tomcat it's only one session. My filter is what
manages the "nested" sessions distribution and that's why an
identifier is required.
Each iframe should have it's own session since the application stores
data on session. If I do not provide different sessions the variables
would overwrite each other and each iframe would have the same
information.
I'll try to do some debugging over Tomcat's source to find out what
the forward method is doing and get back to you if I found some
solution (or not) :)
Thanks again for your time, Pid!
On Thu, Jul 9, 2009 at 11:22 AM, Pid<p...@pidster.com> wrote:
> On 9/7/09 11:04, Ivo Silva wrote:
>>
>> Hi, again! :)
>>
>>> Sounds like a conflicting requirement to me.
>>
>> It's a very odd scenario indeed but it was working fine till I bumped
>> into a forward.
>>
>>> What version of Tomcat are you using, sorry?
>>
>> I'm using Tomcat 6.0.20.
>>
>>> So, to be clear, you want the legacy application to see the context path
>>> as:
>>> /context/session1?
>>
>> Yes, I want my legacy application to see the dummy context path (equal
>> to the source of the iframe). As you stated: /context/session1. So
>> that my filter can keep track of the correct session to inject.
>>
>>> When you say "Session" do you actually mean a
>>> javax.servlet.http.HttpSession
>>> or something else? If something else, what is that you mean?
>>
>> Yes, it's an implementation of the HttpSession.
>
> So you're trying to use different user sessions within the same browser
> window?
>
> That sounds like a recipe for disaster, what do you need to put in the
> session that's different for different parts/iframes of the site?
>
>
> I suspect that your chosen method will fail because the contextPath is
> probably accessed by various things, including the forward method, to
> determine the true path to which the request must be directed.
>
> p
>
>
> (P.S. Just reply to the list please.)
>
>
>> Thanks!
>>
>>
>> On Thu, Jul 9, 2009 at 10:54 AM, Pid<p...@pidster.com> wrote:
>>>
>>> On 9/7/09 10:00, Ivo Silva wrote:
>>>>
>>>> Hello, Pid!
>>>>
>>>> The target pages are part of a "legacy" application that is not to be
>>>> changed but now it must be possible to have several instances on the
>>>> same page (requiring each application to be contextualized).
>>>
>>> Sounds like a conflicting requirement to me.
>>>
>>>> Each instance is placed on an iframe with a unique URL
>>>> (/context/dummy_url_1/page1.jsp).
>>>>
>>>> That [dummy_url_1] is what identifies the Session to be used.
>>>>
>>>> 1 - The first step is to wrap the request in my filter pass it to the
>>>> URL Rewrite filter and then to the page. This works except on the
>>>> cases when the "legacy" application uses:
>>>>
>>>> <%= request.getContextPath() %>
>>>>
>>>> When using this it considers that the context path is /context/ and
>>>> not /context/dummy_url_1. Which is ok. But this causes the "legacy"
>>>> application to get out of context.
>>>
>>> What version of Tomcat are you using, sorry?
>>>
>>> So, to be clear, you want the legacy application to see the context path
>>> as:
>>> /context/session1?
>>>
>>> When you say "Session" do you actually mean a
>>> javax.servlet.http.HttpSession
>>> or something else? If something else, what is that you mean?
>>>
>>>
>>> p
>>>
>>> (just reply to the list, not me as well, please.)
>>>
>>>
>>>> 2 - The second step was to try and trick the "legacy" application
>>>> overriding the getContextPath() method. This doesn't work when using
>>>> the URL Rewrite filter since it overrides my changes, so I thought of
>>>> rewriting the URL myself. Once again, this works ok except on the
>>>> RequestDispatcher.forward() case.
>>>>
>>>> What allows the page to be displayed (not giving a 404 when looking
>>>> for a dummy folder) is overriding the getServletPath() method. The
>>>> ironic part is that this is what causes the infinite loop when using
>>>> forward.
>>>>
>>>>
>>>> In the middle of all of this I just want to understand why forward
>>>> enters a loop.
>>>> I've also tried to overwrite the "javax.servlet.forward.servlet_path"
>>>> request attribute and its "friends" but to no avail.
>>>
>>>
>>> p
>>>
>>>
>>>> Thanks again, Pid!
>>>>
>>>>
>>>> On Thu, Jul 9, 2009 at 9:14 AM, Pid<p...@pidster.com> wrote:
>>>>>
>>>>> On 8/7/09 19:30, Ivo Silva wrote:
>>>>>>
>>>>>> Sure, no problemo! :)
>>>>>>
>>>>>> This is in fact very simple.
>>>>>>
>>>>>> My web.xml has a normal filter configuration:
>>>>>>
>>>>>> <filter>
>>>>>> <filter-name>Test Filter</filter-name>
>>>>>> <filter-class>tests.TestFilter</filter-class>
>>>>>> </filter>
>>>>>> <filter-mapping>
>>>>>> <filter-name>Test Filter</filter-name>
>>>>>> <url-pattern>/*</url-pattern>
>>>>>> </filter-mapping>
>>>>>>
>>>>>> The RequestWrapper is this:
>>>>>>
>>>>>> public class RequestWrapper extends HttpServletRequestWrapper {
>>>>>> private String _servletPath = null;
>>>>>>
>>>>>> public RequestWrapper(HttpServletRequest request) {
>>>>>> super(request);
>>>>>> }
>>>>>>
>>>>>> (...)
>>>>>>
>>>>>> /**
>>>>>> * the problem happens when I set the servlet path
>>>>>> * /dummy/page1.jsp> /page1.jsp
>>>>>> *
>>>>>> * URL, URI, ContextPath can be changed and
>>>>>> * everything works fine, but not servletPath
>>>>>> */
>>>>>> public String getServletPath() {
>>>>>> if(_servletPath != null) {
>>>>>> return _servletPath;
>>>>>> } else {
>>>>>> return super.getServletPath();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> public void rewriteServletPath(String servletPath) {
>>>>>> _servletPath = servletPath;
>>>>>> }
>>>>>>
>>>>>> (...)
>>>>>> }
>>>>>>
>>>>>> The doFilter does this:
>>>>>>
>>>>>> RequestWrapper req = new RequestWrapper(request);
>>>>>> req.rewriteServletPath("/page1.jsp"); // this causes the loop
>>>>>> chain.doFilter(req, servletResponse);
>>>>>>
>>>>>>
>>>>>> What I don't understand is why forward can't read my RequestWrapper
>>>>>> correctly. I might need to override some other variable to make
>>>>>> servletPath rewrite work.
>>>>>
>>>>> OK, why do you need to rewrite the servlet path?
>>>>>
>>>>> p
>>>>>
>>>>>
>>>>>> Thanks again!
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 8, 2009 at 6:30 PM, Pid<p...@pidster.com> wrote:
>>>>>>>
>>>>>>> On 8/7/09 18:20, Ivo Silva wrote:
>>>>>>>>
>>>>>>>> Thanks for your reply, Pid!
>>>>>>>>
>>>>>>>> I'm not sure I understand your explanation.
>>>>>>>
>>>>>>> Maybe I misunderstood you.
>>>>>>>
>>>>>>> What are you modifying in the wrapped request?
>>>>>>>
>>>>>>> What is in your web.xml for the filter?
>>>>>>>
>>>>>>> How and where are you executing the forward to page2.jsp and what
>>>>>>> happens
>>>>>>> if
>>>>>>> the logic there fails?
>>>>>>>
>>>>>>> You might consider telling us a little bit more about what it is that
>>>>>>> you're
>>>>>>> actually trying to achieve.
>>>>>>>
>>>>>>> p
>>>>>>>
>>>>>>>
>>>>>>>> Here's the sequence:
>>>>>>>>
>>>>>>>> 1. Request (browser)
>>>>>>>> 2. My Filter (generates a wrapped request and passes it to the
>>>>>>>> chain)
>>>>>>>> 3. page1.jsp (my wrapped request is here and I can access everything
>>>>>>>> just
>>>>>>>> fine)
>>>>>>>>
>>>>>>>> The following steps are the problem:
>>>>>>>>
>>>>>>>> 4. page1.jsp (.forward(MyWrappedRequest, response))
>>>>>>>> 5. page2.jsp (the request never gets to this page, instead it loops
>>>>>>>> back to page1.jsp)
>>>>>>>>
>>>>>>>> At a first glance I would expect this to work, so I guess that I
>>>>>>>> might
>>>>>>>> be missing some step along the way... maybe something else must be
>>>>>>>> wrapped?!
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> On Wed, Jul 8, 2009 at 6:06 PM, Pid<p...@pidster.com> wrote:
>>>>>>>>>
>>>>>>>>> On 8/7/09 18:00, Ivo Silva wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for your reply, André!
>>>>>>>>>>
>>>>>>>>>> I believe my situation is a bit more complex than a "simple" URL
>>>>>>>>>> Rewrite.
>>>>>>>>>>
>>>>>>>>>> Short explanation:
>>>>>>>>>> My aim is to create a RequestWrapper with a custom Session so that
>>>>>>>>>> the
>>>>>>>>>> target page has access to some specific variables that cannot be
>>>>>>>>>> store
>>>>>>>>>> in the regular session due to iframe instatiaton...
>>>>>>>>>>
>>>>>>>>>> Nevertheless using URL Rewrite doesn't solve my problem (maybe if
>>>>>>>>>> I
>>>>>>>>>> use it after may own filter it could be helpful but not for my
>>>>>>>>>> specific problem).
>>>>>>>>>>
>>>>>>>>>> My problem is that my RequestWrapper (with my custom Session) is
>>>>>>>>>> not
>>>>>>>>>> getting past the forward declaration. The Request Dispatcher
>>>>>>>>>> forward
>>>>>>>>>> seems to use the original request instead of my wrapper when doing
>>>>>>>>>> a
>>>>>>>>>> forward.
>>>>>>>>>
>>>>>>>>> Filters are not applied during the RequestDispatcher.forward()
>>>>>>>>> operation.
>>>>>>>>>
>>>>>>>>> You would need to wrap any unwrapped requests before passing a
>>>>>>>>> modified
>>>>>>>>> request to the forward method.
>>>>>>>>>
>>>>>>>>> p
>>>>>>>>>
>>>>>>>>>> If the target page doesn't have forward all works fine.
>>>>>>>>>>
>>>>>>>>>> So, don't mind about the URL Rewrite part, I just want to know if
>>>>>>>>>> it's
>>>>>>>>>> possible to create a request wrapper and pass it on to a second
>>>>>>>>>> page
>>>>>>>>>> (with a forward on the first page). Currently I get an infinite
>>>>>>>>>> loop.
>>>>>>>>>>
>>>>>>>>>> Thanks again!
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 8, 2009 at 4:43 PM, André Warnier<a...@ice-sa.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Ivo Silva wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello, there!
>>>>>>>>>>>>
>>>>>>>>>>>> I'm trying to implement a filter that takes a given request URL
>>>>>>>>>>>> (that
>>>>>>>>>>>> contains a dummy folder) like so:
>>>>>>>>>>>>
>>>>>>>>>>>> http://localhost/context/dummy_folder/page1.jsp
>>>>>>>>>>>>
>>>>>>>>>>>> This filter takes the dummy_folder part from the URL (just like
>>>>>>>>>>>> a
>>>>>>>>>>>> URL
>>>>>>>>>>>> Rewrite), creates a custom RequestWrapper
>>>>>>>>>>>> (HttpServletRequestWrapper)
>>>>>>>>>>>> with the correct paths (URI, URL, Servlet Path...) and passes it
>>>>>>>>>>>> to
>>>>>>>>>>>> the filter chain.
>>>>>>>>>>>>
>>>>>>>>>>>> By "correct path" I mean: http://localhost/context/page1.jsp
>>>>>>>>>>>>
>>>>>>>>>>>> Every thing works great except when the target page (page1.jsp)
>>>>>>>>>>>> does
>>>>>>>>>>>> a
>>>>>>>>>>>> forward request:
>>>>>>>>>>>>
>>>>>>>>>>>> RequestDispatcher rd =
>>>>>>>>>>>> request.getRequestDispatcher("page2.jsp");
>>>>>>>>>>>> rd.forward(request, response);
>>>>>>>>>>>>
>>>>>>>>>>>> This leads the requests to an infinite loop that keeps coming
>>>>>>>>>>>> back
>>>>>>>>>>>> to
>>>>>>>>>>>> page1.jsp.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't know if this is the correct approach (using an
>>>>>>>>>>>> HttpServletRequestWrapper to override the original request
>>>>>>>>>>>> values).
>>>>>>>>>>>> The request forwarding uses the original request instead of my
>>>>>>>>>>>> wrapper.
>>>>>>>>>>>>
>>>>>>>>>>>> Any directions would be appreciated.
>>>>>>>>>>>>
>>>>>>>>>>> Why redo what has been done before ?
>>>>>>>>>>> Check : http://www.tuckey.org/urlrewrite/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>
>>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
