Any ideas on this? I'm really keen to move to 2.3.1, without forcing my
users to regen their code.

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
>>>
>>
>>
>

Reply via email to