Ah, I see, works, thank you, Kathy! :-)
Merten
________________________________
From: kathy walsh [mailto:Kathleen.Walsh_at_Sun.COM]
Sent: Thursday, June 17, 2004 4:31 PM
To: users_at_jax-rpc.dev.java.net
Subject: Re: JAX-RPC HelloService sample, what scope is it
running in?
Merten-
The dynamic proxy client uses the same stub property-
as it implements the stubIF-
Kathy
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?
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