-----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
| 2 options:
| 1) initialize as many of the superclass's fields of the new instance as
| possible using values from the passed-in Request
| 2) wrap the passed-in Request & delegate method calls to it (100+ methods)
#2 is what you want to do. The constructor should look like this:
public Request(Request wrapped)
{
~ this.wrapped = wrapped;
}
That's it. Every other method should look like this:
public whatever doWhatever(args)
{
~ super.doWhatever(args);
}
| #2 is also not a good idea: my new Request subclass is not a true
| wrapper/adapter since I'm overriding one of the methods to get my desired
| behavior (configureSessionCookie). That method is not called directly,
| rather is a protected method called by a public method so I have to
| pick-and-choose which methods get delegated and which don't, which results
| in state split across two Request objects which gets very confusing and is
| also very error-prone.
Just override the protected method. Protected methods were made to be
overridden. You are doing the exact same thing that is encouraged by the
Servlet API itself (see javax.servlet.http.HttpServletRequestWrapper).
| Overall, I'm going to call the Request API unsuitable for extension and in
| particular, I'm going to say overriding configureCookieSession in a
Request
| subclass is not a viable solution to the cross-subdomain session cookie
| problem.
Okay, happy coding.
| To make Request suitable for extension I can see 2 possible solutions:
| 1) Provide a way to specify the fully-qualified name of my Request
subclass
| in server.xml so Tomcat instantiates that instead of
| org.apache.catalina.connector.Request
You won't have to do this if you modify Request.java directly, which is
what you'll have to do in order to...
| 2) Provide a copy constructor in org.apache.catalina.connector.Request
that
| initializes its state based on the state of the passed-in Request
I'd be careful with this. You might not be able to get some of the
internal state this way.
If I were you, I'd start by submitting a bugzilla enhancement and patch
to achieve #1 above (a way to specify the class name for the request
class). Right now, each connector has "new Request()" hard-coded into
its constructor. This won't be an easy task, as you will have to either
modify the arguments to the connector's constructor (yuck), add a static
class field to specify the Request class to use (and break convention
within the Tomcat code), and in either case you'll have to modify every
connector implementation (or, at least the ones you are currently using)
/and/ any code that interacts with the connectors (because of the new
constructor args, new static field, whatever).
Trust me. Use a Valve even if you don't want to use a wrapper as I
suggest. Otherwise, you have to modify Tomcat code for each release,
which is horribly unmaintainable.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgN6rkACgkQ9CaO5/Lv0PCV6wCfV9Yh/wcd9aksuk1KXEUN1G9z
O2AAnj6c8dkK1x/APNSyCrmLYcPoe1Ef
=Px/z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
