On Oct 22, 2008, at 3:55 PM, Mike Schrag wrote:
I don't think it's the context so much as what is happening in generateResponse _after_ appendToResponse is called though. I say that because I'm obviously using a cloned context, but no new session is created... I just tested it, and my session constructor is only logging one session created from launch to mail sent.... I'm certain the pages are touching the session when generating their content because they are mailed using whatever language is set in the session's current localization. So unless the bug is borking _that_ session, it shouldn't be an issue once patched. I'm curious... did you witness/log a new session being created as the result of the mailings?If you're using a cloned context, it's cloning the session id, which is potentially even worse, because you're going to muck with your session from some other thread (depending on how you're sending out these emails). The correct fix is definitely what Chuck was saying, to change your components in your email to not touch the session. ms
I'm using D2W, so I _have_ to have the session to generate the page content. There's doesn't even appear to be a way to get a page from the D2W factory without a session. So session isn't thread safe? No mail from D2W?
But this is really a crucial question for everyone, because the call to generateResponse that is in ERJavaMail currently is writing to the session's page cache already... so we're still mucking with the session from a separate thread anyway, no?
All I really did to arrive at my patch was step through generateResponse with a debugger, and lop off the unwanted stuff that happens after appendToResponse is called (page caching and cookie setting). If the cloned context is bad.. well the patch method works without the clone, but returning null still gives you the mail page instead of the page you would expect. The only reason I cloned was because of the advice presented here:
http://wiki.objectstyle.org/confluence/display/WO/Project+WONDER-Frameworks-ERJavaMailHow else would we go about returning the proper context in the case of a null return value after generate response does what you see in that method to the context? Perhaps instead of cloning the context, it should store the context._pageElement() value and reset it after append to response is called?
Ramsey
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
