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)
#1 is very error-prone, as many of the set methods in Request do things other than just setting the instance variable to a new value and in a future release when Request inevitably changes it will be broken. #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. 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. 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 2) Provide a copy constructor in org.apache.catalina.connector.Request that initializes its state based on the state of the passed-in Request If I'm missing something, please correct me. Thanks, Zach Christopher Schultz-2 wrote: > > -----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. > > That's why you have to write your own Request class that extends the > existing Request class, includes a constructor that takes the "wrapped" > Request, and delegates nearly all operations to this wrapped object. > > | Is it OK to just create a fresh, new, un-initialized Request object & > | pass it to the next valve in the chain? > > No, you have to do what I have described above. > > - -chris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkgNCmQACgkQ9CaO5/Lv0PARGACgrCxjxUQfVFqxfjilm/wFeQuk > RkIAoJEM7Jp45BpuBTuR1+M/N2x8mHIh > =Dork > -----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] > > > -- View this message in context: http://www.nabble.com/Share-session-cookie-across-subdomains-tp16787390p16823816.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
