Pierre -- Pierre Frisch [EMAIL PROTECTED]
On Jan 24, 2008, at 13:41, Zak Burke wrote:
On Jan 24, 2008, at 4:19 PM, Chuck Hill wrote:On Jan 24, 2008, at 1:12 PM, Zak Burke wrote:On Jan 24, 2008, at 3:15 PM, Chuck Hill wrote:On Jan 24, 2008, at 10:40 AM, Zak Burke wrote:I'm going a little bit mad here. I am working on a new app and cannot get session management to work correctly. Requests to the root of the app (.../simple.woa) generate new sessions; requests generated from within the app (submitting a form) reuse existing sessions. I must have some basic setting goofed up, but I cannot figure out what it is.[...]The logs with that shows the sessionID is available in dispatchRequest and that it looks like the new session is being generated by Application._initializeSessionInContext. When I override that as follows:public WOSession _initializeSessionInContext(WOContext context) { WORequest r = context.request();NSLog .out.appendln("_initializeSessionInContext.isSessionIDInRequest: " + r.isSessionIDInRequest()); NSLog.out.appendln("_initializeSessionInContext.sessionID: " + r.sessionID());return super._initializeSessionInContext(context); } I get the following:REQUEST COOKIES: (<com.webobjects.appserver.WOCookie name=woinst value=("-1") path=null domain=null isSecure=false>, <com.webobjects.appserver.WOCookie name=wosid value=("6gIdXD0e75cWKpZWlkCGAM") path=null domain=null isSecure=false>)isSessionIDInRequest: true sessionID: 6gIdXD0e75cWKpZWlkCGAM _initializeSessionInContext.isSessionIDInRequest: true _initializeSessionInContext.sessionID: 6gIdXD0e75cWKpZWlkCGAM Initialized session 2: q1KLEMrOi9scsTfIe6l7f0 java.lang.RuntimeException: Session created here at your.app.Session.<init>(Session.java:23)at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun .reflect .NativeConstructorAccessorImpl .newInstance(NativeConstructorAccessorImpl.java:39) at sun .reflect .DelegatingConstructorAccessorImpl .newInstance(DelegatingConstructorAccessorImpl.java:27)at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303)at com .webobjects .foundation._NSUtilities.instantiateObject(_NSUtilities.java:577) at com .webobjects .appserver .WOApplication.createSessionForRequest(WOApplication.java:1611) at com .webobjects .appserver .WOApplication._initializeSessionInContext(WOApplication.java:1752) at your.app.Application._initializeSessionInContext(Application.java: 64) at com .webobjects .appserver ._private .WOComponentRequestHandler ._dispatchWithPreparedApplication(WOComponentRequestHandler.java: 309) at com .webobjects .appserver ._private .WOComponentRequestHandler ._handleRequest(WOComponentRequestHandler.java:358) at com .webobjects .appserver ._private .WOComponentRequestHandler .handleRequest(WOComponentRequestHandler.java:435) at com .webobjects .appserver.WOApplication.dispatchRequest(WOApplication.java:1306)at your.app.Application.dispatchRequest(Application.java:77)at com .webobjects .appserver._private.WOWorkerThread.runOnce(WOWorkerThread.java:173) at com .webobjects .appserver._private.WOWorkerThread.run(WOWorkerThread.java:254)at java.lang.Thread.run(Thread.java:613)Huh? Both dispatchRequest and _initializeSessionInContext report the same sessionID. If we already have a sessionID, why is _initializeSessionInContext calling createSessionForRequest?I can't help but feel there is some trivial but arcane setting that I have botched, but I can't for the life of me figure out what it might be.I am too lazy to look it up, but I'd guess that the component action request handler creates a new session based on the URL without looking at the cookies. Try adding this to the application constructor:setDefaultRequestHandler (requestHandlerForKey(directActionRequestHandlerKey()));Make sure that DirectAction.java has something like this: public WOActionResults defaultAction() { return pageWithName(Main.class.getName()); }Wow; that worked. How ... strange. You must be right that "the component action request handler creates a new session based on the URL without looking at the cookies." After several years of writing WO applications, I have learned not to question the wisdom of the framework, but I would really love to know the reasoning behind that decision.Thanks as always, zak. _______________________________________________ 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/pierre%40apple.com This email sent to [EMAIL PROTECTED]
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]
