users@jax-rpc.java.net

RE: Re: JAX-RPC HelloService sample, what scope is it running in?

From: Merten Schumann <Merten.Schumann_at_asg.com>
Date: Thu, 17 Jun 2004 08:46:26 +0200

Hi Bobby,

thank you very much for the helpful response!

I gave it a try and found a new HTTPSession for each run of my static
stub client. That's fine! :-)

I think this session stuff as you explained it should make it's way to
the great J2EE tutorial. In the servlet section, session stuff and all
is mentioned. But not in the JAX-RPC section ...

With my counter stuff and all: I thought to get a fresh instance of my
JAX-RPC endpoint implementation, when there comes a new client (sending
no cookie with the first call). That was a big fault of mine, sorry. I
think I thought too much in JSP or so. :-)

Now, there's another question: is there a standard way for the Dynamic
Proxy Client to hold the session alive?

cu
   Merten

> -----Original Message-----
> From: Bobby Bissett - Javasoft [mailto:Robert.Bissett_at_Sun.COM]
> Sent: Wednesday, June 16, 2004 4:49 PM
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: JAX-RPC HelloService sample, what scope is it running in?
>
> >
> > Do you mean I have to extend HTTPServlet and implement the
> doGet/doPost
> > methods?
>
> Hi Merten,
>
> You don't have to quite that much work. What you want is
> something like
> this, right? Client makes a call to the service, and the
> server responds
> and sets a cookie on the connection. From then on, the client
> sends back
> that same cookie with each call and the server can check it.
>
> A jaxrpc stub, normally, ignores the cookie that comes back. When you
> set the SESSION_MAINTAIN_PROPERTY, then it will send back whatever
> cookie the server set on it. So the client side is pretty simple.
>
> On the server side, you need to do a little more work, but
> basically you
> add one field to your class and a method that sets it. Have your
> endpoint implement javax.xml.rpc.server.ServiceLifecycle. You
> will need
> to add two methods, destroy() (which can be empty if you'd like) and
> init(Object context).
>
> Add a ServletEndpointContext object to your endpoint; I'll call it
> myServletEndpointContext. In the init(Object context) method
> you can set
> it: myServletEndpointContext = (ServletEndpointContext) context;
>
> From then on, in your business methods you can get access to the
> HttpSession with myServletEndpointContext.getHttpSession(). Note that
> the first call to getHttpSession creates the session if one
> doesn't exist.
>
> So in any method the client now calls, you can get the session, set
> attributes on it, get information from it, or whatever, and
> from then on
> the client will send back the same cookie information. See
> http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpS
> ession.html
> for information on the HttpSession object.
>
> To answer your question about whether or not the session code is
> generated for you behind the scenes, much of it is, but
> there's no way
> to know what you want to do with the session information, so by
> implementing javax.xml.rpc.server.ServiceLifecycle you can get the
> session object yourself and do whatever you'd like.
>
> Cheers,
> Bobby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net