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

From: Merten Schumann <>
Date: Fri, 18 Jun 2004 13:52:02 +0200

Ah, I see, works, thank you, Kathy! :-)


        From: kathy walsh [mailto:Kathleen.Walsh_at_Sun.COM]
        Sent: Thursday, June 17, 2004 4:31 PM
        Subject: Re: JAX-RPC HelloService sample, what scope is it
running in?
        The dynamic proxy client uses the same stub property-
        as it implements the stubIF-
        Merten Schumann wrote:

                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?

                        -----Original Message-----
                        From: Bobby Bissett - Javasoft
                        Sent: Wednesday, June 16, 2004 4:49 PM
                        Subject: Re: JAX-RPC HelloService sample, what
scope is it running in?

                                Do you mean I have to extend HTTPServlet
and implement the



                        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
                        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
javax.xml.rpc.server.ServiceLifecycle you can get the
                        session object yourself and do whatever you'd
                        To unsubscribe, e-mail:
                        For additional commands, e-mail:

                To unsubscribe, e-mail:
                For additional commands, e-mail: