Using custom CoyoteResponse(Facade)

[Markus Krogemann <ma...@cologne-systems.de>]

Dear List,

I am having a hard time to figure out how I could fulfill a special 
requirement in a current project.

I could use either tomcat 4.1.x or tomcat 5.0.x for this project, I 
presume it doesn't make much difference in terms of possible solutions.
The project also uses struts (1.2.2) and here is the special 
requirement: Instead of encoding URLs with "our" tomcat's session Id I 
have to use the session Id from another server to encode the URL, since 
all URLs first call that other server which then includes stuff from 
"our" tomcat. Hope that description was clear ...

Anyway, what I would like to do is somehow "smuggle" a response object 
into a request/response pair that could then have it's own encodeURL 
implementation. I don't really want to patch tomcat if possible and I 
also don't want to extend many struts classes which would be another 
solution. Anyone got an idea?

I have tried to use dynamic proxies (creating proxies for 
CoyoteResponseFacade objects) but that didn't appear to work (invoke 
would not get called on the proxies).

I also had a look at the option to wrap my own implementation of 
HttpServletResponse around the CoyoteResponseFacade, but that also 
didn't get me very far. I was hoping that the .setResponse method of 
CoyoteRequest could help, but I cannot get to a CoyoteRequest object, 
only to a CoyoteRequestFacade object. Hm ...

If all else fails, I guess I will have to patch tomcat.

Thanks,
Markus


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: Using custom CoyoteResponse(Facade)

[Tim Funk <fu...@joedog.org>]

I think you might need to use a Valve instead of Http...Wrapper. The 
Http...Wrappers can't dig enough into the correct internals to do your 
session management. But the Valves (probably) can. (Without me thinking about 
the details)

With a valve you should be able to wrap or change the internal tomcat 
implementations. And probably do it in such a way that your webapp might not 
need changed so if this requirement goes away - there is nothing to change in 
your app.

-Tim

Markus Krogemann wrote:

> Dear List,
> 
> I am having a hard time to figure out how I could fulfill a special 
> requirement in a current project.
> 
> I could use either tomcat 4.1.x or tomcat 5.0.x for this project, I 
> presume it doesn't make much difference in terms of possible solutions.
> The project also uses struts (1.2.2) and here is the special 
> requirement: Instead of encoding URLs with "our" tomcat's session Id I 
> have to use the session Id from another server to encode the URL, since 
> all URLs first call that other server which then includes stuff from 
> "our" tomcat. Hope that description was clear ...
> 
> Anyway, what I would like to do is somehow "smuggle" a response object 
> into a request/response pair that could then have it's own encodeURL 
> implementation. I don't really want to patch tomcat if possible and I 
> also don't want to extend many struts classes which would be another 
> solution. Anyone got an idea?
> 
> I have tried to use dynamic proxies (creating proxies for 
> CoyoteResponseFacade objects) but that didn't appear to work (invoke 
> would not get called on the proxies).
> 
> I also had a look at the option to wrap my own implementation of 
> HttpServletResponse around the CoyoteResponseFacade, but that also 
> didn't get me very far. I was hoping that the .setResponse method of 
> CoyoteRequest could help, but I cannot get to a CoyoteRequest object, 
> only to a CoyoteRequestFacade object. Hm ...
> 
> If all else fails, I guess I will have to patch tomcat.
> 
> Thanks,
> Markus
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org