On 9/7/09 11:32, Ivo Silva wrote:
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) :)
At this stage I'd cut my losses and start over with an alternative
solution, like using a request attribute instead of a session attribute.
Your filter acts during every request anyway, whereas the session
contents should only need setting once.
If you've got enough control over your legacy app to do that, then
you're in business.
p
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
