You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Peter Condick <pe...@digio.com.au> on 2019/05/17 07:40:59 UTC
CXF 3.3.x issue
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
Posted by Alexey Markevich <bu...@gmail.com>.
Hi Peter,
Since 3.3.x there is strict requirement for targetNamespace attribute
value[1]: it should be URI; according to [2] only double slash "//"
allowed.
Please update your WSDL with
targetNamespace="http://example.com.au/otherstuff"
1. https://www.w3.org/TR/2001/NOTE-wsdl-20010315#_document-n
2. https://www.w3.org/2002/11/dbooth-names/rfc2396-numbered_clean.htm L666
On 5/17/19, 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
Posted by James Carman <ja...@carmanconsulting.com>.
do you really only have one "/" in your namespace after "http:"? That
could be related?
On Fri, May 17, 2019 at 8:14 AM 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
Posted by 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
Re: CXF 3.3.x issue
Posted by 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
Posted by David Jencks <da...@gmail.com>.
I have no experience with it but others seem to be able to use the maven shade plugin to miraculous effect. Would it be possible to run the shade plugin on the generated code to adjust the package name to what your other code expects?
david jencks
> On May 17, 2019, at 12:40 AM, 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