Thanks for your reply Chuck, definitely not. No instance number and no cookie.
What I’ve found so far: If the app is refusing new sessions, the handleRequest(WORequest) implementation of WOActionRequestHandler returns a response that does not call _finalizeInContext(WOContext) on the response (in contrast to WOComponentRequestHandler). _finalizeInContext will add a "x-webobjects-refusenewsessions" HTTP-header which is evaluated by the WOAdaptor. If I override generateRequestRefusal(WORequest) in WODirectActionRequestHandler calling _finalizeInContext(WOContext) it seems to work as I would expect it to be: The WOAdapter immediately registers the instance as refusing. Any comments on this? Did I miss something? Peer Am 06.07.2010 um 18:17 schrieb Chuck Hill: > I think is there is a woinst cookie or the instance number in the URL, it > will override the refusing. You can remove this cookie or URL part and > redirect if the app is refusing. > > > Chuck > > > On Jul 6, 2010, at 2:10 AM, Peer Sandtner wrote: > >> Hi all, >> >> it seems that in my setup (centos, apache2, mod_WebObjects.so) direct >> actions received by a refusing instance do not trigger a "refusing timeout" >> for this instance in WOAdaptor. Only component actions do this. >> >> Is this by design? Any insight appreciated. >> >> Peer > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/products/practical_webobjects > > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-deploy mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com This email sent to [email protected]
