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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/rklems%
40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/chill%
40global-village.net
This email sent to [EMAIL PROTECTED]
--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/zdbwo%
40dartmouth.edu
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
