You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by fahman_dude <fa...@hotmail.com> on 2010/03/24 15:43:46 UTC
Unmarshalling error when using fastinfoset
Hi,
I have a webservice operation that returns primitive "string". I call this
very same operation in three different ways: 1. without any sort of
compression; 2. with mtom compression 3. with fastinfoset compression.
The no compression call and mtom compression call works but fastinfoset call
fails with this exception:
15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain (240) -
Invoking handleMessage on interceptor
org.apache.cxf.interceptor.DocLiteralInInterceptor@1bb3e9a
15:24:49,343 WARN [main] apache.cxf.phase.PhaseInterceptorChain (365) -
Interceptor for
{http://blahblah/email/service}EmailUS#{http://blahblah/email/service}sendEmail
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Unmarshalling Error: null
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:780)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:624)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:106)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:672)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2254)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2134)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1988)
at
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:484)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:310)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:262)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy67.sendEmail(Unknown Source)
at
blahblah.email.service.EmailUSWSImplTest.prepareAndCallSendEmailWebService(EmailUSWSImplTest.java:332)
at
blahblah.email.service.EmailUSWSImplTest.testSendEmailWithFastinfosetCompression(EmailUSWSImplTest.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.lang.AssertionError
at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
at com.sun.xml.bind.v2.util.QNameMap.get(QNameMap.java:158)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:241)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:478)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)
at
com.sun.xml.bind.v2.runtime.unmarshaller.FastInfosetConnector.handleStartElement(FastInfosetConnector.java:162)
at
com.sun.xml.bind.v2.runtime.unmarshaller.FastInfosetConnector.bridge(FastInfosetConnector.java:105)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:755)
... 48 more
If I change return type of the operation to one way (remove output message
from the porttype def) the call to fastinfoset works just fine!!! But as
soon as I make the operation two way, it brings this error.
I tried:
- changing return type to int;
- enabling FI declaratively by adding <fastinfoset/> to bus definition in
cxf.xml
- enabling FI programaticaly by adding FIStaxXXInterceptor to endpoints
- adding fresh new operation to the webservice with the return value and
testing if it works
none of this worked for me.
thank you and kind regards
reinis
--
View this message in context: http://old.nabble.com/Unmarshalling-error-when-using-fastinfoset-tp28015923p28015923.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Unmarshalling error when using fastinfoset
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 31 March 2010 11:27:08 am fahman_dude wrote:
> I confirm herewith that my real project works with the cxf 2.3-snapshot as
> expected (there are some other non-critical issues with the current trunk
> of 2.3 e.g. BeanCreationException during initialization. Will post
> separate jira ticket).
Cool. I managed to back port the rest of the FI stuff to 2.2.x yesterday.
Thus, the snapshots for 2.2.8 tomorrow (maybe even today's) should also work.
Any chance you could give those a try to make sure everything got back ported
OK?
Dan
>
> Question to community, is there atleast some sort of rumor when will 2.3 be
> released?
>
> fahman_dude wrote:
> > Workaround works for the test project but not for my real project. I will
> > attempt to test the real project with the cxf 2.3-snapshot and will
> > report results in here. Dan, do you have a jira ticket on this? If not,
> > dont reply I'll just post new one.
> >
> > dkulp wrote:
> >> On Monday 29 March 2010 9:25:34 am fahman_dude wrote:
> >>> Hello,
> >>>
> >>> please find attached eclipse test project. Its got maven config so,
> >>> normally, running "mvn install" should be sufficient to generate,
> >>> compile
> >>> and run unittest.
> >>>
> >>> I have stripped and simplified a lot of things from my real use case,
> >>> but I
> >>> still get the same exception I reported even with this simplified
> >>> example.
> >>>
> >>> http://old.nabble.com/file/p28069257/cxf.jaxws.infoset.twoway.mep.test.
> >>> zip cxf.jaxws.infoset.twoway.mep.test.zip
> >>
> >> The good news is this doesn't fail on trunk/2.3. I CAN reproduce the
> >> failure
> >> on 2.2.x. Not all of the FI changes I made could be ported back to
> >> 2.2.x so
> >> I'll need to figure out how to get this working with 2.2.x.
> >>
> >> As a workaround, I THINK you can set a system property of:
> >> "com.sun.xml.fastinfoset.parser.string-interning"
> >> to "true" and it may work. It looks like in some cases, JAXB is
> >> expecting
> >> interned strings which FI isn't doing by default. On 2.3, we force it
> >> to do
> >> so.
> >>
> >> Dan
> >>
> >>> dkulp wrote:
> >>> > Any chance you could create a small test case for this? I did a LOT
> >>>
> >>> of
> >>>
> >>> > testing and benchmarking with FastInfoset for 2.2.7 so I know it
> >>> > works for some use cases.
> >>> >
> >>> > On Wednesday 24 March 2010 10:43:46 am fahman_dude wrote:
> >>> >> Hi,
> >>> >>
> >>> >> I have a webservice operation that returns primitive "string". I
> >>> >> call this
> >>> >> very same operation in three different ways: 1. without any sort of
> >>> >> compression; 2. with mtom compression 3. with fastinfoset
> >>>
> >>> compression.
> >>>
> >>> >> The no compression call and mtom compression call works but
> >>>
> >>> fastinfoset
> >>>
> >>> >> call fails with this exception:
> >>> >>
> >>> >> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain
> >>>
> >>> (240)
> >>>
> >>> >> - Invoking handleMessage on interceptor
> >>> >> ...
> >>> >> 21) Caused by: java.lang.AssertionError
> >>> >>
> >>> >> at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Unmarshalling error when using fastinfoset
Posted by fahman_dude <fa...@hotmail.com>.
I confirm herewith that my real project works with the cxf 2.3-snapshot as
expected (there are some other non-critical issues with the current trunk of
2.3 e.g. BeanCreationException during initialization. Will post separate
jira ticket).
Question to community, is there atleast some sort of rumor when will 2.3 be
released?
fahman_dude wrote:
>
> Workaround works for the test project but not for my real project. I will
> attempt to test the real project with the cxf 2.3-snapshot and will report
> results in here. Dan, do you have a jira ticket on this? If not, dont
> reply I'll just post new one.
>
>
> dkulp wrote:
>>
>> On Monday 29 March 2010 9:25:34 am fahman_dude wrote:
>>> Hello,
>>>
>>> please find attached eclipse test project. Its got maven config so,
>>> normally, running "mvn install" should be sufficient to generate,
>>> compile
>>> and run unittest.
>>>
>>> I have stripped and simplified a lot of things from my real use case,
>>> but I
>>> still get the same exception I reported even with this simplified
>>> example.
>>>
>>> http://old.nabble.com/file/p28069257/cxf.jaxws.infoset.twoway.mep.test.zip
>>> cxf.jaxws.infoset.twoway.mep.test.zip
>>>
>>
>> The good news is this doesn't fail on trunk/2.3. I CAN reproduce the
>> failure
>> on 2.2.x. Not all of the FI changes I made could be ported back to
>> 2.2.x so
>> I'll need to figure out how to get this working with 2.2.x.
>>
>> As a workaround, I THINK you can set a system property of:
>> "com.sun.xml.fastinfoset.parser.string-interning"
>> to "true" and it may work. It looks like in some cases, JAXB is
>> expecting
>> interned strings which FI isn't doing by default. On 2.3, we force it
>> to do
>> so.
>>
>> Dan
>>
>>> dkulp wrote:
>>> > Any chance you could create a small test case for this? I did a LOT
>>> of
>>> > testing and benchmarking with FastInfoset for 2.2.7 so I know it works
>>> > for some use cases.
>>> >
>>> > On Wednesday 24 March 2010 10:43:46 am fahman_dude wrote:
>>> >> Hi,
>>> >>
>>> >> I have a webservice operation that returns primitive "string". I call
>>> >> this
>>> >> very same operation in three different ways: 1. without any sort of
>>> >> compression; 2. with mtom compression 3. with fastinfoset
>>> compression.
>>> >>
>>> >> The no compression call and mtom compression call works but
>>> fastinfoset
>>> >> call fails with this exception:
>>> >>
>>> >> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain
>>> (240)
>>> >> - Invoking handleMessage on interceptor
>>> >> ...
>>> >> 21) Caused by: java.lang.AssertionError
>>> >>
>>> >> at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
>>
>
>
--
View this message in context: http://old.nabble.com/Unmarshalling-error-when-using-fastinfoset-tp28015923p28097544.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Unmarshalling error when using fastinfoset
Posted by fahman_dude <fa...@hotmail.com>.
Workaround works for the test project but not for my real project. I will
attempt to test the real project with the cxf 2.3-snapshot and will report
results in here. Dan, do you have a jira ticket on this? If not, dont reply
I'll just post new one.
dkulp wrote:
>
> On Monday 29 March 2010 9:25:34 am fahman_dude wrote:
>> Hello,
>>
>> please find attached eclipse test project. Its got maven config so,
>> normally, running "mvn install" should be sufficient to generate, compile
>> and run unittest.
>>
>> I have stripped and simplified a lot of things from my real use case, but
>> I
>> still get the same exception I reported even with this simplified
>> example.
>>
>> http://old.nabble.com/file/p28069257/cxf.jaxws.infoset.twoway.mep.test.zip
>> cxf.jaxws.infoset.twoway.mep.test.zip
>>
>
> The good news is this doesn't fail on trunk/2.3. I CAN reproduce the
> failure
> on 2.2.x. Not all of the FI changes I made could be ported back to 2.2.x
> so
> I'll need to figure out how to get this working with 2.2.x.
>
> As a workaround, I THINK you can set a system property of:
> "com.sun.xml.fastinfoset.parser.string-interning"
> to "true" and it may work. It looks like in some cases, JAXB is
> expecting
> interned strings which FI isn't doing by default. On 2.3, we force it
> to do
> so.
>
> Dan
>
>> dkulp wrote:
>> > Any chance you could create a small test case for this? I did a LOT of
>> > testing and benchmarking with FastInfoset for 2.2.7 so I know it works
>> > for some use cases.
>> >
>> > On Wednesday 24 March 2010 10:43:46 am fahman_dude wrote:
>> >> Hi,
>> >>
>> >> I have a webservice operation that returns primitive "string". I call
>> >> this
>> >> very same operation in three different ways: 1. without any sort of
>> >> compression; 2. with mtom compression 3. with fastinfoset compression.
>> >>
>> >> The no compression call and mtom compression call works but
>> fastinfoset
>> >> call fails with this exception:
>> >>
>> >> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain (240)
>> >> - Invoking handleMessage on interceptor
>> >> ...
>> >> 21) Caused by: java.lang.AssertionError
>> >>
>> >> at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
>
--
View this message in context: http://old.nabble.com/Unmarshalling-error-when-using-fastinfoset-tp28015923p28081005.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Unmarshalling error when using fastinfoset
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 29 March 2010 9:25:34 am fahman_dude wrote:
> Hello,
>
> please find attached eclipse test project. Its got maven config so,
> normally, running "mvn install" should be sufficient to generate, compile
> and run unittest.
>
> For those of you opening the project in eclipse BEFORE running maven, don't
> worry about compilation errors! This is because the webservice is intended
> contract-first and missing classes causing compilation errors will be
> generated by wsdl2java when running maven.
>
> I have stripped and simplified a lot of things from my real use case, but I
> still get the same exception I reported even with this simplified example.
>
> http://old.nabble.com/file/p28069257/cxf.jaxws.infoset.twoway.mep.test.zip
> cxf.jaxws.infoset.twoway.mep.test.zip
>
The good news is this doesn't fail on trunk/2.3. I CAN reproduce the failure
on 2.2.x. Not all of the FI changes I made could be ported back to 2.2.x so
I'll need to figure out how to get this working with 2.2.x.
As a workaround, I THINK you can set a system property of:
"com.sun.xml.fastinfoset.parser.string-interning"
to "true" and it may work. It looks like in some cases, JAXB is expecting
interned strings which FI isn't doing by default. On 2.3, we force it to do
so.
Dan
> dkulp wrote:
> > Any chance you could create a small test case for this? I did a LOT of
> > testing and benchmarking with FastInfoset for 2.2.7 so I know it works
> > for some use cases.
> >
> > On Wednesday 24 March 2010 10:43:46 am fahman_dude wrote:
> >> Hi,
> >>
> >> I have a webservice operation that returns primitive "string". I call
> >> this
> >> very same operation in three different ways: 1. without any sort of
> >> compression; 2. with mtom compression 3. with fastinfoset compression.
> >>
> >> The no compression call and mtom compression call works but fastinfoset
> >> call fails with this exception:
> >>
> >> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain (240)
> >> - Invoking handleMessage on interceptor
> >> ...
> >> 21) Caused by: java.lang.AssertionError
> >>
> >> at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Unmarshalling error when using fastinfoset
Posted by fahman_dude <fa...@hotmail.com>.
Hello,
please find attached eclipse test project. Its got maven config so,
normally, running "mvn install" should be sufficient to generate, compile
and run unittest.
For those of you opening the project in eclipse BEFORE running maven, don't
worry about compilation errors! This is because the webservice is intended
contract-first and missing classes causing compilation errors will be
generated by wsdl2java when running maven.
I have stripped and simplified a lot of things from my real use case, but I
still get the same exception I reported even with this simplified example.
http://old.nabble.com/file/p28069257/cxf.jaxws.infoset.twoway.mep.test.zip
cxf.jaxws.infoset.twoway.mep.test.zip
dkulp wrote:
>
>
> Any chance you could create a small test case for this? I did a LOT of
> testing and benchmarking with FastInfoset for 2.2.7 so I know it works for
> some use cases.
>
> On Wednesday 24 March 2010 10:43:46 am fahman_dude wrote:
>> Hi,
>>
>> I have a webservice operation that returns primitive "string". I call
>> this
>> very same operation in three different ways: 1. without any sort of
>> compression; 2. with mtom compression 3. with fastinfoset compression.
>>
>> The no compression call and mtom compression call works but fastinfoset
>> call fails with this exception:
>>
>> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain (240)
>> - Invoking handleMessage on interceptor
>> ...
>> 21) Caused by: java.lang.AssertionError
>> at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
>
--
View this message in context: http://old.nabble.com/Unmarshalling-error-when-using-fastinfoset-tp28015923p28069257.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Unmarshalling error when using fastinfoset
Posted by Daniel Kulp <dk...@apache.org>.
Any chance you could create a small test case for this? I did a LOT of
testing and benchmarking with FastInfoset for 2.2.7 so I know it works for
some use cases.
Dan
On Wednesday 24 March 2010 10:43:46 am fahman_dude wrote:
> Hi,
>
> I have a webservice operation that returns primitive "string". I call this
> very same operation in three different ways: 1. without any sort of
> compression; 2. with mtom compression 3. with fastinfoset compression.
>
> The no compression call and mtom compression call works but fastinfoset
> call fails with this exception:
>
> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain (240)
> - Invoking handleMessage on interceptor
> org.apache.cxf.interceptor.DocLiteralInInterceptor@1bb3e9a
> 15:24:49,343 WARN [main] apache.cxf.phase.PhaseInterceptorChain (365)
> - Interceptor for
> {http://blahblah/email/service}EmailUS#{http://blahblah/email/service}sendE
> mail has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: null
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:7
> 80) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:6
> 24) at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteral
> InInterceptor.java:106) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:672) at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons
> eInternal(HTTPConduit.java:2254) at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons
> e(HTTPConduit.java:2134) at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPCon
> duit.java:1988) at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputSt
> ream.java:47) at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188) at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639) at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
> rceptor.handleMessage(MessageSenderInterceptor.java:62) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:484) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:310) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:262) at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) at
> $Proxy67.sendEmail(Unknown Source)
> at
> blahblah.email.service.EmailUSWSImplTest.prepareAndCallSendEmailWebService(
> EmailUSWSImplTest.java:332) at
> blahblah.email.service.EmailUSWSImplTest.testSendEmailWithFastinfosetCompre
> ssion(EmailUSWSImplTest.java:304) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
> 9) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
> l.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(Method
> Roadie.java:87) at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at
> org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRu
> nner.java:88) at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.j
> ava:51) at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:4
> 4) at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:5
> 9) at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(A
> bstractDirectoryTestSuite.java:115) at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abstract
> DirectoryTestSuite.java:102) at
> org.apache.maven.surefire.Surefire.run(Surefire.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
> 9) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
> l.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Surefire
> Booter.java:350) at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:10
> 21) Caused by: java.lang.AssertionError
> at com.sun.xml.bind.v2.util.QNameMap.getEntry(QNameMap.java:460)
> at com.sun.xml.bind.v2.util.QNameMap.get(QNameMap.java:158)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(Struc
> tureLoader.java:241) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:478) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(
> UnmarshallingContext.java:459) at
> com.sun.xml.bind.v2.runtime.unmarshaller.FastInfosetConnector.handleStartEl
> ement(FastInfosetConnector.java:162) at
> com.sun.xml.bind.v2.runtime.unmarshaller.FastInfosetConnector.bridge(FastIn
> fosetConnector.java:105) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unmars
> hallerImpl.java:360) at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(Unmarsh
> allerImpl.java:339) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:7
> 55) ... 48 more
>
> If I change return type of the operation to one way (remove output message
> from the porttype def) the call to fastinfoset works just fine!!! But as
> soon as I make the operation two way, it brings this error.
> I tried:
> - changing return type to int;
> - enabling FI declaratively by adding <fastinfoset/> to bus definition in
> cxf.xml
> - enabling FI programaticaly by adding FIStaxXXInterceptor to endpoints
> - adding fresh new operation to the webservice with the return value and
> testing if it works
> none of this worked for me.
>
> thank you and kind regards
> reinis
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog