Re: CXF 3.3.x issue

[Peter Condick <pe...@digio.com.au>]

Hello CXF devs

We have a issue with version 3.3.x of CXF. See details below.

I know CXF is open source and if we really want it fixing we should
contribute. But at the moment what we would really like to know is -

Is the below behaviour intended behaviour? If so we can just upgrade to
3.3.x and change all our imports. Or is it actually a bug that should get
fixed one day. In which case we won't upgrade yet.

Thanks very much. We appreciate all the work you do.

Pete



On Fri, May 17, 2019 at 5:40 PM Peter Condick <pe...@digio.com.au>
wrote:

> Hi
>
> We're using CXF in our project and we have come across an issue moving
> from 3.2.9 to 3.3.2 (and also affects 3.3.1).
>
> We are replacing old legacy systems with new systems using CXF. This means
> unfortunately that we can not change any of the wsdl files.
>
> Some of the wsdl files we have to use have namespaces declared like
>
> <wsdl:definitions name="ExampleService_v1_0" targetNamespace="http:/example.com.au/otherstuff"  ... other name spaces defined>
>
>
> Note only one / after the http: in the targetNamespace
>
> With 3.2.x when we generated java classes from a wsdl like this it would
> be put in the package
>
> au.com.example.otherstuff
>
> Now with 3.3.x the classes are generated in the package
>
> au.com.xample.otherstuff
>
> note the e is removed from example
>
> Is this intended behaviour or is this a bug? If it is intended behaviour
> is there a way to make it behave in the old way? If it is a bug is it one
> you are likely to fix?
>
> The code generated in the xample package works fine. But this is a problem
> for us as it means if we upgrade the version of CXF in one of our existing
> repositories all the imports in our code will break. Correcting the wsdl
> files to have http:// rather than http:/ would be the ideal I agree but
> unfortunately we can't do that when we are changing legacy implementations.
>
> Thanks very much. We appreciate all the work you do.
>
> Pete
>
>
>
>
>
>
>
>

Re: CXF 3.3.x issue

[Colm O hEigeartaigh <co...@apache.org>]

Did you miss Alexey's reply?

https://lists.apache.org/thread.html/bd02fc736659bb2466254ddd062540f20bee7e25881cb75797c49f64@%3Cdev.cxf.apache.org%3E

Colm.

On Mon, Jun 24, 2019 at 2:11 AM Peter Condick <pe...@digio.com.au>
wrote:

> Hello CXF devs
>
> We have a issue with version 3.3.x of CXF. See details below.
>
> I know CXF is open source and if we really want it fixing we should
> contribute. But at the moment what we would really like to know is -
>
> Is the below behaviour intended behaviour? If so we can just upgrade to
> 3.3.x and change all our imports. Or is it actually a bug that should get
> fixed one day. In which case we won't upgrade yet.
>
> Thanks very much. We appreciate all the work you do.
>
> Pete
>
>
>
> On Fri, May 17, 2019 at 5:40 PM Peter Condick <pe...@digio.com.au>
> wrote:
>
> > Hi
> >
> > We're using CXF in our project and we have come across an issue moving
> > from 3.2.9 to 3.3.2 (and also affects 3.3.1).
> >
> > We are replacing old legacy systems with new systems using CXF. This
> means
> > unfortunately that we can not change any of the wsdl files.
> >
> > Some of the wsdl files we have to use have namespaces declared like
> >
> > <wsdl:definitions name="ExampleService_v1_0" targetNamespace="http:/
> example.com.au/otherstuff"  ... other name spaces defined>
> >
> >
> > Note only one / after the http: in the targetNamespace
> >
> > With 3.2.x when we generated java classes from a wsdl like this it would
> > be put in the package
> >
> > au.com.example.otherstuff
> >
> > Now with 3.3.x the classes are generated in the package
> >
> > au.com.xample.otherstuff
> >
> > note the e is removed from example
> >
> > Is this intended behaviour or is this a bug? If it is intended behaviour
> > is there a way to make it behave in the old way? If it is a bug is it one
> > you are likely to fix?
> >
> > The code generated in the xample package works fine. But this is a
> problem
> > for us as it means if we upgrade the version of CXF in one of our
> existing
> > repositories all the imports in our code will break. Correcting the wsdl
> > files to have http:// rather than http:/ would be the ideal I agree but
> > unfortunately we can't do that when we are changing legacy
> implementations.
> >
> > Thanks very much. We appreciate all the work you do.
> >
> > Pete
> >
> >
> >
> >
> >
> >
> >
> >
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com