org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
John Smith
Any input to resolve the following error is appreciated. Thanks.
I am trying to use a web service that has the following WSDL snippet:
<element name="getServiceIdsResponse">
<complexType>
<sequence>
<element maxOccurs="unbounded" name="getServiceIdsReturn"
type="xsd:long"/>
</sequence>
</complexType>
</element>
The Java code was generated with WSDL2Java. The web service stub
includes:
public interface ServiceAdmin extends java.rmi.Remote {
...
public long[] getServiceIds() throws java.rmi.RemoteException;
...
}
When trying to call this stub method I got:
Exception has occured during health check on grid engines.
Exception: ; nested exception is:
org.xml.sax.SAXParseException: The element type
"getServiceIdsReturn" must be terminated by the matching end-tag "</
getServiceIdsReturn>".
Cause: org.xml.sax.SAXParseException: The element type
"getServiceIdsReturn" must be terminated by the matching end-tag "</
getServiceIdsReturn>".
Stacktrace:
org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:701)
org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
org.apache.axis.transport.http.HTTPSender.readFromSocket
(HTTPSender.java:796)
org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
org.apache.axis.strategies.InvocationStrategy.visit
(InvocationStrategy.java:32)
org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
org.apache.axis.client.Call.invokeEngine(Call.java:2765)
org.apache.axis.client.Call.invoke(Call.java:2748)
org.apache.axis.client.Call.invoke(Call.java:2424)
org.apache.axis.client.Call.invoke(Call.java:2347)
org.apache.axis.client.Call.invoke(Call.java:1804)
org.tds.eqd.gridMonitor.ds.webservices.serviceadmin.ServiceAdminSoapBindingStub.getServiceIds
(Unknown Source)
org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.runHealthCheckOnEachEngine
(Unknown Source)
org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.start
(Unknown Source)
org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.main(Unknown
Source)
AxisFault object:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}
Server.userException
faultSubcode:
faultString: org.xml.sax.SAXParseException: The element type
"getServiceIdsReturn" must be terminated by the matching end-
tag "</getServiceIdsReturn>".
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}
stackTrace:org.xml.sax.SAXParseException: The element type
"getServiceIdsReturn" must be terminated by the matching end-
tag "</getServiceIdsReturn>".
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError
(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
$FragmentContentDispatcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse
(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse
(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:
696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
at org.apache.axis.transport.http.HTTPSender.readFromSocket
(HTTPSender.java:796)
at org.apache.axis.transport.http.HTTPSender.invoke
(HTTPSender.java:144)
at org.apache.axis.strategies.InvocationStrategy.visit
(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:
118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:
165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
at org.apache.axis.client.Call.invoke(Call.java:2748)
at org.apache.axis.client.Call.invoke(Call.java:2424)
at org.apache.axis.client.Call.invoke(Call.java:2347)
at org.apache.axis.client.Call.invoke(Call.java:1804)
at
org.tds.eqd.gridMonitor.ds.webservices.serviceadmin.ServiceAdminSoapBindingStub.getServiceIds
(Unknown Source)
at
org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.runHealthCheckOnEachEngine
(Unknown Source)
at
org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.start
(Unknown Source)
at
org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.main(Unknown
Source)
John Smith
posting guidelines?
> org.tds.eqd.gridMonitor.ds.webservices.serviceadmin.ServiceAdminSoapBindingStub.getServiceIds
> (Unknown Source)
> org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.runHealthCheckOnEachEngine
> org.tds.eqd.gridMonitor.ds.webservices.serviceadmin.ServiceAdminSoapBindingStub.getServiceIds
> (Unknown Source)
> at
> org.tds.eqd.gridMonitor.startup.TDStartGridHealthAnalysis.runHealthCheckOnEachEngine
Mike Schilling
> P.S. i am a newbie on this group. How do I obtain a copy of the
> posting guidelines?
>
> On May 15, 7:02 pm, John Smith <wleu...@gmail.com> wrote:
>> All,
Rule 1: Don't top-post. That is, put your comments *below* what you're
quoting, not above.
Anyway, your problem seems straightforward enough. The service you're
calling sent back some ill-formed XML: Missing the end tag, exactly as
the error message indicates.
John Smith
wrote:
...
> Anyway, your problem seems straightforward enough. The service you're
> calling sent back some ill-formed XML: Missing the end tag, exactly as
> the error message indicates.
what r some common reasons y the service would send back ill-formed
XML?
John
Lew
If u cn rd ths thk a secty.
Perhaps the service is using short tags and your client demands
explicit closing tags.
Avoid leetspeek. It's unprofessional, hard to read, lazy and
unnecessary.
--
Lew
John Smith
> On May 18, 2:35 pm, John Smith <wleu...@gmail.com> wrote:
>
> > On May 17, 1:35 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> > wrote:
> > ...
>
> > > Anyway, your problem seems straightforward enough. The service you're
> > > calling sent back some ill-formed XML: Missing the end tag, exactly as
> > > the error message indicates.
>
> > what r some common reasons y the service would send back ill-formed
> > XML?
>
>
> explicit closing tags.
>
The WSDL has:
<element maxOccurs="unbounded" name="getServiceIdsReturn"
type="xsd:long"/>
I think that's what you meant by short tags.
My client is simply a calling the stub generated using WSDL2Java.
What needs to be done to ensure the client can also use short tags?
Mike Schilling
> On May 18, 2:35 pm, John Smith <wleu...@gmail.com> wrote:
>> On May 17, 1:35 pm, "Mike Schilling" <mscottschill...@hotmail.com>
>> wrote:
>> ...
>>
>>> Anyway, your problem seems straightforward enough. The service
>>> you're calling sent back some ill-formed XML: Missing the end tag,
>>> exactly as the error message indicates.
>>
>> what r some common reasons y the service would send back ill-formed
>> XML?
>
> Perhaps the service is using short tags and your client demands
> explicit closing tags.
What do you mean by short tags?
Mike Schilling
Unfortunately, I have no answer beyond "Because it's badly broken". If you
can trap the actual output (say, using TCPMON), there may be some clues.
John Smith
wrote:
> Lew wrote:
> > On May 18, 2:35 pm, John Smith <wleu...@gmail.com> wrote:
> >> On May 17, 1:35 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> >> wrote:
> >> ...
>
> >>> Anyway, your problem seems straightforward enough. The service
> >>> you're calling sent back some ill-formed XML: Missing the end tag,
> >>> exactly as the error message indicates.
>
> >> what r some common reasons y the service would send back ill-formed
> >> XML?
>
> > Perhaps the service is using short tags and your client demands
> > explicit closing tags.
>
> What do you mean by short tags?
short tag:
<element maxOccurs="unbounded" name="getServiceIdsReturn"
type="xsd:long"/>
explicit closing tag:
<element maxOccurs="unbounded" name="getServiceIdsReturn"
type="xsd:long">
</element>
I am getting
org.xml.sax.SAXParseException: The element type
"getServiceIdsReturn" must be terminated by the matching end-tag "</
getServiceIdsReturn>".
So I need assistance in either:
1) Changing the SOAP response to produce
<getServiceIdsReturn>
</getServiceIdsReturn>
instead of
<getServiceIdsReturn ... />
OR
2) being able to parse <getServiceIdsReturn ... />.
with:
http://java.sun.com/webservices/docs/1.5/api/org/xml/sax/package-summary.html
John Smith
For TCPMON, I can't seem to find documentation on https://tcpmon.dev.java.net/
that specifies how to find out the value of the "Local Port on the
host where tcpmon is running". Any other documentation I can look at?
Mike Schilling
I promise you that that's not your problem. Any current XML parser can
parse "<tag/>".
Mike Schilling
You set the port(s) on which tcpmon will listen using its UI.
Lew
> What do you mean by short tags?
Empty-element tags.
--
Lew
John Smith
wrote:
> John Smith wrote:
> > On May 18, 5:03 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> > wrote:
> >> John Smith wrote:
> >>> On May 17, 1:35 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> >>> wrote:
> >>> ...
>
> >>>> Anyway, your problem seems straightforward enough. The service
> >>>> you're calling sent back some ill-formed XML: Missing the end tag,
> >>>> exactly as the error message indicates.
>
> >>> what r some common reasons y the service would send back ill-formed
> >>> XML?
>
> >> Unfortunately, I have no answer beyond "Because it's badly broken".
> >> If you can trap the actual output (say, using TCPMON), there may be
> >> some clues.
>
> > For TCPMON, I can't seem to find documentation on
> > of the "Local Port on the
> > host where tcpmon is running". Any other documentation I can look at?
>
> You set the port(s) on which tcpmon will listen using its UI.
How do I find out the port# on which tcpmon will listen?
Lew
>>> For TCPMON, I can't seem to find documentation on
>>> https://tcpmon.dev.java.net/that specifies how to find out the value
>>> of the "Local Port on the host where tcpmon is running".
>>> Any other documentation I can look at?
Mike Schilling wrote:
>> You set the port(s) on which tcpmon will listen using its UI.
John Smith wrote:
> How do I find out the port# on which tcpmon will listen?
You set the port(s) on which tcpmon will listen using its UI.
--
Lew
Lew
>>>> For TCPMON, I can't seem to find documentation on
>>>> https://tcpmon.dev.java.net/that specifies how to find out the value
>>>> of the "Local Port on the host where tcpmon is running".
>>>> Any other documentation I can look at?
Mike Schilling wrote:
>>> You set the port(s) on which tcpmon will listen using its UI.
John Smith wrote:
>> How do I find out the port# on which tcpmon will listen?
Lew wrote:
> You set the port(s) on which tcpmon will listen using its UI.
Are you asking how to *decide* the ports on which tcpmon will listen?
That depends on what you want to monitor. For example, if you are running a
web service on http://localhost:8080, and you want to monitor communications
to that port, you would set tcpmon to listen to port 8080.
It's entirely up to you.
--
Lew
Arne Vajhøj
You would set TCPMon to listen to another port than 8080 and set TCPMon
to connect to port 8080.
Arne
Lew
>>> You set the port(s) on which tcpmon will listen using its UI.
>>
>> Are you asking how to *decide* the ports on which tcpmon will listen?
>>
>> That depends on what you want to monitor. For example, if you are
>> running a web service on http://localhost:8080, and you want to
>> monitor communications to that port, you would set tcpmon to listen to
>> port 8080.
Arne Vajhøj wrote:
> You would set TCPMon to listen to another port than 8080 and set TCPMon
> to connect to port 8080.
Absolutely correct. Good catch.
Now that I'm corrected, I'm reminded that the client would therefore have to
connect to the tcpmon port instead of 8080 in order to go through the monitor.
Let's say you set tpcmon to listen to 8070 and relay to 8080. You'd point the
web-service client to port 8070 of the service host to get monitored, and to
8080 to bypass monitoring.
--
Lew
Mike Schilling
Like <tag/>? I don't believe there are any XML parsers currently in use
that don't understand them.
Arne Vajhøj
I would consider it a bug if it did not. That is core XML functionality.
Arne
John Smith
Output of the SOAP message:
HTTPSender : <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelo
pe/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance"><soapenv:Body><getServiceIdsResponse
xmlns="http://a
dmin.gridserver.webservices.datasynapse.com"><getServiceIdsReturn>2368199479101491014</
getServiceIdsReturn>
...
<getServiceIdsReturn>730366849291265490</
getServiceIdsReturn><getServiceIdsReturn>730366847626427013</
getServiceIdsRetu
rn><getServiceIdsReturn>730366850316749035</
getServiceIdsReturn><getServiceIdsReturn>730366849590541473</
getServiceIdsReturn><getServiceIdsReturn>7303668494
55877182</getServiceIdsReturn></getServiceIdsResponse></soapenv:Body></
soapenv:Envelope>
It seems to me like all
<getServiceIdsReturn></getServiceIdsReturn>
tags are closed properly.
I therefore don't understand why the app is giving
org.xml.sax.SAXParseException: The element type
"getServiceIdsReturn" must be terminated by the matching end-tag "</
getServiceIdsReturn>".
What did I miss?
Mike Schilling
I don't see it either. Can you do this? Save the output to a file
(including HTTP headers, if you've got them) and e-mail it to me as an
attachment, so none of the formatting or (possible) special characters are
lost. No guarantees, but something may jump out at me.
John Smith
wrote:
> John Smith wrote:
> > On May 18, 5:03 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> > wrote:
> >> John Smith wrote:
> >>> On May 17, 1:35 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> >>> wrote:
> >>> ...
>
> >>>> Anyway, your problem seems straightforward enough. The service
> >>>> you're calling sent back some ill-formed XML: Missing the end tag,
> >>>> exactly as the error message indicates.
>
> >>> what r some common reasons y the service would send back ill-formed
> >>> XML?
>
> >> Unfortunately, I have no answer beyond "Because it's badly broken".
> >> If you can trap the actual output (say, using TCPMON), there may be
> >> some clues.
>
> > Output of the SOAP message:
> > HTTPSender : <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelo
> > pe/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://
> >www.w3.org/2001/XMLSchema-instance"><soapenv:Body><getServiceIdsResponse
> > xmlns="http://a
> > getServiceIdsReturn>
> > ...
> > <getServiceIdsReturn>730366849291265490</
> > getServiceIdsReturn><getServiceIdsReturn>730366847626427013</
> > getServiceIdsRetu
> > rn><getServiceIdsReturn>730366850316749035</
> > getServiceIdsReturn><getServiceIdsReturn>730366849590541473</
> > getServiceIdsReturn><getServiceIdsReturn>7303668494
> > 55877182</getServiceIdsReturn></getServiceIdsResponse></soapenv:Body></
> > soapenv:Envelope>
>
> > It seems to me like all
> > <getServiceIdsReturn></getServiceIdsReturn>
>
> > tags are closed properly.
>
> > I therefore don't understand why the app is giving
> > org.xml.sax.SAXParseException: The element type
> > "getServiceIdsReturn" must be terminated by the matching end-tag "</
> > getServiceIdsReturn>".
>
> > What did I miss?
>
> I don't see it either. Can you do this? Save the output to a file
> (including HTTP headers, if you've got them) and e-mail it to me as an
> attachment, so none of the formatting or (possible) special characters are
>
> - Show quoted text -
The SOAP output is trapped by running the app that uses the web
service in debug mode which captures SOAP responses as well.
The app runs on solaris server (server 1) while the web service runs
on a grid blade server (server 2). Can I have TCPMON run locally on
my desktop and still monitor the SOAP communication between the
solaris server and the grid server? If so what's my local port?
I have already read:
http://ws.apache.org/axis/java/user-guide.html#AppendixUsingTheAxisTCPMonitorTcpmon
but still confused. Thanks for any clarification that would help me
to pick up the HTTP headers as well.
John B. Matthews
<1d33fb2b-29fb-4e2f...@r3g2000vbp.googlegroups.com>,
John Smith <wle...@gmail.com> wrote:
> On May 19, 1:48 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> wrote:
> > John Smith wrote:
> > > On May 18, 5:03 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> > > wrote:
> > >> John Smith wrote:
> > >>> On May 17, 1:35 pm, "Mike Schilling" <mscottschill...@hotmail.com>
> > >>> wrote:
[...]
> > > org.xml.sax.SAXParseException: The element type
> > > "getServiceIdsReturn" must be terminated by the matching end-tag
> > > "</getServiceIdsReturn>".
> >
> > > What did I miss?
> >
> > I don't see it either. Can you do this? Save the output to a file
> > (including HTTP headers, if you've got them) and e-mail it to me as
> > an attachment, so none of the formatting or (possible) special
> > characters are lost. No guarantees, but something may jump out at
> > me.
>
> The SOAP output is trapped by running the app that uses the web
> service in debug mode which captures SOAP responses as well. The app
> runs on solaris server (server 1) while the web service runs on a
> grid blade server (server 2). Can I have TCPMON run locally on my
> desktop and still monitor the SOAP communication between the solaris
> server and the grid server? If so what's my local port?
>
> I have already read:
> http://ws.apache.org/axis/java/user-guide.html#AppendixUsingTheAxisTCPMonitorTcpmon
> but still confused. Thanks for any clarification that would help me
> to pick up the HTTP headers as well.
The -v option of cURL displays headers; a hex dump might be revealing:
curl -v http://www.example.com | hexdump -C
<http://en.wikipedia.org/wiki/CURL>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Mike Schilling
Pick any unused port, say 9090. Use TCPMON's UI to listen at 9090 and
redirect to the web server's host and port, and change youe client to
send to localhost:9090.
John Smith
>
> - Show quoted text -
TCPMON is running on my desktop but the app is running on the solaris
server (the problem only occurs on the solaris server).
Therefore if I monitor Local Port, then I am just monitoring a local
port on my desktop while the solaris server is trying to connect to
the grid server. Therefore I got no traffic.
Are you saying having the solaris server connect to my desktop? But
how can I make the server find the desktop?
Mike Schilling
Are you saying that the solaris server is the SOAP client? If so,
you'll need to change (or reconfigure) the code running in the server
to point to TCPMON rather than to the grid server.
John Smith
>
> - Show quoted text -
The solaris server is the SOAP client.
However TCPMON is running on my desktop and I don't see how I can make
the solaris server connect to my desktop's TCPMON.
Mike Schilling
The SOAP client was built with some idea of where the SOAP service is.
Change it. If necessary, edit the WSDL it was built against to point
to a different URL, though I suspect all you need to do is edit the
code that creates the stub.