Hello, Christopher!

I cannot use a request parameter because the "legacy" application is
inside an iframe.
If I passed it as a request parameter in the iframe it would only work
the first time, because once you click a link inside the iframe the
parameter wouldn't be there.

Remember that the tricky part here is that the "legacy" application is
not to be changed.

When setting an URL like [/context/_session_id_/page1.jsp] for the
iframe, any link will be automatically relative to
[/context/_session_id_/] except in the cases were getContextPath() is
used. For these cases my request wrapper should provide the same dummy
url when getContextPath() is called.

btw, I'm with you on the PITA thing :)

Best regards!

On Sat, Jul 11, 2009 at 9:45 PM, Christopher
Schultz<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ivo,
>
> On 7/9/2009 6:32 AM, Ivo Silva wrote:
>> 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.
>
> What if you used a request parameter instead of request path info?
>
> So, to re-state, you want to take the following URLs and make them serve
> a single page, after "unwrapping" a special session that is stored in
> the main session:
>
> /context/X/page_1.jsp
> /context/Y/page_1.jsp
> /context/Z/page_1.jsp
>
> ??
>
> I still don't understand why the URL rewriting is necessary, though I
> *do* understand the session multiplexing (which is a total PITA, BTW).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkpY+gEACgkQ9CaO5/Lv0PBBSgCePoHoEKENfgUJGLdQe4O90Zjr
> xcYAn11zYGYzlnlWHwib0bA8O7O8RtYy
> =XEcl
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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

Reply via email to