I thought I may have found the issue, while debugging BareOutInterceptor but I'm still stumped..
My operation is called login, so in the MessageContentsList I end up with a com.gameaccount.external.account.jaxws_asm.LoginResponse class. this contains my own BaseResponse class under a _return variable, which is what I am guessing gets written out...The thing that got me though is that this is exactly the same under 2.3.0, so there must be something a lot more subtle at work here.. Y. On 9 December 2010 10:20, Yiannis Mavroukakis < [email protected]> wrote: > Here's a diff of 2.3.0 with 2.3.1 > > spazstik:account imavroukakis$ diff 2.3.0 2.3.1 > 20c20 > < [INFO] +- org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.3.0:compile > --- > > [INFO] +- org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.3.1:compile > 23,24c23,24 > < [INFO] | +- org.apache.cxf:cxf-api:jar:2.3.0:compile > < [INFO] | | +- org.apache.cxf:cxf-common-utilities:jar:2.3.0:compile > --- > > [INFO] | +- org.apache.cxf:cxf-api:jar:2.3.1:compile > > [INFO] | | +- org.apache.cxf:cxf-common-utilities:jar:2.3.1:compile > 30,31c30,31 > < [INFO] | | \- org.apache.cxf:cxf-common-schemas:jar:2.3.0:compile > < [INFO] | +- org.apache.cxf:cxf-rt-core:jar:2.3.0:compile > --- > > [INFO] | | \- org.apache.cxf:cxf-common-schemas:jar:2.3.1:compile > > [INFO] | +- org.apache.cxf:cxf-rt-core:jar:2.3.1:compile > 34,40c34,40 > < [INFO] | +- org.apache.cxf:cxf-rt-bindings-soap:jar:2.3.0:compile > < [INFO] | | +- org.apache.cxf:cxf-tools-common:jar:2.3.0:compile > < [INFO] | | \- org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.3.0:compile > < [INFO] | +- org.apache.cxf:cxf-rt-bindings-xml:jar:2.3.0:compile > < [INFO] | +- org.apache.cxf:cxf-rt-frontend-simple:jar:2.3.0:compile > < [INFO] | \- org.apache.cxf:cxf-rt-ws-addr:jar:2.3.0:compile > < [INFO] +- org.apache.cxf:cxf-rt-transports-http:jar:2.3.0:compile > --- > > [INFO] | +- org.apache.cxf:cxf-rt-bindings-soap:jar:2.3.1:compile > > [INFO] | | +- org.apache.cxf:cxf-tools-common:jar:2.3.1:compile > > [INFO] | | \- org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.3.1:compile > > [INFO] | +- org.apache.cxf:cxf-rt-bindings-xml:jar:2.3.1:compile > > [INFO] | +- org.apache.cxf:cxf-rt-frontend-simple:jar:2.3.1:compile > > [INFO] | \- org.apache.cxf:cxf-rt-ws-addr:jar:2.3.1:compile > > [INFO] +- org.apache.cxf:cxf-rt-transports-http:jar:2.3.1:compile > 78,79c78,79 > > Nothing leaps out at me. I am using jaxb/ws 2.2.1 btw, I will try with 2.2 > just in case. > > Y > > On 8 December 2010 20:33, Daniel Kulp <[email protected]> wrote: > >> On Wednesday 08 December 2010 11:58:07 am Yiannis Mavroukakis wrote: >> > Sorry, stupidly forgot to include more info about my setup. I am seeing >> > this on the deployed service, I use a code first approach, so it was >> > simply a case of updating the version on my pom, recompiling and firing >> up >> > the service. If you need anything specific to debug this I'd be happy to >> > help. >> >> I have NO idea what would cause this. Can you do something like: >> >> mvn clean dependency:copy-dependencies >> or even just >> mvn dependency:tree >> >> with each of the two and see if different versions of things are popping >> up? >> >> This isn't in OSGi, is it? >> >> >> Dan >> >> >> >> > >> > Thanks, >> > >> > Yiannis >> > >> > On 8 December 2010 16:53, Daniel Kulp <[email protected]> wrote: >> > > On Wednesday 08 December 2010 11:45:15 am Yiannis Mavroukakis wrote: >> > > > Hello everyone, >> > > > >> > > > I updated from 2.3.0 to 2.3.1 today, and I noticed that the <return> >> > > > element has changed to <_return> any particular reason for this? >> > > >> > > No idea really. Is there any way to create a small test case? >> > > >> > > The only thing that really was done around this is with the wsdl2java >> > > tool and >> > > java2ws tools (is that where you are seeing this), we did a better job >> of >> > > endorsing the jaxws/jaxb 2.2 stuff. If this is just a runtime thing, >> > > then that really wouldn't apply though. >> > > >> > > >> > > -- >> > > Daniel Kulp >> > > [email protected] >> > > http://dankulp.com/blog >> >> -- >> Daniel Kulp >> [email protected] >> http://dankulp.com/blog >> > >
