-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| Hi Matthias - Unfortunately I think the Response class is just as
ill-suited
| for wrapping/extending as the Request class is.
Okay, I finally looked at this class, again. static final is just fine:
it doesn't mess with the s
Again, I'll point out that Tomcat's Request class is not designed properly
for extension and offer these two proposed solutions, both of which would
need to be implemented in core Tomcat source code by Tomcat developers:
1) Let users specify the fully-qualified name of a Request subclass in
serve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| Hi Matthias - Unfortunately I think the Response class is just as
ill-suited
| for wrapping/extending as the Request class is. Which boggles my mind -
| isn't wrapping the Request and/or Response one of the primary intended
|
.
>
> -- Matthias
>
> -Original Message-
> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 23, 2008 9:51 PM
> To: Tomcat Users List
> Subject: Re: Share session cookie across subdomains
>
> -BEGIN PGP SIGNED MESSAGE-
> Ha
ponse
must also be modified.
-- Matthias
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 9:51 PM
To: Tomcat Users List
Subject: Re: Share session cookie across subdomains
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| Hi Chris - I'm not sure what this will accomplish:
|
| public Request(Request wrapped)
| {
| ~this.wrapped = wrapped;
| }
|
| public whatever doWhatever(args)
| {
| ~super.doWhatever(args);
| }
|
| 1) this.wrapped is n
Hi Chris - I'm not sure what this will accomplish:
public Request(Request wrapped)
{
~this.wrapped = wrapped;
}
public whatever doWhatever(args)
{
~super.doWhatever(args);
}
1) this.wrapped is never used so what's the point of saving it?
2) why override all of the methods just to call t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| That's what I was afraid of - that Request class is huge (2600+ lines) and
| has lots of fields (50+) some of which are private. So if I create a
| Request subclass that accepts another Request in the constructor,
there are
|
That's what I was afraid of - that Request class is huge (2600+ lines) and
has lots of fields (50+) some of which are private. So if I create a
Request subclass that accepts another Request in the constructor, there are
2 options:
1) initialize as many of the superclass's fields of the new instan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| Hi Chris - I thought about doing that, but that existing Request
| object could have state that my newly created Request will not have -
| Request does not have a copy constructor and does not wrap another
| Request object.
T
Hi Chris - I thought about doing that, but that existing Request object could
have state that my newly created Request will not have - Request does not
have a copy constructor and does not wrap another Request object. Is it OK
to just create a fresh, new, un-initialized Request object & pass it t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| Note that this entire issue would be made much more simple if there was an
| easy way to override the
| org.apache.catalina.connector.Request.configureSessionCookie method.
I have
| not found an easy way to do that.
Have your
That's a good point Matthias - in my case sessions are always created so it's
acceptable. Can you think of a good way to only replace the session cookie
when it would be naturally created by the app for those cases where always
creating it is not acceptable?
Note that this entire issue would be
With your implementation, the valve will have the effect that a session
is created upon first access to a server,
not only when required by the application.
(see also discussion on
http://www.nabble.com/Cookie-less-session-tracking---whats-are-the-downs
ides-tp16738472p16738472.html )
Thus, the v
That's a really good idea and could definitely be done by modifying the
getCookieDomain method. I whipped that method up pretty quickly for my own
purposes - and you're correct, this currently won't work with two-part TLDs
like .co.uk. If I get some spare time (already used 2 days of this projec
how about adding either, a property that allows you to specify the
number of domain parts (accounting for domain.co.uk for example), or the
actual domain?
p
Zach Cox wrote:
I'm working on a site that has a single web app in Tomcat that handles
lots of subdomains via wildcard DNS:
- site
16 matches
Mail list logo
