You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Fabrice Fontenoy <fa...@sophia.inria.fr> on 2009/10/27 13:33:51 UTC
Use of CXF without javax.wsdl.extensions.soap12 package
Hi,
We've got a problem using CXF in our project since it uses the wsdl4j
library. This library is under the CPL licence which is not compatible
with our project licence (GPL).
One solution is to replace this lib with either groovysoap-all.jar or
axis-wsdl4j.jar (ASL licence compatible with GPLv3).
It works fine with our implementation using Axis2 (that normally uses
wsdl4j too) but it doesn't with CXF since it needs
classes of the javax.wsdl.extensions.soap12 package.
Is there a way to use CXF (to programmatically expose and consume
services) without using javax.wsdl.extensions.soap12 ?
Have you already faced this licence issue and found a better solution ?
Many thanks,
Regards,
Fabrice Fontenoy
Re: Use of CXF without javax.wsdl.extensions.soap12 package
Posted by Fabrice Fontenoy <fa...@sophia.inria.fr>.
Finally, I've found the library
org.apache.servicemix.bundles.wsdl4j-1.6.1_1.jar available on
http://servicemix.apache.org/SMX4/bundles-repository.html which is under
ASL2.0.
That solves all my problems.
Fabrice
Fabrice Fontenoy wrote:
> As I did not find the sources of axis-wsdl4j in a reasonable time, I
> tried my solution and it works.
> I removed the references of javax.wsdl.extensions.soap12 in the
> following classes:
> org.apache.cxf.tools.util.SOAPBindingUtil.java
> org.apache.cxf.tools.common.extension.soap.*.java
> I rebuilt cxf and integrated it into our project.
>
> Hoping that it will help,
>
> Fabrice
>
> Fabrice Fontenoy wrote:
>> Many thanks.
>> I was thinking about removing dependencies on with package from cxf
>> but it seemed cumbersome (and not beautiful at all).
>> I did not think about your solution which looks better.
>>
>> I'll try and let you informed.
>>
>> Daniel Kulp wrote:
>>> On Tue October 27 2009 8:33:51 am Fabrice Fontenoy wrote:
>>>
>>>> Hi,
>>>>
>>>> We've got a problem using CXF in our project since it uses the wsdl4j
>>>> library. This library is under the CPL licence which is not compatible
>>>> with our project licence (GPL).
>>>>
>>>> One solution is to replace this lib with either groovysoap-all.jar or
>>>> axis-wsdl4j.jar (ASL licence compatible with GPLv3).
>>>> It works fine with our implementation using Axis2 (that normally uses
>>>> wsdl4j too) but it doesn't with CXF since it needs
>>>> classes of the javax.wsdl.extensions.soap12 package.
>>>>
>>>> Is there a way to use CXF (to programmatically expose and consume
>>>> services) without using javax.wsdl.extensions.soap12 ?
>>>> Have you already faced this licence issue and found a better
>>>> solution ?
>>>>
>>>
>>> Nope. Never faced this issue before. My best suggestion would be
>>> to take the source code for axis-wsdl4j.jar and copy/rename the
>>> classes in javax.wsdl.extensions.soap into
>>> javax.wsdl.extensions.soap12 and build a new jar with just the new
>>> javax.wsdl.extensions.soap12 classes in it. That MAY allow use
>>> with CXF as long as you don't actually use soap12 anywhere. The
>>> interfaces would then at least exist, just no implementation. But
>>> that may be OK.
>>>
>>>
>>
>
Re: Use of CXF without javax.wsdl.extensions.soap12 package
Posted by Fabrice Fontenoy <fa...@sophia.inria.fr>.
As I did not find the sources of axis-wsdl4j in a reasonable time, I
tried my solution and it works.
I removed the references of javax.wsdl.extensions.soap12 in the
following classes:
org.apache.cxf.tools.util.SOAPBindingUtil.java
org.apache.cxf.tools.common.extension.soap.*.java
I rebuilt cxf and integrated it into our project.
Hoping that it will help,
Fabrice
Fabrice Fontenoy wrote:
> Many thanks.
> I was thinking about removing dependencies on with package from cxf
> but it seemed cumbersome (and not beautiful at all).
> I did not think about your solution which looks better.
>
> I'll try and let you informed.
>
> Daniel Kulp wrote:
>> On Tue October 27 2009 8:33:51 am Fabrice Fontenoy wrote:
>>
>>> Hi,
>>>
>>> We've got a problem using CXF in our project since it uses the wsdl4j
>>> library. This library is under the CPL licence which is not compatible
>>> with our project licence (GPL).
>>>
>>> One solution is to replace this lib with either groovysoap-all.jar or
>>> axis-wsdl4j.jar (ASL licence compatible with GPLv3).
>>> It works fine with our implementation using Axis2 (that normally uses
>>> wsdl4j too) but it doesn't with CXF since it needs
>>> classes of the javax.wsdl.extensions.soap12 package.
>>>
>>> Is there a way to use CXF (to programmatically expose and consume
>>> services) without using javax.wsdl.extensions.soap12 ?
>>> Have you already faced this licence issue and found a better solution ?
>>>
>>
>> Nope. Never faced this issue before. My best suggestion would be
>> to take the source code for axis-wsdl4j.jar and copy/rename the
>> classes in javax.wsdl.extensions.soap into
>> javax.wsdl.extensions.soap12 and build a new jar with just the new
>> javax.wsdl.extensions.soap12 classes in it. That MAY allow use with
>> CXF as long as you don't actually use soap12 anywhere. The
>> interfaces would then at least exist, just no implementation. But
>> that may be OK.
>>
>>
>
Re: Use of CXF without javax.wsdl.extensions.soap12 package
Posted by Fabrice Fontenoy <fa...@sophia.inria.fr>.
Many thanks.
I was thinking about removing dependencies on with package from cxf but
it seemed cumbersome (and not beautiful at all).
I did not think about your solution which looks better.
I'll try and let you informed.
Daniel Kulp wrote:
> On Tue October 27 2009 8:33:51 am Fabrice Fontenoy wrote:
>
>> Hi,
>>
>> We've got a problem using CXF in our project since it uses the wsdl4j
>> library. This library is under the CPL licence which is not compatible
>> with our project licence (GPL).
>>
>> One solution is to replace this lib with either groovysoap-all.jar or
>> axis-wsdl4j.jar (ASL licence compatible with GPLv3).
>> It works fine with our implementation using Axis2 (that normally uses
>> wsdl4j too) but it doesn't with CXF since it needs
>> classes of the javax.wsdl.extensions.soap12 package.
>>
>> Is there a way to use CXF (to programmatically expose and consume
>> services) without using javax.wsdl.extensions.soap12 ?
>> Have you already faced this licence issue and found a better solution ?
>>
>
> Nope. Never faced this issue before. My best suggestion would be to take
> the source code for axis-wsdl4j.jar and copy/rename the classes in
> javax.wsdl.extensions.soap into javax.wsdl.extensions.soap12 and build a new
> jar with just the new javax.wsdl.extensions.soap12 classes in it. That MAY
> allow use with CXF as long as you don't actually use soap12 anywhere. The
> interfaces would then at least exist, just no implementation. But that may
> be OK.
>
>
Re: Use of CXF without javax.wsdl.extensions.soap12 package
Posted by Daniel Kulp <dk...@apache.org>.
On Tue October 27 2009 8:33:51 am Fabrice Fontenoy wrote:
> Hi,
>
> We've got a problem using CXF in our project since it uses the wsdl4j
> library. This library is under the CPL licence which is not compatible
> with our project licence (GPL).
>
> One solution is to replace this lib with either groovysoap-all.jar or
> axis-wsdl4j.jar (ASL licence compatible with GPLv3).
> It works fine with our implementation using Axis2 (that normally uses
> wsdl4j too) but it doesn't with CXF since it needs
> classes of the javax.wsdl.extensions.soap12 package.
>
> Is there a way to use CXF (to programmatically expose and consume
> services) without using javax.wsdl.extensions.soap12 ?
> Have you already faced this licence issue and found a better solution ?
Nope. Never faced this issue before. My best suggestion would be to take
the source code for axis-wsdl4j.jar and copy/rename the classes in
javax.wsdl.extensions.soap into javax.wsdl.extensions.soap12 and build a new
jar with just the new javax.wsdl.extensions.soap12 classes in it. That MAY
allow use with CXF as long as you don't actually use soap12 anywhere. The
interfaces would then at least exist, just no implementation. But that may
be OK.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog