The example posted by Sam is incorrect because when init(Object) gets called,
the only ServletEndpointContext property that is guaranteed to contain a valid
value is ServletContext. The values of the MessageContext, HttpSession and
UserPrincipal are unspecified at that time.
The idea behind this is that in the init() method you should only look up resources
using the ServletContext object. Typically, you'll also store a reference to the
ServletEndpointContext object in one of your fields. After you're done initializing,
the server will start calling your business methods and in the course of processing
those invocations you can use the other getters on ServletEndpointContext.
Please notice that an implementation is required to return the appropriate
values for all those properties even in the case where several requests are
being served by the *same* endpoint instance in parallel. We expect that
implementations will use thread local variables to make this possible.
Regards,
Roberto
--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.
Sang Shin wrote:
> Sam wrote:
> >
> > Here is a quote from this months Java Live chat.
> >
> > "Roberto Chinnici: In the 0.8 specification an endpoint implementation
> > class is initialized with an object on which it can call back to obtain
> > the SOAPMessageContext for the request, so it could use that to access
> > the attachments. Another strategy would be to use message handlers to
> > deal with attachments and put the data where the endpoint implementation
> > class can find it -- this would work in EA2 too, incidentally. "
> >
> > Well I have a problem with this answer and I have a feeling that
> > this interface might be broken...
>
> Yes, I had a problem with the first part of his answer.
>
> The init(java.lang.Object context) method of the
> ServiceLifeCycle
> interface is meant to pass ServletContext not
> SOAPMessageContext.
> (The SOAPMessageContext gets passed around by SOAP message
> handlers in their init() methods.) So the example code you
> cited
> below should not happen.
>
> -Sang
>
> >
> > Here is an excerpt from the specs :
> >
> > "....After the service endpoint object is instantiated, the JAX-RPC
> > runtime system is required to initialize the endpoint before any
> > requests can be serviced. The JAX-RPC runtime system is required to
> > invoke the ServiceLifecycle.init method ......."
> >
> > "Once a service endpoint has been initialized, the JAX-RPC runtime
> > system may dispatch multiple remote method invocations to the service
> > endpoint object. These method invocations must correspond to the remote
> > methods in the service endpoint interface implemented by the service
> > endpoint class."
> >
> > This leads me to believe that the init() is *not* called for every
> > request
> > but only once, when the class is initialized....much like how servlets
> > are initialized in the servlet specs.
> >
> > Which is fine... But heres where the problem comes in. Consider the
> > following code.
> >
> > public class MyImplementation implements
> > myremoteInterface,ServiceLifecycle {
> >
> > private ServletEndpointContext ctx;
> >
> > public void init(java.lang.Object context){
> > ctx=(ServletEndpointContext)context;
> > SOAPMessageContext msgctx= (SOAPMessageContext)
> > (ctx.getMessageContext());
> > // =====> SOAPMessage message=msgctx.getMessage();
> > }
> > // other code
> > }
> >
> > Well if the actual soap message is retrevied via the context ....how can
> > this work , unless....the init() method is (= MUST be) called for every
> > incoming request that the implementation is servicing....otherwise
> > the class will have access to only one message...the first one . And
> > what happens in the case when the instance is processing multiple
> > requests, from different clients, with different messages,
> > simulatneously (as per the requirements)??
> >
> > And in a related question to the above para, how should developers
> > assume the threading model of these implementations ?? Like RMI ?
> > (where the object could be serviceing multiple requests from different
> > clients simultaenously...and hence isnt thread safe ?)...
> >
> > I.E like RMI no client specific (in the case of JAX-RPC message
> > specific) state
> > should be stored in the instance variables....?? If so then again,
> > the above code will not work...since the only way to access
> > the SOAPMessage object in other methods of this class is to put
> > it in an instance variable.
> >
> > Please clarify and advice.
> >
> > /Sam
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
>
> --
>
> ---------------------------------------------
> Sang Shin sang.shin_at_sun.com
> Strategic Market Development (781) 442-0531(Work)
> Sun Microsystems, Inc. (781) 993-1136(Fax)
>
> http://www.plurb.com/misc/xml/brandeis-xml-2001.html#bio
> http://www.plurb.com/misc/te/SangSchedule.html
> ---------------------------------------------