Hi everyone, I went another step further in debugging, this time with a little help. We found out that the -f:wsi feature of wscompile isn't that wsi-compliant is it is thought. So we changed a couple of things to the wsdl so we had elements with children, and now we've got a new stacktrace:
org.apache.wsif.WSIFException: exception on AXIS invoke: JAXRPCTIE01:
caught exception while handling request: deserialization error:
unexpected XML reader state. expected: END but found: START:
{http://www.xti.com/}String_1; nested exception is:
JAXRPCTIE01: caught exception while handling request:
deserialization error: unexpected XML reader state. expected: END but
found: START: {http://www.xti.com/}String_1
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.invok
eAXISDocStyle(WSIFOperation_ApacheAxis.java:1721)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.invok
eRequestResponseOperation(WSIFOperation_ApacheAxis.java:1435)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.execu
teRequestResponseOperation(WSIFOperation_ApacheAxis.java:1036)
at AnotherTest.main(AnotherTest.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.intellij.rt.execution.application.AppMain.main(Unknown
Source)
Caused by: JAXRPCTIE01: caught exception while handling request:
deserialization error: unexpected XML reader state. expected: END but
found: START: {http://www.xti.com/}String_1
at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.jav
a:135)
at
org.apache.axis.encoding.DeserializationContextImpl.endElement(Deseriali
zationContextImpl.java:942)
at
org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis
patcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno
wn Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
at
org.apache.axis.encoding.DeserializationContextImpl.parse(Deserializatio
nContextImpl.java:232)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:546)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:377)
at org.apache.axis.client.Call.invokeEngine(Call.java:2132)
at org.apache.axis.client.Call.invoke(Call.java:2102)
at org.apache.axis.client.Call.invoke(Call.java:1851)
at org.apache.axis.client.Call.invoke(Call.java:1777)
at org.apache.axis.client.Call.invoke(Call.java:1315)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.invok
eAXISDocStyle(WSIFOperation_ApacheAxis.java:1717)
... 8 more
Process terminated with exit code 0
This kinda weird:
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.invok
eAXISDocStyle(WSIFOperation_ApacheAxis.java:1721)
I would expect that this would run ApacheAxis.invokeAxisRPCStyle. I
tried that manually, but then I just get an "invocation failed" message.
The Tomcat stacktrace:
unexpected XML reader state. expected: END but found: START:
{http://www.xti.com/}String_1
at
com.sun.xml.rpc.streaming.XMLReaderUtil.verifyReaderState(XMLReaderUtil.
java:51)
at
wstest.WSTestIF_helloTest_RequestStruct__WSIFTest__LiteralSerializer.doD
eserialize(WSTest
IF_helloTest_RequestStruct__WSIFTest__LiteralSerializer.java:56)
at
com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDes
erialize(LiteralO
bjectSerializerBase.java:216)
at
com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize
(LiteralObjectSer
ializerBase.java:124)
at
wstest.WSTestIF_Tie.deserialize_helloTest(WSTestIF_Tie.java:107)
at
wstest.WSTestIF_Tie.readFirstBodyElement(WSTestIF_Tie.java:94)
at
com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:233
)
at
com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDe
legate.java:443)
at
com.sun.xml.rpc.server.http.JAXRPCServlet.doPost(JAXRPCServlet.java:86)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.j
ava:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo
ntext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5
20)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardCon
textValve.java:19
8)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo
ntext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5
20)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo
ntext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:117)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo
ntext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5
20)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo
ntext.java:104)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo
ntext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5
20)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:79
0)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC
onnection(Http11P
rotocol.java:709)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:57
2)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:644)
at java.lang.Thread.run(Thread.java:534)
By the way, Jeff, thanks for your help. I was already running the latest
version of WSIF, but I was using a method with no input parameters. I
didn't see a note anywhere that you need input parameters ... But the
reason of the nullpointerexception was actually the wsdl, generated by
wscompile...
Should anyone be able to help me with this new stacktrace, please reply.
I'll be busy with it all day ;)
Kind Regards,
Dylan Honorez,
[EMAIL PROTECTED]
-----Original Message-----
From: Jeff Greif [mailto:[EMAIL PROTECTED]
Sent: vrijdag 23 juli 2004 18:21
To: [EMAIL PROTECTED]
Subject: Re: SOAP vs AXIS
Both the ApacheAxis and ApacheSOAP providers can support the protocols
referred to in DynamicInvoker as "soap" and "axis". There are two
separate
tokens only to allow a choice to be made. I think the ApacheAxis
provider
is the WSIF default for SOAP over HTTP and is probably more up-to-date.
In
any case, unless you observe a difference in behavior when you switch
(for
instance, if there were a bug in the axis provider not present in the
soap
provider), there's no very good reason not to use the Axis provider.
If you want to try the ApacheSOAP provider, use the "soap" protocol
token on
the command line running DynamicInvoker.
Here are some speculative suggestions about the exception you're seeing:
Support for doc/lit bindings has been improving rapidly in Axis
recently,
which means it was weak before, and probably worse in ApacheSOAP. You
should review the parts of the Axis user guide and WIKI referring to
types
of bindings, and decide whether you intended to use the wrapped variant
of
doc/lit or not, or whether you intended to use doc/lit at all! If you
want
doc/lit but not wrapped, you might have to change some names so the
funky
assumptions that Axis uses to decide whether to unwrap can be violated.
Are
you perhaps invoking an operation whose input message has no parts?
From
your exception trace it looks as though something is expecting to find a
non-empty ArrayList, and fails when that list is empty by referencing
the
non-existent first element.
It's possible that using a later version of WSIF might avoid this
problem.
Jeff
----- Original Message -----
From: "Honorez Dylan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 23, 2004 7:59 AM
Subject: RE: SOAP vs AXIS
Hi,
No it didn't change anything. Apperantly, when the getPort command is
executed, I get a wrong provider assigned dynamically. I am using a
jax-rpc
webservice, but I get an Axis Provider.
Have you got any clue how I fix this?
Kind Regards,
Dylan Honorez,
[EMAIL PROTECTED]
http://www.xt-i.com
________________________________________
From: Raghunath Parthasarathi Krishnaswamy
[mailto:[EMAIL PROTECTED]
Sent: vrijdag 23 juli 2004 10:42
To: [EMAIL PROTECTED]
Subject: Re: SOAP vs AXIS
Hi,
Below log looks like you are using SOAP WS with AXIS WSIF Dynamic
Provider.
Try to comment out the below code in Dynamic Invoker source.
// The default SOAP provider is the Apache SOAP provider. If Axis was
specified
// then change that
if ("axis".equals(protocol)) {
WSIFPluggableProviders.overrideDefaultProvider(
"http://schemas.xmlsoap.org/wsdl/soap/";,
new WSIFDynamicProvider_ApacheAxis());
}
Let me know the result.
regards
raghu
R a g h u n a t h P K
-------------------------------------------------
Technical Lead - Business Integration
IBM Global Services India
Level 2, Prestige Towers,
#99, Residency Road,
Bangalore 5260025, India
"Honorez Dylan" <[EMAIL PROTECTED]>
07/22/2004 06:57 PM
Please respond to
wsif-user
To
<[EMAIL PROTECTED]>
cc
Subject
SOAP vs AXIS
Hi again,
I found something strange in the ouput I get with my tests:
- WSIF0006W: Multiple WSIFProvider found supporting the same namespace
URI 'http://schemas.xmlsoap.org/wsdl/soap/'. Found
('org.apache.wsif.providers.soap.apacheaxis.WSIFDynamicProvider_ApacheAx
is,
org.apache.wsif.providers.soap.apachesoap.WSIFDynamicProvider_ApacheSOAP
')
- WSIF0007I: Using WSIFProvider
'org.apache.wsif.providers.soap.apacheaxis.WSIFDynamicProvider_ApacheAxi
s' for namespaceURI 'http://schemas.xmlsoap.org/wsdl/soap/'
shows up when I execute getPort(). After that I get a stacktrace. Why
does the WSIF framework chooses Axis as provider, when my WSDL is
clearly defined to use with SOAP? Is this normal, or is this what's
causing the stacktrace afterwards?
Stacktrace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.get(ArrayList.java:324)
at org.apache.wsif.util.WSIFUtils.unWrapPart(Unknown Source)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.unwra
pSOAPParts(Unknown Source)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.prepa
re(Unknown Source)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.invok
eRequestResponseOperation(Unknown Source)
at
org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.execu
teRequestResponseOperation(Unknown Source)
at AnotherTest.main(AnotherTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.intellij.rt.execution.application.AppMain.main(Unknown
Source)
Exception in thread "main" Process terminated with exit code 1
Also, I'd like to know if empty input services (with no parameters) are
supported. I also haven't figured out how you get the parts out of the
output message? Is the naming there done by using the WSIF and get the
output parameters from there? I haven't been able to test that because
of the neverending stack trace.
Again, my WSDL is included.
Met vriendelijke groeten,
Dylan Honorez,
[EMAIL PROTECTED]
http://www.xt-i.com
WSIFHello.wsdl
Description: WSIFHello.wsdl
