You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by to...@gsk.com on 2004/12/01 09:50:51 UTC
Re: How to get/set cookies from the Axis *client* side?
Well, Axis stores cookies in the message context, so I guess you could
simply put your cookies there and they will be picked up for transmission
to the server. Axis uses two cookies, "Cookie" and "Cookie2". The first
contains the session ID (e.g. "JSESSIONID=206048F23B7AB387C5B2801622EF2C1C
"). I'm not sure what the second is for, but they are both used (if they
exist) if you specify that Axis is to use HTTP sessions. You can store
them in the message context using:
msgContext.setProperty(cookieName, cookie)
However, it's usually pointless setting these on the client side, since
the server has to know which session you're referring to, to be able to
use them. It's the server which sets the cookies on the response and Axis
stores them in the message context, which means that only multiple uses of
the same message context (or Call object) will get to use the same
session. I guess you could use handlers to persist the cookies across
different message contexts.
As for sending other cookies, there doesn't seem to be a way to do that
using the standard HTTP sender, you'd have to write your own, or maybe
subclass the standard one (you'd still have to specify the subclass in the
client config file, though).
I haven't done any of this, so I can't help further, I'm afraid.
Tony
news <ne...@sea.gmane.org> wrote on 30/11/2004 20:21:24:
>
> Is it possible to get and set cookies on the HTTP transport from the
> *client* side of Axis?
>
> If so, how? Are there any examples, please?
>
> Thank you.
>
> Tim
>
>
Re: Changing the endpoint by sending redirects from the server?
Posted by TMG <tm...@nc.rr.com>.
Nige,
UDDIs are there own topic, so I don't want to clutter this list.
To get started, take a look at:
http://www.uddi.org/
http://ws.apache.org/juddi
The Apache jUDDI project has its own mailing list, etc... if you go down
that path.
Tom Gordon
Nige White wrote:
> TMG wrote:
>
>> Nige,
>>
>> As an FYI ...
>>
>> Another way to accomplish dynamic endpoints would be to use a UDDI
>> (e.g. jUDDI), and have the client locate services using a standard
>> interface.
>>
> Woah!! I've just mastered the complexities of a Soap envelope and soap
> encoding serialization/deserialization. I'm just beginning with WSDL,
> and schemas now.
>
> I'm translating the Synergy DBL proprietary interface description into
> WSDL to be able to expose our system as a web service. And I'm wanting
> to write a generator that will generate Synergy DBL client code from
> WSDL so that we can access other web services in Synergy DBL. I've got
> a lot on my plate. UDDI could be the next thing for me... what *is* it?
>
>
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
>
>
>
Re: Changing the endpoint by sending redirects from the server?
Posted by Nige White <ni...@forward-comp.co.uk>.
TMG wrote:
> Nige,
>
> As an FYI ...
>
> Another way to accomplish dynamic endpoints would be to use a UDDI
> (e.g. jUDDI), and have the client locate services using a standard
> interface.
>
Woah!! I've just mastered the complexities of a Soap envelope and soap
encoding serialization/deserialization. I'm just beginning with WSDL,
and schemas now.
I'm translating the Synergy DBL proprietary interface description into
WSDL to be able to expose our system as a web service. And I'm wanting
to write a generator that will generate Synergy DBL client code from
WSDL so that we can access other web services in Synergy DBL. I've got a
lot on my plate. UDDI could be the next thing for me... what *is* it?
_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk
Re: Changing the endpoint by sending redirects from the server?
Posted by TMG <tm...@nc.rr.com>.
Nige,
As an FYI ...
Another way to accomplish dynamic endpoints would be to use a UDDI (e.g.
jUDDI), and have the client locate services using a standard interface.
Tom Gordon
Nige White wrote:
> tony.q.weddle@gsk.com wrote:
>
>>
>> Have you thought about SOAP headers? The first response could include
>> a header giving a new URL for subsequent calls. On the client, a
>> handler could check for the header and, if present, store the value
>> as the endpoint address. You could probably work out how to then
>> modify the Service object or update the URL in the message context
>> for each call. I'm sure there is a way to handle this without
>> modifying the stub or doing any TCP/IP programming.
>>
>>
> So I'd have to write an implementation of some kind of plugable
> interface that Axis offers to change its functionality, and provide
> this along with the WSDL of our service so that the programmers on the
> client side can plug it in?
>
> Any idea what interface would do this? I could just extend the Axis
> default implementation if I knew what it was.
>
> Apache Soap follows the redirect, but it does it for every request
> instead of seeing that 301 means moved *permanently* and changing its
> endpoint accordingly! So it's getting a brand new server for each
> call, which obviously isn't logged in and initialized.
>
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
>
>
Re: Changing the endpoint by sending redirects from the server?
Posted by to...@gsk.com.
Nige,
Axis supports handlers that can get at the SOAP request and response on
the way out and on the way back. It supports this on the client and server
sides. You just have to configure the client and server side WSDD files
and supply classes for the handlers. Axis calls the invoke method of each
handler and passes the message context. Most or all of the information
related to a single request/response is accessible from the message
context. Handlers are often used to add and process SOAP headers, though
they don't have to.
If the first call results in a hand-off of the request, to another URL, a
handler, in the response chain of the server side, can add that URL (it
can be obtained from the HTTP request object, if you don't have it any
other way) in a SOAP header (that you define) to the SOAP response. A
client side handler, in the response chain, can remove the information
from the header and store the information somewhere. If you're using a
single Call object, you may be able to update the endpoint in that object,
in which case all subsequent requests should go to the new endpoint.
Alternatively, I believe that the endpoint is ultimately stored in the
message context and retrieved from there by the HTTP sender, so a request
chain handler could pick up the previously stored endpoint (if there is
one) and update the one stored in the message context.
This is all off the top of my head and I've never tried any of this but it
doesn't seem like too much work and may be optimized if you can determine
whether a call is the first call for a client (to avoid creating and
sending the header with each response). The client handler class could be
combined with the client jar file, along with a client-config.wsdd file.
You might also be able to change the HTTP transport chain, I think, and so
extend the Axis HTTPSender class to perhaps respond to a 301, adding the
new URL to a mapping of logical and actual URLs, using the real URL for
each outward request.
Tony
"Nige White" <ni...@forward-comp.co.uk> wrote on 02/12/2004 15:22:10:
> tony.q.weddle@gsk.com wrote:
>
> Have you thought about SOAP headers? The first response could
> include a header giving a new URL for subsequent calls. On the
> client, a handler could check for the header and, if present, store
> the value as the endpoint address. You could probably work out how
> to then modify the Service object or update the URL in the message
> context for each call. I'm sure there is a way to handle this
> without modifying the stub or doing any TCP/IP programming.
>
> So I'd have to write an implementation of some kind of plugable
> interface that Axis offers to change its functionality, and provide
> this along with the WSDL of our service so that the programmers on
> the client side can plug it in?
>
> Any idea what interface would do this? I could just extend the Axis
> default implementation if I knew what it was.
>
> Apache Soap follows the redirect, but it does it for every request
> instead of seeing that 301 means moved *permanently* and changing
> its endpoint accordingly! So it's getting a brand new server for
> each call, which obviously isn't logged in and initialized.
>
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
>
Re: Changing the endpoint by sending redirects from the server?
Posted by Nige White <ni...@forward-comp.co.uk>.
tony.q.weddle@gsk.com wrote:
>
> Have you thought about SOAP headers? The first response could include
> a header giving a new URL for subsequent calls. On the client, a
> handler could check for the header and, if present, store the value as
> the endpoint address. You could probably work out how to then modify
> the Service object or update the URL in the message context for each
> call. I'm sure there is a way to handle this without modifying the
> stub or doing any TCP/IP programming.
>
>
So I'd have to write an implementation of some kind of plugable
interface that Axis offers to change its functionality, and provide this
along with the WSDL of our service so that the programmers on the client
side can plug it in?
Any idea what interface would do this? I could just extend the Axis
default implementation if I knew what it was.
Apache Soap follows the redirect, but it does it for every request
instead of seeing that 301 means moved *permanently* and changing its
endpoint accordingly! So it's getting a brand new server for each call,
which obviously isn't logged in and initialized.
_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk
Re: Changing the endpoint by sending redirects from the server?
Posted by to...@gsk.com.
Have you thought about SOAP headers? The first response could include a
header giving a new URL for subsequent calls. On the client, a handler
could check for the header and, if present, store the value as the
endpoint address. You could probably work out how to then modify the
Service object or update the URL in the message context for each call. I'm
sure there is a way to handle this without modifying the stub or doing any
TCP/IP programming.
Tony
"Nige White" <ni...@forward-comp.co.uk> wrote on 02/12/2004 14:22:51:
> Nige White wrote:
>
> > Will the Axis HTTP client classes follow redirects?
> >
> No it doesn't! It just throws a "(301)Moved Permanently" error.
>
> This means standard, generated Axis clients won't be able to use our
> Soap server. The programmers of the client will have to modify the
> BindingStub class do the extra step of talking straight TCP/IP on a
> known port to the host to access my manager service which spawns a new
> server process, and sends back the port on which that server is
> listening, and creating the endpoint URL from that. BAH! :-(
>
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
>
>
>
Re: Changing the endpoint by sending redirects from the server?
Posted by Nige White <ni...@forward-comp.co.uk>.
Nige White wrote:
> Will the Axis HTTP client classes follow redirects?
>
No it doesn't! It just throws a "(301)Moved Permanently" error.
This means standard, generated Axis clients won't be able to use our
Soap server. The programmers of the client will have to modify the
BindingStub class do the extra step of talking straight TCP/IP on a
known port to the host to access my manager service which spawns a new
server process, and sends back the port on which that server is
listening, and creating the endpoint URL from that. BAH! :-(
_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk
Changing the endpoint by sending redirects from the server?
Posted by Nige White <ni...@forward-comp.co.uk>.
Will the Axis HTTP client classes follow redirects?
I write my own server (because it has to be in this proprietary language
we use for the business system). Each client needs a new process (They
use loads of global data - it's all hideous!), so I want the first
request from a client to be redirected to a newly spawned server on
another port.
I'm planning to spawn the new server, and send an HTTP 301 response to
point the client at that new server.
Will this work?
_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk
Re: How to get/set cookies from the Axis *client* side?
Posted by to...@gsk.com.
No problem, Tim.
I think I'm going to have to worry about this problem before too long, so
I'd be interested in options. SOAP headers are probably the way to go. If
you implement the cookie functionality in handlers, then it should be
relatively easy to move to another method. I'll probably look at deploying
the Axis provided SimpleSessionHandler, which does maintain sessions
through SOAP headers.
Tony
Tim K. (Gmane) wrote on 01/12/2004 17:06:55:
>
> Thanks Tony for your good replies on this list.
>
> I wonder if my approach is good in general. I suspect there will also be
> non-Axis clients like .NET and maybe other frameworks on the client side
> that will need to do the same.
>
> Does anyone have a different idea to achieve the same behavior? I think
> SOAP headers for session tracking should work and I suppose it is more
> portable, right? If I could get rid of the requirement to use cookie
> based tracking ...
>
> I am open to other suggestions :)
>
> Tim
>
>
> tony.q.weddle@gsk.com wrote:
> >
> > In that case, as I mentioned in my first reply, extract the cookies
from
> > the message context, in the first reply and store them somewhere (for
> > example, in a static variable or in system properties) that will be
> > available in the next call. In that next call, add the cookies to the
> > message context and they should get picked up by the Axis HTTPSender,
if
> > maintainSession is set to true. Provided the same host is called each
> > time, this should work. Simple Axis handlers can be written to do
this.
> >
> > Tony
> >
> > *Tim K. (Gmane)* wrote on 01/12/2004 16:45:06:
> >
> > > John Walker wrote:
> > > >>Is it possible to get and set cookies on the HTTP transport from
the
> > > >>*client* side of Axis?
> > > >
> > > >
> > > > I tried using the MessageContext to get the HttpRequest object,
and
> > > > then set cookies there, but it seemed that when doing this from
the
> > > > AXIS client side, when the HTTP message got to the receiver, my
> > > > cookies had been clobbered.
> > > >
> > > > I know this isnt an affirmation, but a warning about cookies and
> > > > inconsistency. I think it may be an easier thing to utilize the
> > > > standard AXIS APIs to transfer data about the client to the
server.
> > > > For example, there is a way to set the username and password for
> > > > authentication.
> > > >
> > > > What data are you trying to hold onto that SOAP/AXIS doesnt
> > handlenatively?
> > > >
> > >
> > > I have multiple module that I am thinking of deploying as
individual web
> > > services running in the same web app rather than create a big
interface
> > > and have one big monolithic service with 200+ methods in it. One of
the
> > > modules is a SessionModule that the client needs to call to
authenticate
> > > before using the other modules, so I need some sort of session
tracking
> > > across the modules.
> > >
> > > I know I could use SOAP headers which would probably work OK across
the
> > > modules, but I need to do the session tracking via cookies because
> > > there's another servlet in the same web app that needs to use the
same
> > > session (complicated, I know).
> > >
> > > So I was thinking if it's possible to do something like this:
> > >
> > > 1. From the client call the SessionModule with the MAINTAIN_SESSION
> > > property or whatever it is which will establish a session
(HttpSession)
> > > on the server and send a cookie back to the client which Axis will
store.
> > >
> > > 2. From the client before calling another module, set the session
cookie
> > > from #1 before making the call so that the same HttpSession as in
#1 is
> > > recovered and used on the server side (this other module requires
that
> > > the user is authenticated).
> > >
> > > 3. Continue doing #2 for all modules when they are needed.
> > >
> > > Maybe I'm complicating my life, is there an easier way to achieve
this?
> > > Basically session tracking across a set of web services deployed in
the
> > > same web app.
> > >
> > > Thanks for your help.
> > >
> > > Tim
> > >
> > >
>
>
Re: How to get/set cookies from the Axis *client* side?
Posted by "Tim K. (Gmane)" <tk...@ugcs.net>.
Thanks Tony for your good replies on this list.
I wonder if my approach is good in general. I suspect there will also be
non-Axis clients like .NET and maybe other frameworks on the client side
that will need to do the same.
Does anyone have a different idea to achieve the same behavior? I think
SOAP headers for session tracking should work and I suppose it is more
portable, right? If I could get rid of the requirement to use cookie
based tracking ...
I am open to other suggestions :)
Tim
tony.q.weddle@gsk.com wrote:
>
> In that case, as I mentioned in my first reply, extract the cookies from
> the message context, in the first reply and store them somewhere (for
> example, in a static variable or in system properties) that will be
> available in the next call. In that next call, add the cookies to the
> message context and they should get picked up by the Axis HTTPSender, if
> maintainSession is set to true. Provided the same host is called each
> time, this should work. Simple Axis handlers can be written to do this.
>
> Tony
>
> *Tim K. (Gmane)* wrote on 01/12/2004 16:45:06:
>
> > John Walker wrote:
> > >>Is it possible to get and set cookies on the HTTP transport from the
> > >>*client* side of Axis?
> > >
> > >
> > > I tried using the MessageContext to get the HttpRequest object, and
> > > then set cookies there, but it seemed that when doing this from the
> > > AXIS client side, when the HTTP message got to the receiver, my
> > > cookies had been clobbered.
> > >
> > > I know this isnt an affirmation, but a warning about cookies and
> > > inconsistency. I think it may be an easier thing to utilize the
> > > standard AXIS APIs to transfer data about the client to the server.
> > > For example, there is a way to set the username and password for
> > > authentication.
> > >
> > > What data are you trying to hold onto that SOAP/AXIS doesnt
> handlenatively?
> > >
> >
> > I have multiple module that I am thinking of deploying as individual web
> > services running in the same web app rather than create a big interface
> > and have one big monolithic service with 200+ methods in it. One of the
> > modules is a SessionModule that the client needs to call to authenticate
> > before using the other modules, so I need some sort of session tracking
> > across the modules.
> >
> > I know I could use SOAP headers which would probably work OK across the
> > modules, but I need to do the session tracking via cookies because
> > there's another servlet in the same web app that needs to use the same
> > session (complicated, I know).
> >
> > So I was thinking if it's possible to do something like this:
> >
> > 1. From the client call the SessionModule with the MAINTAIN_SESSION
> > property or whatever it is which will establish a session (HttpSession)
> > on the server and send a cookie back to the client which Axis will store.
> >
> > 2. From the client before calling another module, set the session cookie
> > from #1 before making the call so that the same HttpSession as in #1 is
> > recovered and used on the server side (this other module requires that
> > the user is authenticated).
> >
> > 3. Continue doing #2 for all modules when they are needed.
> >
> > Maybe I'm complicating my life, is there an easier way to achieve this?
> > Basically session tracking across a set of web services deployed in the
> > same web app.
> >
> > Thanks for your help.
> >
> > Tim
> >
> >
Re: How to get/set cookies from the Axis *client* side?
Posted by to...@gsk.com.
In that case, as I mentioned in my first reply, extract the cookies from
the message context, in the first reply and store them somewhere (for
example, in a static variable or in system properties) that will be
available in the next call. In that next call, add the cookies to the
message context and they should get picked up by the Axis HTTPSender, if
maintainSession is set to true. Provided the same host is called each
time, this should work. Simple Axis handlers can be written to do this.
Tony
Tim K. (Gmane) wrote on 01/12/2004 16:45:06:
> John Walker wrote:
> >>Is it possible to get and set cookies on the HTTP transport from the
> >>*client* side of Axis?
> >
> >
> > I tried using the MessageContext to get the HttpRequest object, and
> > then set cookies there, but it seemed that when doing this from the
> > AXIS client side, when the HTTP message got to the receiver, my
> > cookies had been clobbered.
> >
> > I know this isnt an affirmation, but a warning about cookies and
> > inconsistency. I think it may be an easier thing to utilize the
> > standard AXIS APIs to transfer data about the client to the server.
> > For example, there is a way to set the username and password for
> > authentication.
> >
> > What data are you trying to hold onto that SOAP/AXIS doesnt
handlenatively?
> >
>
> I have multiple module that I am thinking of deploying as individual web
> services running in the same web app rather than create a big interface
> and have one big monolithic service with 200+ methods in it. One of the
> modules is a SessionModule that the client needs to call to authenticate
> before using the other modules, so I need some sort of session tracking
> across the modules.
>
> I know I could use SOAP headers which would probably work OK across the
> modules, but I need to do the session tracking via cookies because
> there's another servlet in the same web app that needs to use the same
> session (complicated, I know).
>
> So I was thinking if it's possible to do something like this:
>
> 1. From the client call the SessionModule with the MAINTAIN_SESSION
> property or whatever it is which will establish a session (HttpSession)
> on the server and send a cookie back to the client which Axis will
store.
>
> 2. From the client before calling another module, set the session cookie
> from #1 before making the call so that the same HttpSession as in #1 is
> recovered and used on the server side (this other module requires that
> the user is authenticated).
>
> 3. Continue doing #2 for all modules when they are needed.
>
> Maybe I'm complicating my life, is there an easier way to achieve this?
> Basically session tracking across a set of web services deployed in the
> same web app.
>
> Thanks for your help.
>
> Tim
>
>
Re: How to get/set cookies from the Axis *client* side?
Posted by "Tim K. (Gmane)" <tk...@ugcs.net>.
John Walker wrote:
>>Is it possible to get and set cookies on the HTTP transport from the
>>*client* side of Axis?
>
>
> I tried using the MessageContext to get the HttpRequest object, and
> then set cookies there, but it seemed that when doing this from the
> AXIS client side, when the HTTP message got to the receiver, my
> cookies had been clobbered.
>
> I know this isnt an affirmation, but a warning about cookies and
> inconsistency. I think it may be an easier thing to utilize the
> standard AXIS APIs to transfer data about the client to the server.
> For example, there is a way to set the username and password for
> authentication.
>
> What data are you trying to hold onto that SOAP/AXIS doesnt handle natively?
>
I have multiple module that I am thinking of deploying as individual web
services running in the same web app rather than create a big interface
and have one big monolithic service with 200+ methods in it. One of the
modules is a SessionModule that the client needs to call to authenticate
before using the other modules, so I need some sort of session tracking
across the modules.
I know I could use SOAP headers which would probably work OK across the
modules, but I need to do the session tracking via cookies because
there's another servlet in the same web app that needs to use the same
session (complicated, I know).
So I was thinking if it's possible to do something like this:
1. From the client call the SessionModule with the MAINTAIN_SESSION
property or whatever it is which will establish a session (HttpSession)
on the server and send a cookie back to the client which Axis will store.
2. From the client before calling another module, set the session cookie
from #1 before making the call so that the same HttpSession as in #1 is
recovered and used on the server side (this other module requires that
the user is authenticated).
3. Continue doing #2 for all modules when they are needed.
Maybe I'm complicating my life, is there an easier way to achieve this?
Basically session tracking across a set of web services deployed in the
same web app.
Thanks for your help.
Tim
Re: How to get/set cookies from the Axis *client* side?
Posted by to...@gsk.com.
John,
I'm not sure what you were getting back from the MessageContext but there
is no HttpRequest available from the Axis client. HttpRequests only exist
on the server. Of course, your client may be embedded in a server side
object but the HttpRequest for that would not be the one associated with
the web service request.
Tony
"John Walker" <jo...@gmail.com> wrote on 01/12/2004 15:26:51:
> > Is it possible to get and set cookies on the HTTP transport from the
> > *client* side of Axis?
>
> I tried using the MessageContext to get the HttpRequest object, and
> then set cookies there, but it seemed that when doing this from the
> AXIS client side, when the HTTP message got to the receiver, my
> cookies had been clobbered.
>
> I know this isnt an affirmation, but a warning about cookies and
> inconsistency. I think it may be an easier thing to utilize the
> standard AXIS APIs to transfer data about the client to the server.
> For example, there is a way to set the username and password for
> authentication.
>
> What data are you trying to hold onto that SOAP/AXIS doesnt handle
natively?
>
> > >
> > > If so, how? Are there any examples, please?
> > >
> > > Thank you.
> > >
> > > Tim
> > >
> > >
> >
>
Re: How to get/set cookies from the Axis *client* side?
Posted by John Walker <jo...@gmail.com>.
> Is it possible to get and set cookies on the HTTP transport from the
> *client* side of Axis?
I tried using the MessageContext to get the HttpRequest object, and
then set cookies there, but it seemed that when doing this from the
AXIS client side, when the HTTP message got to the receiver, my
cookies had been clobbered.
I know this isnt an affirmation, but a warning about cookies and
inconsistency. I think it may be an easier thing to utilize the
standard AXIS APIs to transfer data about the client to the server.
For example, there is a way to set the username and password for
authentication.
What data are you trying to hold onto that SOAP/AXIS doesnt handle natively?
> >
> > If so, how? Are there any examples, please?
> >
> > Thank you.
> >
> > Tim
> >
> >
>
Axis SimpleDeserializer error...help
Posted by "Kibaya E." <ek...@yahoo.com>.
Hi,I have deployed a webservice but when running the
client i get the following error....can anybody
familair with this help me out..
AxisFault
faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXException:
SimpleDeserializer encountered a child element, which
is NOT expected, in something it was trying to
deserialize.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace: AxisFault
faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXException:
SimpleDeserializer encountered a child element, which
is NOT expected, in something it was trying to
deserialize.
faultActor:
faultNode:
faultDetail:
org.xml.sax.SAXException: SimpleDeserializer
encountered a child element, which is NOT expected, in
something it was trying to deserialize.
at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:260)
at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:169)
at
org.apache.axis.encoding.DeserializationContextImpl.endElement(DeserializationContextImpl.java:1015)
at
org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1456)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1260)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at
org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at
org.apache.axis.encoding.DeserializationContextImpl.parse(DeserializationContextImpl.java:242)
at
org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:538)
at
org.apache.axis.Message.getSOAPEnvelope(Message.java:376)
at
org.apache.axis.client.Call.invokeEngine(Call.java:2583)
at org.apache.axis.client.Call.invoke(Call.java:2553)
at org.apache.axis.client.Call.invoke(Call.java:1753)
at
SecurityTokenServiceClient.main(SecurityTokenServiceClient.java:92)
org.xml.sax.SAXException: SimpleDeserializer
encountered a child element, which is NOT expected, in
something it was trying to deserialize.
at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:260)
at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:169)
at
org.apache.axis.encoding.DeserializationContextImpl.endElement(DeserializationContextImpl.java:1015)
at
org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1456)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1260)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at
org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at
org.apache.axis.encoding.DeserializationContextImpl.parse(DeserializationContextImpl.java:242)
at
org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:538)
at
org.apache.axis.Message.getSOAPEnvelope(Message.java:376)
at
org.apache.axis.client.Call.invokeEngine(Call.java:2583)
at org.apache.axis.client.Call.invoke(Call.java:2553)
at org.apache.axis.client.Call.invoke(Call.java:1753)
at
SecurityTokenServiceClient.main(SecurityTokenServiceClient.java:92)
Exception in thread "main"
The line code from which it throws the error, is
supposed to be invoking the service its here below:
....
SOAPEnvelope response = call.invoke(env);
System.out.println("\n============= Response
from Kibs TrustManager==============");
XMLUtils.PrettyElementToStream(response.getAsDOM(),
System.out);
// Find the <RequestSecurityTokenResponse>
element the SOAP body should contain
SOAPBodyElement responseBody =
response.getBodyByName(TrustConstants.WST_NS,
TrustConstants.RESPONSE_TAG);
// Construct a Java object from the XML
RequestSecurityTokenResponse tokenResponse =
new
RequestSecurityTokenResponse(responseBody.getAsDOM());
System.out.println("\n-------
RequestSecurityTokenResponse object from Kibs
TrustManager ------------- \n" + tokenResponse);
}
}
Thanks
Kibaya
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail