Hi Andrew!
When you set "scope=session" on a service, the JavaProvider will actually use the Session object that is associated with the MessageContext to store the service object (under the service's name - so you should actually be careful not to overwrite it if you use the Session in your own code!) and get it back on each subsequent request. Note that Session is an interface, and there are currently two implementations - the SimpleSession, and the AxisHttpSession, which wraps a servlet HttpSession. The AxisServlet plunks an AxisHttpSession into the MessageContext if appropriate, and the SimpleSessionHandler plunks in a SimpleSession. The idea there is that the Handlers/Providers shouldn't care HOW you implement sessions, just that they're there. So you may either use cookies OR the SOAP-based session handlers, and in either case you end up with a Session object in your MessageContext. If your service is session scoped, you will also ensure that you get the same service object for every request associated with a given session. Hence you can certainly use state in your service object, but the explicit usage of the Session object is also useful, especially in Handlers which do want to maintain state themselves, but don't want to be tied to a particular service object class. --Glen > -----Original Message----- > From: Andrew Vardeman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 09, 2002 11:15 AM > To: [EMAIL PROTECTED] > Subject: RE: stateful service example (no cookies) > > > hehe--nope, didn't know that :) Guess it pays to read one's > Javadocs, but > then I get lost fast in Javadocs. At least I know I was on > the right track > since I was about to implement everything that's already there-- > > So I get that this handler reads the session ID and places > the appropriate > SimpleSession object in the MessageContext. It makes sense > that I can > store session info in the SimpleSession and it'll be there on > the next > request. Something from Stan's cookie-based Stateful Service > example is > confusing me: he doesn't bother with SimpleSession at all; he > saves a value > in a member field of his service class, and it's there on the next > request. I understand that this is because the service has > session scope, > but what is really going on? There is an instance of the > service for each > distinct session, right? At what point in processing the > incoming request > does Axis determine which instance of the service to hook the > request up > with? In the transport chain? It seems like selecting the > right instance > of the service is a job for something outside of any one > handler's control... > > I guess what I'm wondering is whether the parameter "scope" > is applicable > to a service using SimpleSessionHandler. If I say <parameter name = > "scope" value = "session" />, does that imply cookie-based session > maintenance? What scope should I set for a service that uses > SimpleSessionHandler? If session scope, do I get the same > benefit as in > Stan's example, where member fields of my service class stick > around? If > so, why the SimpleSession object? > > Thanks, > > Andrew > > At 11:18 PM 5/8/2002 -0400, you wrote: > > >Hi Andrew! > > > >Just an FYI - you do realize that we already have SOAP header-based > >sessions built in to Axis, right? I haven't looked at your > code, so I'm > >not sure if the functionality we provide is what you're > looking for, but > >it's there. Essentially, if you drop a Handler > (SimpleSessionHandler) > >into your request & response flows, we will automatically > handle session > >management and timeout issues for you, allowing you to use > exactly the > >same mechanism to store + retrieve session data as you would for > >cookie-based sessions. > > > >--Glen > > >
