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 <[email protected]> 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 > > > > > > > >
