And stupid question of the day..where is @WebReturn supposed to be in, jaxws-api? My IDE doesn't seem to know where to find it.
On 13 December 2010 21:37, Yiannis Mavroukakis < [email protected]> wrote: > Hello Daniel, > the WebReturn is a great suggestion, I'll get that setup, but I will also > pursue your suggestion about the debug. Any particular class I should be > looking towards for that, except the BareOutInterceptor? > > Oh and a huge facepalm on my part about _return... :) > > > On 13 December 2010 20:42, Daniel Kulp <[email protected]> wrote: > >> On Monday 13 December 2010 6:07:32 am Yiannis Mavroukakis wrote: >> > Any ideas on this? I'm really keen to move to 2.3.1, without forcing my >> > users to regen their code. >> >> Honestly, I'm not really sure. Is there an @WebReturn on the methods >> with a >> "name" in it? That SHOULD be the easiest way from your side to make sure >> it >> stays consistent. >> >> While debugging, can you see if there are any @XmlElement annotations on >> the >> _return parameter? _return is correct (since you cannot have a name of >> "return" as it's a reserved word), but there should be an @XmlElement >> annotation on it. >> >> Dan >> >> >> >> > On 9 December 2010 14:29, Yiannis Mavroukakis < >> > >> > [email protected]> wrote: >> > > 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 >> >> -- >> Daniel Kulp >> [email protected] >> http://dankulp.com/blog >> > >
