It seems like a cleaner solution would have been to have the stubs
manage this for you rather than the Sevice object since, as Rick
pointed out, in a multithreaded scenario this could get really
messy.
-Dug


Davanum Srinivas <[EMAIL PROTECTED]> on 03/26/2002 07:50:25 AM

Please respond to [EMAIL PROTECTED]

To:    [EMAIL PROTECTED]
cc:
Subject:    Re: client.Service getCall()



Dug,

I think i mentioned it. I want WSDL2Java to generate code and i want to use
JUST the generated
code!!!

Thanks,
dims

--- Doug Davis <[EMAIL PROTECTED]> wrote:
> I'm confused - if you need access to the response XML, why not just ask
the
> Call object (or its message context) for the response message.  Why does
> the Service object need to be involved at all?
> -Dug
>
> Davanum Srinivas <[EMAIL PROTECTED]> on 03/26/2002 07:36:06 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To:    Rick Rineholt/Raleigh/IBM@IBMUS
> cc:    [EMAIL PROTECTED]
> Subject:    Re: client.Service getCall()
>
>
>
> Rick,
>
> Here's the scenario where i NEED this (See enclosed WSDL and Main.java
for
> running the generated
> stub). The problem is that when AXIS fails to convert the SOAP Response
XML
> into Java objects...I
> need access to the Response XML itself!!!. Right now this is not possible
> any other way. If
> there's a better way to do this, please let me know and we can get rid of
> this UGLY hack.
>
> Thanks,
> dims
>
> --- Rick Rineholt <[EMAIL PROTECTED]> wrote:
> > Davanum,
> > I would like to get your thinking about this method and why the need
for
> > this functionality in the client.Service object.  If presumably the
> caller
> > did the createCall, I would think it would be possible for it to cache
> this
> > call object away and not have the client.Service object do this.  Doing
> > this has a negative consequence if lets say your an axis handler that
> wants
> > make soap calls using this client api.  The Servlet engine  may/will be
> > calling you on many POOLED threads and caching this in the thread
object
> > means that garbage collection will never be called util that thread is
> used
> > by the server again AND it makes another createCall call to replace it.
> > IMO this is a very bad side effect that I don't think is very desirable
> for
> > a functionality that the caller could  presumably do and be cognizant
of
> > its side effects.
> >
> > Rick Rineholt
> > "The truth is out there...  All you need is a better search engine!"
> >
> > [EMAIL PROTECTED]
> >
>
>
> =====
> Davanum Srinivas - http://xml.apache.org/~dims/
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards®
> http://movies.yahoo.com/
>
>


=====
Davanum Srinivas - http://xml.apache.org/~dims/

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/


Reply via email to