• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: new session on each request
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new session on each request


  • Subject: Re: new session on each request
  • From: Zak Burke <email@hidden>
  • Date: Fri, 25 Jan 2008 12:01:23 -0500

On Jan 24, 2008, at 5:14 PM, Chuck Hill wrote:
That looks more like the problem than a bug in WO. I always / almost always use a DA as the default request handler so I never noticed this problem.

Me too. The actual app I'm working on is DA based, but in my efforts to troubleshoot the problem I simplified and simplified until I had nothing but a barebones application with the default request handler. Happily, setting the DA request handler as the default request handler, as you suggested, solves the problem.


And Klems' tip on how to change the component request handler's default handling works too:

On Jan 24, 2008, at 2:04 PM, Ryan Klems wrote:
You could also try overriding shouldRestoreSessionOnCleanEntry() on your WOApplication class, this controls whether to read the cookie or not when hitting the base URL of the application.

I guess I find it odd that the defaults for session handling would be different between these two request handlers (maybe that still counts as a bug, as Pierre suggested?), but it is documented in the WOApplication API docs so I can't really complain.


zak.





On Jan 24, 2008, at 2:41 PM, 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._dispa tchWithPreparedApplication(WOComponentRequestHandler.java:309)
at com.webobjects.appserver._private.WOComponentRequestHandler._handl eRequest(WOComponentRequestHandler.java:358)
at com.webobjects.appserver._private.WOComponentRequestHandler.handle Request(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@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com


This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net


This email sent to email@hidden


--

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-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40dartmouth.edu


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >new session on each request (From: Zak Burke <email@hidden>)
 >Re: new session on each request (From: Chuck Hill <email@hidden>)
 >Re: new session on each request (From: Zak Burke <email@hidden>)
 >Re: new session on each request (From: Chuck Hill <email@hidden>)
 >Re: new session on each request (From: Zak Burke <email@hidden>)
 >Re: new session on each request (From: Ryan Klems <email@hidden>)
 >Re: new session on each request (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Ajax Modal Container question
  • Next by Date: Re: Enumerating EOs in a new thread
  • Previous by thread: Re: new session on each request
  • Next by thread: Problems with xcodebuild
  • Index(es):
    • Date
    • Thread