Hi, Pid! How are you?
As I said, we now have a working solution, currently in tests, but so
far so good.
Nevertheless this is always a good exercice to better understand the
inner workings of our fellow Tom, the cat!
Cheers!
On 7/13/09, Pid wrote:
> On 13/7/09 20:51, Ivo Silva wrote:
>> Hi aga
On 13/7/09 20:51, Ivo Silva wrote:
Hi again, Christopher!
Yes, but that is the last resort!
We are still testing this approach but all is working as expected.
The main reason to adopt this is to provide the possibility to deploy
the legacy application in a portal environment (as a portlet) and
Hi again, Christopher!
Yes, but that is the last resort!
We are still testing this approach but all is working as expected.
The main reason to adopt this is to provide the possibility to deploy
the legacy application in a portal environment (as a portlet) and to
allow instatiation whitout requiri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ivo,
On 7/13/2009 2:28 PM, Ivo Silva wrote:
> 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
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 tric
-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 sin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pid,
On 7/8/2009 1:06 PM, Pid wrote:
> Filters are not applied during the RequestDispatcher.forward() operation.
They can be, if configured with FORWARD in
web.xml when using a Servlet 2.5-compliant webapp.
> You would need to wrap any unwrapped req
27;expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci
> est interdite. Ce message sert à l'information seulement et n'aura pas
> n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la mani
nt donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Thu, 9 Jul 2009 11:32:48 +0100
> Subject: Re: Filter RequestWrapper
> From: strikedae...@gmail.com
> To: users@tomcat.apache.org; p..
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 no
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 var
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 app
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).
Each instance is placed on an iframe with a unique URL
(/context/dummy_url_1/page1.js
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:
Test Filter
tests.TestFilter
Test Filter
/*
The RequestWrapper
Thanks for your reply, Pid!
I'm not sure I understand your explanation.
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 pro
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 st
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 if
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
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 (HttpServletReques
19 matches
Mail list logo
