Re: How to make classes created from wsdl2java implements serializable?
I had exactly the same problem with cxf and swf. And here is the solution you need: ?xml version=1.0 encoding=UTF-8? jaxws:bindings wsdlLocation=YOUR_WSDL_LOCATION xmlns:jaxws=http://java.sun.com/xml/ns/jaxws; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; jaxws:bindings node=wsdl:definitions/wsdl:types/xs:[EMAIL PROTECTED]'YOUR_TARGET_NAMESPACE'] jxb:globalBindings xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:xs=http://www.w3.org/2001/XMLSchema; jxb:serializable/ /jxb:globalBindings /jaxws:bindings /jaxws:bindings I hope it works for you too. Regards, Akos daniel.mfreitas wrote: Hello. I want to use wsdl2java to generate the client stubs to be used by my client web application. I am using Spring Web Flow and it requires that objects used in the flow are Serializable. I successfully generated Serializable classes using the following bindings file and Metro JAXWS RI implementation: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jaxb=http://java.sun.com/xml/ns/jaxb; xmlns:xjc=http://java.sun.com/xml/ns/jaxb/xjc; elementFormDefault=qualified attributeFormDefault=unqualified jaxb:extensionBindingPrefixes=xjc jaxb:version=1.0 xs:annotation xs:appinfo jaxb:globalBindings xjc:serializable uid=-6026937020915831338/ /jaxb:globalBindings /xs:appinfo /xs:annotation /xs:schema But because of some limitations of Metro RI, we want to switch to CXF. When calling wsdl2java from a maven build file and we try to supply the above binding file, cfx throws WSDLToJava Error : Unknown external binding files: This is not a FileNotFoundError. wsdl2java does find the file, but it seems it does not understand its contents. I wanted to use CXF for everything including java2wsdl and wsdl2java. We have bad experiences to set up JAXWS Metro RI and for some developers it is a pain to put it to work. So how can I make the entities stubs to implement serializable with wsdl2java? -- View this message in context: http://www.nabble.com/How-to-make-classes-created-from-wsdl2java-implements-serializable--tp14246207p15062180.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Creating and publishing services from wsdl
As Benson mentioned, take a look at the JaxWsServerFactoryBean. When you are using spring to configure things with jaxws:server, that is the object that Spring is manipulating. Thus, anything you can configure there should have appropriate options on the bean. The other option is to create a org.apache.cxf.jaxws.EndpointImpl object directly and configure that. That's the object spring is manipulating when you use jaxws:enpoint.The first option is probably better though. Dan On Wednesday 23 January 2008, Rob Barrett wrote: that's what i'm looking for - got a url? On Jan 24, 2008 12:46 PM, Benson Margulies [EMAIL PROTECTED] wrote: Ideally I'd like to achieve all of this programatically - i.e. without having to knock together a big config file. All that spring config corresponds to plain old Java objects. Some of them are even specified by the JAX-WS specification :-) Beyond the stock JAXWS API, all of CXF can be configured programmatically, so you can, indeed, stamp these things out like cookies. See the user guide section on non-spring configuration. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: How to make classes created from wsdl2java implements serializable?
Thanks Akos, I will try this a later time. For this project we will keep using metro RI, we don't have time to change that as we are close to the end of the project. 1 quick question though: the wsdlLocation=YOUR_WSDL_LOCATION should point to the final destination of your wsdls or is it used just to generate the serializable classes? Can I provide it the WSDL in my disk as it is created by Maven and expect things to work when moved to production and the wsdl location changes to http://watever? []s Daniel Akos Kiss wrote: I had exactly the same problem with cxf and swf. And here is the solution you need: ?xml version=1.0 encoding=UTF-8? jaxws:bindings wsdlLocation=YOUR_WSDL_LOCATION xmlns:jaxws=http://java.sun.com/xml/ns/jaxws; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; jaxws:bindings node=wsdl:definitions/wsdl:types/xs:[EMAIL PROTECTED]'YOUR_TARGET_NAMESPACE'] jxb:globalBindings xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:xs=http://www.w3.org/2001/XMLSchema; jxb:serializable/ /jxb:globalBindings /jaxws:bindings /jaxws:bindings I hope it works for you too. Regards, Akos daniel.mfreitas wrote: Hello. I want to use wsdl2java to generate the client stubs to be used by my client web application. I am using Spring Web Flow and it requires that objects used in the flow are Serializable. I successfully generated Serializable classes using the following bindings file and Metro JAXWS RI implementation: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jaxb=http://java.sun.com/xml/ns/jaxb; xmlns:xjc=http://java.sun.com/xml/ns/jaxb/xjc; elementFormDefault=qualified attributeFormDefault=unqualified jaxb:extensionBindingPrefixes=xjc jaxb:version=1.0 xs:annotation xs:appinfo jaxb:globalBindings xjc:serializable uid=-6026937020915831338/ /jaxb:globalBindings /xs:appinfo /xs:annotation /xs:schema But because of some limitations of Metro RI, we want to switch to CXF. When calling wsdl2java from a maven build file and we try to supply the above binding file, cfx throws WSDLToJava Error : Unknown external binding files: This is not a FileNotFoundError. wsdl2java does find the file, but it seems it does not understand its contents. I wanted to use CXF for everything including java2wsdl and wsdl2java. We have bad experiences to set up JAXWS Metro RI and for some developers it is a pain to put it to work. So how can I make the entities stubs to implement serializable with wsdl2java? -- View this message in context: http://www.nabble.com/How-to-make-classes-created-from-wsdl2java-implements-serializable--tp14246207p15065628.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: How to make classes created from wsdl2java implements serializable?
Daniel, The binding file is ONLY used at code generation time as an option passed to wsdl2java. It's not used at runtime at all. Thus, it should point to whatever the development time location would be. Dan On Thursday 24 January 2008, daniel.mfreitas wrote: Thanks Akos, I will try this a later time. For this project we will keep using metro RI, we don't have time to change that as we are close to the end of the project. 1 quick question though: the wsdlLocation=YOUR_WSDL_LOCATION should point to the final destination of your wsdls or is it used just to generate the serializable classes? Can I provide it the WSDL in my disk as it is created by Maven and expect things to work when moved to production and the wsdl location changes to http://watever? []s Daniel Akos Kiss wrote: I had exactly the same problem with cxf and swf. And here is the solution you need: ?xml version=1.0 encoding=UTF-8? jaxws:bindings wsdlLocation=YOUR_WSDL_LOCATION xmlns:jaxws=http://java.sun.com/xml/ns/jaxws; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; jaxws:bindings node=wsdl:definitions/wsdl:types/xs:[EMAIL PROTECTED]'YOUR_T ARGET_NAMESPACE'] jxb:globalBindings xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:xs=http://www.w3.org/2001/XMLSchema; jxb:serializable/ /jxb:globalBindings /jaxws:bindings /jaxws:bindings I hope it works for you too. Regards, Akos daniel.mfreitas wrote: Hello. I want to use wsdl2java to generate the client stubs to be used by my client web application. I am using Spring Web Flow and it requires that objects used in the flow are Serializable. I successfully generated Serializable classes using the following bindings file and Metro JAXWS RI implementation: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jaxb=http://java.sun.com/xml/ns/jaxb; xmlns:xjc=http://java.sun.com/xml/ns/jaxb/xjc; elementFormDefault=qualified attributeFormDefault=unqualified jaxb:extensionBindingPrefixes=xjc jaxb:version=1.0 xs:annotation xs:appinfo jaxb:globalBindings xjc:serializable uid=-6026937020915831338/ /jaxb:globalBindings /xs:appinfo /xs:annotation /xs:schema But because of some limitations of Metro RI, we want to switch to CXF. When calling wsdl2java from a maven build file and we try to supply the above binding file, cfx throws WSDLToJava Error : Unknown external binding files: This is not a FileNotFoundError. wsdl2java does find the file, but it seems it does not understand its contents. I wanted to use CXF for everything including java2wsdl and wsdl2java. We have bad experiences to set up JAXWS Metro RI and for some developers it is a pain to put it to work. So how can I make the entities stubs to implement serializable with wsdl2java? -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
[Dynamic Client, TypeClassInitializer, Wrapped operation] problem
Hi,
The WSDL pasted at the end of this email contains two methods:
getApprovedTerms, verifyTerm. There signatures are very close, yet,
verifyItem is wrappable and getApprovedTerms isn't...Can somebody please
explain me why?
I am working with CXF 2.0.1 patched. I did update TypeClassSerializer to
fix a couple of bugs.
When I execute this code:
DynamicClientFactory dynamicClientFactory =
DynamicClientFactory.newInstance(bus);
Client client = dynamicClientFactory.createClient(wsdl);
ServiceInfo model =
client.getEndpoint().getService().getServiceInfos().get(0);
InterfaceInfo interfaceInfo = model.getInterface();
CollectionOperationInfo operationInfos =
interfaceInfo.getOperations();
for(OperationInfo operationInfo:operationInfos){
MessageInfo outputMessageInfo = operationInfo.getInput();
MapQName,MessagePartInfo map =
outputMessageInfo.getMessagePartsMap();
for(EntryQName,MessagePartInfo entry : map.entrySet()){
MessagePartInfo messagePartInfo = entry.getValue();
if(messagePartInfo.getTypeClass() == null){
throw new Exception(Should not happened!!)
}
}
}
}
The Exception is unfortunately thrown:-( and should not be. I tried to
find a way to fix it myself but I am running out of ideas!
My patched TypeClassInitializer is the latest code from the source
repository.
Any Help would be really appreciated.
Thanks,
BEnjamin
?xml version='1.0' encoding='UTF-8'?
definitions name=cvServiceDefinitions
targetNamespace=http://sii.gri.roche.com;
xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
types
xs:schema attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://sii.gri.roche.com;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=getApprovedTerms
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getApprovedTermsResponse
xs:complexType
xs:sequence
xs:any/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=verifyTerm
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=termName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=verifyTermResponse
xs:complexType
xs:sequence
xs:element name=ReturnVerifyTerm type=xs:boolean/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/types
message name=verifyTerm
part element=s0:verifyTerm name=parameters/
/message
message name=verifyTermResponse
part element=s0:verifyTermResponse name=parameters/
/message
message name=getApprovedTerms
part element=s0:getApprovedTerms name=parameters/
/message
message name=getApprovedTermsResponse
part element=s0:getApprovedTermsResponse name=parameters/
/message
portType name=cvPortType
operation name=getApprovedTerms parameterOrder=parameters
input message=s0:getApprovedTerms/
output message=s0:getApprovedTermsResponse/
/operation
operation name=verifyTerm parameterOrder=parameters
input message=s0:verifyTerm/
output message=s0:verifyTermResponse/
/operation
/portType
binding name=cvServiceSoapBinding type=s0:cvPortType
s1:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
operation name=getApprovedTerms
s1:operation soapAction= style=document/
input
s1:body parts=parameters use=literal/
/input
output
s1:body parts=parameters use=literal/
/output
/operation
operation name=verifyTerm
s1:operation soapAction= style=document/
input
s1:body parts=parameters use=literal/
/input
output
s1:body parts=parameters use=literal/
/output
/operation
/binding
service name=cvService
port binding=s0:cvServiceSoapBinding name=cvPortTypeSoapPort
!--s1:address
location=http://rnuuspr12.tot.roche.com:8080/cv/cvService/--
s1:address location=http://localhost:9000/
/port
/service
/definitions
item element with xmlns=
I need to expose a service (java-first) with CXF with an exception (EchoComplexException ) that includes an array of object (of class EchoStruct). The service is setted with: anonymousWrapperType, qualifyWrapperSchema ad wrapped to true. The wsdl generated seems to be correct, with a wrapper EchoComplexException of the type: xs:complexType final=#all name=echoStructArray xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=item nillable=true type=tns:echoStruct/ /xs:sequence /xs:complexType The problem is that, on object deserialization, the EchoComplexException is serialized in: EchoComplexException xmlns=xxx ns2:reason xsi:type=echoStructArray xmlns=yyy xmlns:ns2=xxx xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; item xmlns= xmlns:ns4=yyy ns4:fieldBooleantrue/ns4:fieldBoolean /item /ns2:reason /EchoComplexException ...that's correct, except for the xmlns= item namespace. Of course the schema validation fails. Anyone meet the same problem? Marco.
FW: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem
Fyi, it fails to find the class for
{http://sii.gri.roche.com}:verifyTerm although it was generated. I
believe the bug here is that the operation is not Wrappable but can
somebody confirm?
Thanks
-Original Message-
From: Benjamin Coiffe [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 15:36
To: cxf-user@incubator.apache.org
Subject: [Dynamic Client, TypeClassInitializer, Wrapped operation]
problem
Hi,
The WSDL pasted at the end of this email contains two methods:
getApprovedTerms, verifyTerm. There signatures are very close, yet,
verifyItem is wrappable and getApprovedTerms isn't...Can somebody please
explain me why?
I am working with CXF 2.0.1 patched. I did update TypeClassSerializer to
fix a couple of bugs.
When I execute this code:
DynamicClientFactory dynamicClientFactory =
DynamicClientFactory.newInstance(bus);
Client client = dynamicClientFactory.createClient(wsdl);
ServiceInfo model =
client.getEndpoint().getService().getServiceInfos().get(0);
InterfaceInfo interfaceInfo = model.getInterface();
CollectionOperationInfo operationInfos =
interfaceInfo.getOperations();
for(OperationInfo operationInfo:operationInfos){
MessageInfo outputMessageInfo = operationInfo.getInput();
MapQName,MessagePartInfo map =
outputMessageInfo.getMessagePartsMap();
for(EntryQName,MessagePartInfo entry : map.entrySet()){
MessagePartInfo messagePartInfo = entry.getValue();
if(messagePartInfo.getTypeClass() == null){
throw new Exception(Should not happened!!)
}
}
}
}
The Exception is unfortunately thrown:-( and should not be. I tried to
find a way to fix it myself but I am running out of ideas!
My patched TypeClassInitializer is the latest code from the source
repository.
Any Help would be really appreciated.
Thanks,
BEnjamin
?xml version='1.0' encoding='UTF-8'?
definitions name=cvServiceDefinitions
targetNamespace=http://sii.gri.roche.com;
xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
types
xs:schema attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://sii.gri.roche.com;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=getApprovedTerms
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getApprovedTermsResponse
xs:complexType
xs:sequence
xs:any/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=verifyTerm
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=termName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=verifyTermResponse
xs:complexType
xs:sequence
xs:element name=ReturnVerifyTerm type=xs:boolean/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/types
message name=verifyTerm
part element=s0:verifyTerm name=parameters/
/message
message name=verifyTermResponse
part element=s0:verifyTermResponse name=parameters/
/message
message name=getApprovedTerms
part element=s0:getApprovedTerms name=parameters/
/message
message name=getApprovedTermsResponse
part element=s0:getApprovedTermsResponse name=parameters/
/message
portType name=cvPortType
operation name=getApprovedTerms parameterOrder=parameters
input message=s0:getApprovedTerms/
output message=s0:getApprovedTermsResponse/
/operation
operation name=verifyTerm parameterOrder=parameters
input message=s0:verifyTerm/
output message=s0:verifyTermResponse/
/operation
/portType
binding name=cvServiceSoapBinding type=s0:cvPortType
s1:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
operation name=getApprovedTerms
s1:operation soapAction= style=document/
input
s1:body parts=parameters use=literal/
/input
output
s1:body parts=parameters use=literal/
/output
/operation
operation name=verifyTerm
s1:operation soapAction= style=document/
input
s1:body parts=parameters use=literal/
/input
output
s1:body parts=parameters use=literal/
/output
/operation
/binding
service name=cvService
port
Re: item element with xmlns=
Any chance you could check with the 2.0.4 release candidates available at: http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator/ There were definite issues with Exceptions not working correctly with qualified schemas in 2.0.3. They should (hopefully) be fixed there. Dan On Thursday 24 January 2008, Marco Piraccini wrote: I need to expose a service (java-first) with CXF with an exception (EchoComplexException ) that includes an array of object (of class EchoStruct). The service is setted with: anonymousWrapperType, qualifyWrapperSchema ad wrapped to true. The wsdl generated seems to be correct, with a wrapper EchoComplexException of the type: xs:complexType final=#all name=echoStructArray xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=item nillable=true type=tns:echoStruct/ /xs:sequence /xs:complexType The problem is that, on object deserialization, the EchoComplexException is serialized in: EchoComplexException xmlns=xxx ns2:reason xsi:type=echoStructArray xmlns=yyy xmlns:ns2=xxx xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; item xmlns= xmlns:ns4=yyy ns4:fieldBooleantrue/ns4:fieldBoolean /item /ns2:reason /EchoComplexException ...that's correct, except for the xmlns= item namespace. Of course the schema validation fails. Anyone meet the same problem? Marco. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: item element with xmlns=
Thank you Dan for your quick answer. I already tried with CXF-2.0.4 (RC) but the behaviour seems to be the same as the 2.0.3 version. Marco. Quoting Daniel Kulp [EMAIL PROTECTED]: Any chance you could check with the 2.0.4 release candidates available at: http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator/ There were definite issues with Exceptions not working correctly with qualified schemas in 2.0.3. They should (hopefully) be fixed there. Dan On Thursday 24 January 2008, Marco Piraccini wrote: I need to expose a service (java-first) with CXF with an exception (EchoComplexException ) that includes an array of object (of class EchoStruct). The service is setted with: anonymousWrapperType, qualifyWrapperSchema ad wrapped to true. The wsdl generated seems to be correct, with a wrapper EchoComplexException of the type: xs:complexType final=#all name=echoStructArray xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=item nillable=true type=tns:echoStruct/ /xs:sequence /xs:complexType The problem is that, on object deserialization, the EchoComplexException is serialized in: EchoComplexException xmlns=xxx ns2:reason xsi:type=echoStructArray xmlns=yyy xmlns:ns2=xxx xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; item xmlns= xmlns:ns4=yyy ns4:fieldBooleantrue/ns4:fieldBoolean /item /ns2:reason /EchoComplexException ...that's correct, except for the xmlns= item namespace. Of course the schema validation fails. Anyone meet the same problem? Marco. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
2.0.2 to 2.0.3 causes NoClassDefFoundError: ExtensionDeserializer
Hello All, As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because the below class could not be found. I'm using Maven for builds and tests, and am *not* bringing in every possible CXF dependency as defined here[1]. java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/extensions/ExtensionDeserializer Question: Does anyone know what dependency am I missing, such that this class can be found in 2.0.2 but *not* in 2.0.3? (Alternatively, it is possible that this class is never used in 2.0.2, hence why it works with that version.) Thanks, Glen [1] http://cwiki.apache.org/CXF20DOC/building-your-cxf-project-with-maven.html -- View this message in context: http://www.nabble.com/2.0.2-to-2.0.3-causes-NoClassDefFoundError%3A-ExtensionDeserializer-tp15069327p15069327.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: 2.0.2 to 2.0.3 causes NoClassDefFoundError: ExtensionDeserializer
Oops, forgot to mention, this is the exception that caused the class missing error: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.jaxws.EndpointImpl]: Constructor threw exception; nested exception is java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/extensions/ExtensionDeserializer Glen Glen Mazza wrote: Hello All, As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because the below class could not be found. I'm using Maven for builds and tests, and am *not* bringing in every possible CXF dependency as defined here[1]. java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/extensions/ExtensionDeserializer Question: Does anyone know what dependency am I missing, such that this class can be found in 2.0.2 but *not* in 2.0.3? (Alternatively, it is possible that this class is never used in 2.0.2, hence why it works with that version.) Thanks, Glen [1] http://cwiki.apache.org/CXF20DOC/building-your-cxf-project-with-maven.html -- View this message in context: http://www.nabble.com/2.0.2-to-2.0.3-causes-NoClassDefFoundError%3A-ExtensionDeserializer-tp15069327p15069348.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: 2.0.2 to 2.0.3 causes NoClassDefFoundError: ExtensionDeserializer
Looks to me as if you have a too-old XmlSchema jar file. On Thu, 2008-01-24 at 08:44 -0800, Glen Mazza wrote: Hello All, As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because the below class could not be found. I'm using Maven for builds and tests, and am *not* bringing in every possible CXF dependency as defined here[1]. java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/extensions/ExtensionDeserializer Question: Does anyone know what dependency am I missing, such that this class can be found in 2.0.2 but *not* in 2.0.3? (Alternatively, it is possible that this class is never used in 2.0.2, hence why it works with that version.) Thanks, Glen [1] http://cwiki.apache.org/CXF20DOC/building-your-cxf-project-with-maven.html
Re: 2.0.2 to 2.0.3 causes NoClassDefFoundError: ExtensionDeserializer
You need to update the version of XmlSchema.The version we used in 2.0.2 had too many bugs that we couldn't work around. In 2.0.3, it was updated to 1.3.2, which STILL has a bunch of bugs we cannot work around, :-( but it does fix a few others and does provide us an oportunity to work around a few others. We're trying to push to get a 1.3.3 released to fix some of the other issues, but they aren't being too helpful with that, which is frustrating. FYI: the ExtensionDeserializer dependency is to work around one of the bugs. The default extension deserializer loses most extensors (keeps only the last one) and treats namespace declarations as extensors as well. Thus, it loses things all over the place, especially with mtom schemas that throw xmime extensors on the base64 things.We created our own ExtenstionDeserializer that actually works correctly.1.3.3 SHOULD be fixed, at which point we can remove our version. Dan On Thursday 24 January 2008, Glen Mazza wrote: Hello All, As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because the below class could not be found. I'm using Maven for builds and tests, and am *not* bringing in every possible CXF dependency as defined here[1]. java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/extensions/ExtensionDeserializer Question: Does anyone know what dependency am I missing, such that this class can be found in 2.0.2 but *not* in 2.0.3? (Alternatively, it is possible that this class is never used in 2.0.2, hence why it works with that version.) Thanks, Glen [1] http://cwiki.apache.org/CXF20DOC/building-your-cxf-project-with-maven. html -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem
It's the JAX-WS spec (which our tools implement) found at:
http://jcp.org/en/jsr/detail?id=224
Specifically, it's section 2.3.1.2. The first table in there, item 5
says:
(v) The wrapper elements only contain child elements, they must not
contain other structures such as wildcards (element or attribute),
xsd:choice, substitution groups (element references are not permitted)
or attributes; furthermore, they must not be nillable.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Do you have the link to the document you are quoting?
I am reading the Basic Profile
(http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html) and can't
really find what you are mentioning.
Thanks, Ben
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 16:09
To: cxf-user@incubator.apache.org
Cc: Benjamin Coiffe
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation]
problem
According to the JAXWS spec, wrapper types are NOT allowed to contain
wildcards.The xs:any is considered a wildcard. Thus, it's not
unwrappable.
That said, wsld2java is still broken for this case as it's generating
a void return instead of a GetApprovedTermsResponse return . That's
really not good. Off to log a bug for that.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Hi,
The WSDL pasted at the end of this email contains two methods:
getApprovedTerms, verifyTerm. There signatures are very close, yet,
verifyItem is wrappable and getApprovedTerms isn't...Can somebody
please explain me why?
I am working with CXF 2.0.1 patched. I did update
TypeClassSerializer to fix a couple of bugs.
When I execute this code:
DynamicClientFactory dynamicClientFactory =
DynamicClientFactory.newInstance(bus);
Client client = dynamicClientFactory.createClient(wsdl);
ServiceInfo model =
client.getEndpoint().getService().getServiceInfos().get(0);
InterfaceInfo interfaceInfo = model.getInterface();
CollectionOperationInfo operationInfos =
interfaceInfo.getOperations();
for(OperationInfo operationInfo:operationInfos){
MessageInfo outputMessageInfo =
operationInfo.getInput();
MapQName,MessagePartInfo map =
outputMessageInfo.getMessagePartsMap();
for(EntryQName,MessagePartInfo entry :
map.entrySet()){
MessagePartInfo messagePartInfo =
entry.getValue();
if(messagePartInfo.getTypeClass() == null){
throw new Exception(Should not happened!!)
}
}
}
}
The Exception is unfortunately thrown:-( and should not be. I tried
to find a way to fix it myself but I am running out of ideas!
My patched TypeClassInitializer is the latest code from the source
repository.
Any Help would be really appreciated.
Thanks,
BEnjamin
?xml version='1.0' encoding='UTF-8'?
definitions name=cvServiceDefinitions
targetNamespace=http://sii.gri.roche.com;
xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
types
xs:schema attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://sii.gri.roche.com;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=getApprovedTerms
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getApprovedTermsResponse
xs:complexType
xs:sequence
xs:any/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=verifyTerm
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=termName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=verifyTermResponse
xs:complexType
xs:sequence
xs:element name=ReturnVerifyTerm type=xs:boolean/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/types
message name=verifyTerm
part element=s0:verifyTerm name=parameters/
/message
message name=verifyTermResponse
part element=s0:verifyTermResponse name=parameters/
/message
message name=getApprovedTerms
part
Re: 2.0.2 to 2.0.3 causes NoClassDefFoundError: ExtensionDeserializer
Glen, Depends. Mavens transitive dependency mechanisms is one of the worlds depest mysteries (and changes from version to version :-( ) Seriously, if you have two dependencies that depend on different versions of XmlSchema transitively, what version you get is completely dependent on where in your pom they are and what version of Maven you are using. (as well as what JVM you were using, Sun/IBM/OSX/etc...) With 2.0.7+, a new algorithm was put in place to try and normallize that a bit. With 2.0.7+, it uses the version closest to the root of the tree. Consider your pom as the root. If one dep depends on XmlSchema 1.2 2 levels of transitively deep, and other depends on 1.3.2 3 levels deep, you will get version 1.2. If the two are the same level deep, I think it grabs the version from the dep found first in your pom. By putting it explicitely in your pom, that's level 1 so that will be grabbed. With XmlSchema, it also gets complex cause they keep flipping groupId's. Some things depend on org.apache.ws.commons:XmlSchema and others depend on org.apache.ws.commons.schema:XmlSchema. To maven, they are completely different and you can end up with both on the classpath and the which one is first could be relatively random. Dan On Thursday 24 January 2008, Glen Mazza wrote: Placing this in the pom seems to allow it to work now (but it raising another problem I'll start hunting down next): dependency groupIdorg.apache.ws.commons.schema/groupId artifactIdXmlSchema/artifactId version1.3.2/version /dependency But adding this dependency to my pom.xml raises the question: why would I need to explicitly include this, wouldn't it be normally detected by Maven via the transitive dependencies required by CXF? Thanks, Glen dkulp wrote: You need to update the version of XmlSchema.The version we used in 2.0.2 had too many bugs that we couldn't work around. In 2.0.3, it was updated to 1.3.2, which STILL has a bunch of bugs we cannot work around, :-( but it does fix a few others and does provide us an oportunity to work around a few others. We're trying to push to get a 1.3.3 released to fix some of the other issues, but they aren't being too helpful with that, which is frustrating. FYI: the ExtensionDeserializer dependency is to work around one of the bugs. The default extension deserializer loses most extensors (keeps only the last one) and treats namespace declarations as extensors as well. Thus, it loses things all over the place, especially with mtom schemas that throw xmime extensors on the base64 things.We created our own ExtenstionDeserializer that actually works correctly.1.3.3 SHOULD be fixed, at which point we can remove our version. Dan On Thursday 24 January 2008, Glen Mazza wrote: Hello All, As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because the below class could not be found. I'm using Maven for builds and tests, and am *not* bringing in every possible CXF dependency as defined here[1]. java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/extensions/ExtensionDeserializer Question: Does anyone know what dependency am I missing, such that this class can be found in 2.0.2 but *not* in 2.0.3? (Alternatively, it is possible that this class is never used in 2.0.2, hence why it works with that version.) Thanks, Glen [1] http://cwiki.apache.org/CXF20DOC/building-your-cxf-project-with-mav en. html -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem
Ben,
This won't do what you think. The DEFAULT is to enable wrapper style.
The customization you are referring two will allow all operations to be
generated in the bare style. In your case, the verifyTerm would be
changed to match the other item:
VerifyTermResponse verifyTerm(VerifyTermRequest req);
If the schema does not match the rules in 2.3.1.2, there is nothing that
can be done to get it unwrapped.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Ok, thanks, I found it. An I found this as well:
Conformance (Disabling wrapper style): An implementation MUST support
use of the jaxws:enable-
WrapperStyle binding declaration to enable or disable the wrapper
style mapping of operations (see section
8.7.3).
How can I get this working for the dynamic client?
Thanks,
Ben
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 17:05
To: cxf-user@incubator.apache.org
Cc: Benjamin Coiffe
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation]
problem
It's the JAX-WS spec (which our tools implement) found at:
http://jcp.org/en/jsr/detail?id=224
Specifically, it's section 2.3.1.2. The first table in there, item 5
says:
(v) The wrapper elements only contain child elements, they must not
contain other structures such as wildcards (element or attribute),
xsd:choice, substitution groups (element references are not permitted)
or attributes; furthermore, they must not be nillable.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Do you have the link to the document you are quoting?
I am reading the Basic Profile
(http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html) and can't
really find what you are mentioning.
Thanks, Ben
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 16:09
To: cxf-user@incubator.apache.org
Cc: Benjamin Coiffe
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped
operation] problem
According to the JAXWS spec, wrapper types are NOT allowed to
contain wildcards.The xs:any is considered a wildcard. Thus,
it's not unwrappable.
That said, wsld2java is still broken for this case as it's
generating a void return instead of a GetApprovedTermsResponse
return . That's really not good. Off to log a bug for that.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Hi,
The WSDL pasted at the end of this email contains two methods:
getApprovedTerms, verifyTerm. There signatures are very close,
yet, verifyItem is wrappable and getApprovedTerms isn't...Can
somebody please explain me why?
I am working with CXF 2.0.1 patched. I did update
TypeClassSerializer to fix a couple of bugs.
When I execute this code:
DynamicClientFactory dynamicClientFactory =
DynamicClientFactory.newInstance(bus);
Client client = dynamicClientFactory.createClient(wsdl);
ServiceInfo model =
client.getEndpoint().getService().getServiceInfos().get(0);
InterfaceInfo interfaceInfo = model.getInterface();
CollectionOperationInfo operationInfos =
interfaceInfo.getOperations();
for(OperationInfo operationInfo:operationInfos){
MessageInfo outputMessageInfo =
operationInfo.getInput();
MapQName,MessagePartInfo map =
outputMessageInfo.getMessagePartsMap();
for(EntryQName,MessagePartInfo entry :
map.entrySet()){
MessagePartInfo messagePartInfo =
entry.getValue();
if(messagePartInfo.getTypeClass() == null){
throw new Exception(Should not
happened!!)
}
}
}
}
The Exception is unfortunately thrown:-( and should not be. I
tried to find a way to fix it myself but I am running out of
ideas!
My patched TypeClassInitializer is the latest code from the source
repository.
Any Help would be really appreciated.
Thanks,
BEnjamin
?xml version='1.0' encoding='UTF-8'?
definitions name=cvServiceDefinitions
targetNamespace=http://sii.gri.roche.com;
xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
types
xs:schema attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://sii.gri.roche.com;
xmlns:s0=http://sii.gri.roche.com;
xmlns:s1=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=getApprovedTerms
xs:complexType
xs:sequence
xs:element name=domainName type=xs:string/
xs:element name=appName type=xs:string/
xs:element name=viewName type=xs:string/
/xs:sequence
RE: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem
Does not sound to bad...I guess the customization
jaxws:enableWrapperStyle would be in an XML file somewhere in the cxf
JAR.
My final purpose here is to get this soap message:
(Generated in SOAP UI)
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:sii=http://sii.gri.roche.com;
soapenv:Header/
soapenv:Body
sii:verifyTerm
sii:domainNamerandom/sii:domainName
sii:termNameyes/sii:termName
sii:appNamej/sii:appName
sii:viewNameNarrower/sii:viewName
/sii:verifyTerm
/soapenv:Body
/soapenv:Envelope
Instead of that:
(Generated by CXF)
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:sii=http://sii.gri.roche.com;
soapenv:Header/
soapenv:Body
sii:domainNamerandom/sii:domainName
sii:termNameyes/sii:termName
sii:appNamej/sii:appName
sii:viewNameNarrower/sii:viewName
/soapenv:Body
/soapenv:Envelope
The reason behind this is that a Web Service deployed on Web Logic
replied me a weird error message (htmlHello /html) when I send
the cxf message and not the soapui one.
Thanks,
Benjamin
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 17:43
To: Benjamin Coiffe
Cc: cxf-user@incubator.apache.org
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation]
problem
Ben,
This won't do what you think. The DEFAULT is to enable wrapper style.
The customization you are referring two will allow all operations to be
generated in the bare style. In your case, the verifyTerm would be
changed to match the other item:
VerifyTermResponse verifyTerm(VerifyTermRequest req);
If the schema does not match the rules in 2.3.1.2, there is nothing that
can be done to get it unwrapped.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Ok, thanks, I found it. An I found this as well:
Conformance (Disabling wrapper style): An implementation MUST support
use of the jaxws:enable-
WrapperStyle binding declaration to enable or disable the wrapper
style mapping of operations (see section
8.7.3).
How can I get this working for the dynamic client?
Thanks,
Ben
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 17:05
To: cxf-user@incubator.apache.org
Cc: Benjamin Coiffe
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation]
problem
It's the JAX-WS spec (which our tools implement) found at:
http://jcp.org/en/jsr/detail?id=224
Specifically, it's section 2.3.1.2. The first table in there, item 5
says:
(v) The wrapper elements only contain child elements, they must not
contain other structures such as wildcards (element or attribute),
xsd:choice, substitution groups (element references are not permitted)
or attributes; furthermore, they must not be nillable.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Do you have the link to the document you are quoting?
I am reading the Basic Profile
(http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html) and can't
really find what you are mentioning.
Thanks, Ben
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 16:09
To: cxf-user@incubator.apache.org
Cc: Benjamin Coiffe
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped
operation] problem
According to the JAXWS spec, wrapper types are NOT allowed to
contain wildcards.The xs:any is considered a wildcard. Thus,
it's not unwrappable.
That said, wsld2java is still broken for this case as it's
generating a void return instead of a GetApprovedTermsResponse
return . That's really not good. Off to log a bug for that.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Hi,
The WSDL pasted at the end of this email contains two methods:
getApprovedTerms, verifyTerm. There signatures are very close,
yet, verifyItem is wrappable and getApprovedTerms isn't...Can
somebody please explain me why?
I am working with CXF 2.0.1 patched. I did update
TypeClassSerializer to fix a couple of bugs.
When I execute this code:
DynamicClientFactory dynamicClientFactory =
DynamicClientFactory.newInstance(bus);
Client client = dynamicClientFactory.createClient(wsdl);
ServiceInfo model =
client.getEndpoint().getService().getServiceInfos().get(0);
InterfaceInfo interfaceInfo = model.getInterface();
CollectionOperationInfo operationInfos =
interfaceInfo.getOperations();
for(OperationInfo operationInfo:operationInfos){
MessageInfo outputMessageInfo =
operationInfo.getInput();
MapQName,MessagePartInfo map =
outputMessageInfo.getMessagePartsMap();
for(EntryQName,MessagePartInfo entry :
map.entrySet()){
MessagePartInfo
WebLogic, AquaLogic and CXF
Hi, I would like to know if any of you had a successful integration between these technologies. Basically, calling CXF Web Services from an EBA platform and calling EBA web Services from CXF? Any answer (link to a blog, anything) appreciated, Thanks Benjamin Coiffe
Re: @ProduceMime support
I just had a chance to look a little closer at this. It appears that
when we use the CXF servlet transport the mime types for the Accept:
Content-Type: headers are not being propagated into the jax-rs
runtime. I'm currently investigating why this is the case.
BTW I was mistaken on the ProduceMime thing yesterday, you can specify
multiple mime types in the @ProduceMime annotation, you simply need to
encose the array of strings in curly braces like the following:
@ProduceMime({application/xml, application/json})
duh! ;)
--Frank
On Wed, 2008-01-23 at 14:33 -0500, Frank Lynch wrote:
I'm seeing the same thing here, no matter what I do the runtime seems to
want to dispatch the call to the method annotated application/json. I
also noted that it isn't possible to annotate a single method with
multiple mime types. i.e. per the dec4th jsr311 draft it should be
possible t0 annotate a method with the following:
@ProduceMime(application/xml, application/json)
alas, this doesn't appear to be supported in cxf yet. I guess we should
log JIRA's for these.
--Frank
On Wed, 2008-01-23 at 07:12 -0800, brmaguir wrote:
Hi,
Does CXF support the JSR311 @ProduceMime annotation fully? Here's the code:
import com.sun.ws.rest.api.ConsumeMime;
import com.sun.ws.rest.api.HttpMethod;
import com.sun.ws.rest.api.ProduceMime;
import com.sun.ws.rest.api.UriTemplate;
@UriTemplate(/sampleservlet)
public class SampleServlet {
@HttpMethod(PUT)
@ConsumeMime(text/plain)
@ProduceMime(application/xml)
public void getXML() {
System.out.println(### Handle PUT for sampleservlet: XML ###);
}
@HttpMethod(PUT)
@ConsumeMime(text/plain)
@ProduceMime(application/json)
public void getJSON() {
System.out.println(### Handle PUT for sampleservlet: JSON
###);
}
}
When the client specifies the Accept parameter in the http header as
application/json or application/xml I would expect the corresponding method
to be called according to the @ProduceMime specified before the method. Is
this supported? It doesn't seem to be working as expected for me.
Thanks in advance.
How do you force CXF to use SOAP 1.0?
I reread my own posting and realized that the problem is not in the detail element, but in the faultcode element which contains an arbitrary string, ServerFaultCode, not a QName. The exception says: No NamespaceURI, SOAP requires faultcode content to be a QName I believe the faultcode element and QName requirement was introduced with SOAP 1.1. Can CXF be forced to validate using SOAP 1.0? If so, how? What are the ramifications? I checked the schemas specified in the WSDL document and they appear to be SOAP 1.0. Why didn't CXF automatically use same SOAP 1.0 schemas as were defined in the WSDL document? The VMWare/Axis web service appears to be placing the qualified fault element in the contents of the detail element. How do I get around this? Is there a way (interceptor?) to fix the XML prior to being parsed? This would involve moving and translating the detail element contents to a QName stored in the contents of the faultcode element. If I can force CXF to SOAP 1.0, will it still know to generate an exception using the QName in the detail element? Or is where I would use a custom Interceptor and specify it in the inFaultInterceptors of the CXF Spring configuration. Has anyone already written an Axis to CXF fault translator? Thank you for your help. Thank you. Fred Frederick N. Brier wrote: I am writing a client to a VMWare management web service. In working with the API, I made a mistake and a SOAP fault was thrown. That is not the problem. Instead of an WSDL generated exception class being thrown, I got what appears to be a validation error during parsing of the SOAP fault. Below is the SOAP fault message that caused the exception and below that is the stack trace. SOAP fault message: ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodeServerFaultCode/faultcode faultstringspecSet/faultstring detail InvalidRequestFault xmlns=urn:vim2 xsi:type=InvalidRequest/ /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope Here is the stack trace: Jan 23, 2008 4:56:09 PM com.sun.xml.messaging.saaj.soap.impl.FaultImpl setFaultCode SEVERE: SAAJ0140: No NamespaceURI, SOAP requires faultcode content to be a QName java.lang.reflect.UndeclaredThrowableException at $Proxy32.retrieveProperties(Unknown Source) at com.reflexsecurity.vmware.SampleClient.retrieveProperties(SampleClient.java:216) at com.reflexsecurity.vmware.SampleClient.main(SampleClient.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: No NamespaceURI, SOAP requires faultcode content to be a QName at com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:101) at com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:138) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:155) ... 8 more Failed to retrieve properties. 2008-01-23 16:56:09,872 ERROR main SampleClient.main:96] Failed to retrieve properties java.lang.reflect.UndeclaredThrowableException at $Proxy32.retrieveProperties(Unknown Source) at com.reflexsecurity.vmware.SampleClient.retrieveProperties(SampleClient.java:216) at com.reflexsecurity.vmware.SampleClient.main(SampleClient.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: No NamespaceURI, SOAP requires faultcode content to be a QName at com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:101) at com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:138) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:155) ... 8 more Process finished with exit code 0
Problem with java mail - suspect geronimo-javamail_1.4_spec-1.0-M1.jar is the problem
I'm using CXF 2.0.3-incubator with Maven 2. I get this exception when I try to use java mail from within my web service (running on Tomcat 5.5.16) :- javax.mail.NoSuchProviderException: Provider class does not have a constructor(Session, URLName): protocol=smtp; type= [EMAIL PROTECTED]; class=com.sun.mail.smtp.SMTPTransport; vendor=Sun Microsystems, Inc at javax.mail.Session.getService(Session.java:485) at javax.mail.Session.getTransport(Session.java:379) at javax.mail.Session.getTransport(Session.java:339) at com.wearegt.messenger.transports.SMTPSend.doSend(SMTPSend.java :64) at com.wearegt.messenger.transports.SMTPSend.run(SMTPSend.java:99) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NoSuchMethodException: com.sun.mail.smtp.SMTPTransport .init(javax.mail.Session, javax.mail.URLName) at java.lang.Class.getConstructor0(Class.java:2647) at java.lang.Class.getConstructor(Class.java:1629) at javax.mail.Session.getService(Session.java:480) ... 5 more Exception in thread Thread-28 java.lang.RuntimeException: Error sending email at com.wearegt.messenger.transports.SMTPSend.doSend(SMTPSend.java :76) at com.wearegt.messenger.transports.SMTPSend.run(SMTPSend.java:99) at java.lang.Thread.run(Thread.java:595) Caused by: javax.mail.NoSuchProviderException: Provider class does not have a constructor(Session, URLName): protocol=smtp; type= [EMAIL PROTECTED]; class=com.sun.mail.smtp.SMTPTransport; vendor=Sun Microsystems, Inc at javax.mail.Session.getService(Session.java:485) at javax.mail.Session.getTransport(Session.java:379) at javax.mail.Session.getTransport(Session.java:339) at com.wearegt.messenger.transports.SMTPSend.doSend(SMTPSend.java :64) ... 2 more Caused by: java.lang.NoSuchMethodException: com.sun.mail.smtp.SMTPTransport .init(javax.mail.Session, javax.mail.URLName) at java.lang.Class.getConstructor0(Class.java:2647) at java.lang.Class.getConstructor(Class.java:1629) at javax.mail.Session.getService(Session.java:480) ... 5 more Having searched on the web, it appears this indicates that there are 2 implementations of java mail on the classpath. Tomcat has the Sun mail.jaras expected, but having run a mvn site it seems I have a geronimo-javamail_1.4_spec-1.0-M1.jar on my classpath. Does anyone which if any CXF pom.xml may be pulling this in, so I can exclude it ? thanks, Deepak
support.JaxWsServiceFactoryBean as factory for multiple endpoints
hi, in http://cwiki.apache.org/CXF20DOC/aegis-databinding.html it is suggested to use org.apache.cxf.aegis.databinding.AegisDatabinding as factory bean for endpoints. The described syntax implies the use of a single factory bean for multiple endpoints, whereas this does not work. Is this a known issue ? When using the same factory for more than one endpoint: jaxws:endpoint id=my_service_endpoint implementor=#my-service address=/MyIndex jaxws:serviceFactory ref bean='jaxws-and-aegis-service-factory' / /jaxws:serviceFactory /jaxws:endpoint cfx delegates methods of one endpoint to another, trying to invoke a Method on an target bean which doesn't own it. the workaround is : jaxws:endpoint id=my_service_endpoint implementor=#my-service address=/MyIndex jaxws:serviceFactory bean class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean property name=dataBinding ref=aegisBean/ property name=serviceConfigurations list bean class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/ bean class=org.apache.cxf.aegis.databinding.AegisServiceConfiguration/ bean class=org.apache.cxf.service.factory.DefaultServiceConfiguration/ /list /property /bean /jaxws:serviceFactory /jaxws:endpoint Chears, Ron
Re: support.JaxWsServiceFactoryBean as factory for multiple endpoints
sorry, the factory class is ofcause not org.apache.cxf.aegis.databinding.AegisDatabinding but org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean Cheers, Ron Ron Piterman wrote: hi, in http://cwiki.apache.org/CXF20DOC/aegis-databinding.html it is suggested to use org.apache.cxf.aegis.databinding.AegisDatabinding as factory bean for endpoints. The described syntax implies the use of a single factory bean for multiple endpoints, whereas this does not work. Is this a known issue ? When using the same factory for more than one endpoint: jaxws:endpoint id=my_service_endpoint implementor=#my-service address=/MyIndex jaxws:serviceFactory ref bean='jaxws-and-aegis-service-factory' / /jaxws:serviceFactory /jaxws:endpoint cfx delegates methods of one endpoint to another, trying to invoke a Method on an target bean which doesn't own it. the workaround is : jaxws:endpoint id=my_service_endpoint implementor=#my-service address=/MyIndex jaxws:serviceFactory bean class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean property name=dataBinding ref=aegisBean/ property name=serviceConfigurations list bean class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/ bean class=org.apache.cxf.aegis.databinding.AegisServiceConfiguration/ bean class=org.apache.cxf.service.factory.DefaultServiceConfiguration/ /list /property /bean /jaxws:serviceFactory /jaxws:endpoint Chears, Ron
Re: How do you force CXF to use SOAP 1.0?
Benson Margulies wrote: On Thu, 2008-01-24 at 13:05 -0500, Frederick N. Brier wrote: I reread my own posting and realized that the problem is not in the detail element, but in the faultcode element which contains an arbitrary string, ServerFaultCode, not a QName. The exception says: No NamespaceURI, SOAP requires faultcode content to be a QName I believe the faultcode element and QName requirement was introduced with SOAP 1.1. Can CXF be forced to validate using SOAP 1.0? If so, how? What are the ramifications? I checked the schemas specified in the WSDL document and they appear to be SOAP 1.0. Why didn't CXF automatically use same SOAP 1.0 schemas as were defined in the WSDL document? The errors comes out of the SAAJ component, doesn't it? Yes.
RE: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem
Cheers Daniel, But I read that CXF-927 on your jira. And I am thinking that if I do that in the wsdl: operation name=verifyTerm parameterOrder=parameters jaxws:bindings xmlns:jaxws=http://java.sun.com/xml/ns/jaxws; jaxws:enableWrapperStylefalse/jaxws:enableWrapperStyle /jaxws:bindings input message=s0:verifyTerm/ output message=s0:verifyTermResponse/ /operation /portType I could deactivate the Wrapper mode for the method verifyTerm. Then, in WSDLServiceBuilder.checkedWrapped, I can check for the tag in the wsdl (xmlschema) and that would do the trick ( it does exactly what I want - tested in debug mode). And I respect the jax-ws specification, doesn't it? (My main concern is to respect that) Fyi, I have no problem with the getApprovedTerms operation. So I would avoid updating for the moment :). Thanks again, Benjamin -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: 24 January 2008 18:48 To: cxf-user@incubator.apache.org Cc: Benjamin Coiffe Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem Honestly, I think this was a bug in 2.0.1 that was fixed in 2.0.2 (or .3). I HIGHLY suggest you update to 2.0.3 and check again. Actually, you could try the 2.0.4 release candidates that we are voting on: http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator/ OK. I dug into some code a bit and figured out the problem with the method generated for the getApprovedTerms method.It's the parameterOrder attribute. It's confusing the BARE code generator. If you could remove that, it should generate a proper (and usable) method. I attached an updated wsdl that actually will work with wsdl2java to generate a usable, completely BARE style client. That all said, I just realized that you are using the Dynamic client. That's JAXB only and doesn't really deal with the jaxws extensions at all to figure out if it should be bare or wrapped. :-( In that case, I DEFINITELY recommend checking out 2.0.4. The Client object in 2.0.4 has new invokeWrapped methods that can be used to ALWAYS use the wrapper objects even if the normal code generators would have unwrapped it. Like: VerifyTerm vt = new VerifyTerm(); vt.set.(); VerifyTermResponse vtr = client.invokeWrapped(verifyTerm, vt); Dan On Thursday 24 January 2008, Benjamin Coiffe wrote: Does not sound to bad...I guess the customization jaxws:enableWrapperStyle would be in an XML file somewhere in the cxf JAR. My final purpose here is to get this soap message: (Generated in SOAP UI) soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:sii=http://sii.gri.roche.com; soapenv:Header/ soapenv:Body sii:verifyTerm sii:domainNamerandom/sii:domainName sii:termNameyes/sii:termName sii:appNamej/sii:appName sii:viewNameNarrower/sii:viewName /sii:verifyTerm /soapenv:Body /soapenv:Envelope Instead of that: (Generated by CXF) soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:sii=http://sii.gri.roche.com; soapenv:Header/ soapenv:Body sii:domainNamerandom/sii:domainName sii:termNameyes/sii:termName sii:appNamej/sii:appName sii:viewNameNarrower/sii:viewName /soapenv:Body /soapenv:Envelope The reason behind this is that a Web Service deployed on Web Logic replied me a weird error message (htmlHello /html) when I send the cxf message and not the soapui one. Thanks, Benjamin -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: 24 January 2008 17:43 To: Benjamin Coiffe Cc: cxf-user@incubator.apache.org Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem Ben, This won't do what you think. The DEFAULT is to enable wrapper style. The customization you are referring two will allow all operations to be generated in the bare style. In your case, the verifyTerm would be changed to match the other item: VerifyTermResponse verifyTerm(VerifyTermRequest req); If the schema does not match the rules in 2.3.1.2, there is nothing that can be done to get it unwrapped. Dan On Thursday 24 January 2008, Benjamin Coiffe wrote: Ok, thanks, I found it. An I found this as well: Conformance (Disabling wrapper style): An implementation MUST support use of the jaxws:enable- WrapperStyle binding declaration to enable or disable the wrapper style mapping of operations (see section 8.7.3). How can I get this working for the dynamic client? Thanks, Ben -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: 24 January 2008 17:05 To: cxf-user@incubator.apache.org Cc: Benjamin Coiffe Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem It's the JAX-WS spec (which our tools implement) found at:
Re: support.JaxWsServiceFactoryBean as factory for multiple endpoints
On Thursday 24 January 2008, Benson Margulies wrote: On Thu, 2008-01-24 at 13:54 -0500, Daniel Kulp wrote: Yea, that definitely won't work. The service factories record way to much state specific to that endpoint. That said, you MAY be able to get it to work by doing: bean singleton=false id='jaxws-and-aegis-service-factory' class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean That is, scope='prototype'. This works in a live app of mine. Listen to him, not me. I have no clue what I'm talking about... :-) -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [Dynamic Client, TypeClassInitializer, Wrapped operation] problem
Benjamin,
That would work for wsdl2java generated clients, but not for the
DynamicClient. The DynamicClient thing you are using doesn't do any
JAX-WS extensor processing or anything like that. No matter what you
do, verifyTerm will be unwrapped, the other bare.
Now, that all said, there is another interesting workaround. I see from
your code below that you found out how to use the OperationInfo objects.
For all unwrapped operations, there is a bare or wrapped version. Thus,
you can find the unwrapped operationinfo and pass that to the invoke
method that takes the OperationInfo instead of the default unwrapped
version that is chosen if you pass in the string name of the operation.
I think it would be something like:
operationInfos = client.getEndpoint().getBinding()
.getBindingInfo().getOperations();
BindingOperationInfo opToCall = null;
for(BindingOperationInfo oi: operationInfos) {
if (oi.getName().equals(opName)) {
opToCall = oi;
}
}
if (opToCall.isUnwrapped()) {
opToCall = opToCall.getWrappedOperation();
}
client.invoke(opToCall, param);
That actually should work for all methods if you want to always use the
wrapped form.
That all said, I still suggest upgrading to 2.0.3 and/or 2.0.4.
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Cheers Daniel,
But I read that CXF-927 on your jira. And I am thinking that if I do
that in the wsdl:
operation name=verifyTerm parameterOrder=parameters
jaxws:bindings xmlns:jaxws=http://java.sun.com/xml/ns/jaxws;
jaxws:enableWrapperStylefalse/jaxws:enableWrapperStyle
/jaxws:bindings
input message=s0:verifyTerm/
output message=s0:verifyTermResponse/
/operation
/portType
I could deactivate the Wrapper mode for the method verifyTerm.
Then, in WSDLServiceBuilder.checkedWrapped, I can check for the tag in
the wsdl (xmlschema) and that would do the trick ( it does exactly
what I want - tested in debug mode). And I respect the jax-ws
specification, doesn't it? (My main concern is to respect that)
Fyi, I have no problem with the getApprovedTerms operation. So I would
avoid updating for the moment :).
Thanks again,
Benjamin
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008 18:48
To: cxf-user@incubator.apache.org
Cc: Benjamin Coiffe
Subject: Re: [Dynamic Client, TypeClassInitializer, Wrapped operation]
problem
Honestly, I think this was a bug in 2.0.1 that was fixed in 2.0.2
(or .3). I HIGHLY suggest you update to 2.0.3 and check again.
Actually, you could try the 2.0.4 release candidates that we are
voting on:
http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator/
OK. I dug into some code a bit and figured out the problem with the
method generated for the getApprovedTerms method.It's the
parameterOrder attribute. It's confusing the BARE code generator.
If
you could remove that, it should generate a proper (and usable)
method.
I attached an updated wsdl that actually will work with wsdl2java to
generate a usable, completely BARE style client.
That all said, I just realized that you are using the Dynamic client.
That's JAXB only and doesn't really deal with the jaxws extensions at
all to figure out if it should be bare or wrapped. :-( In that
case, I DEFINITELY recommend checking out 2.0.4. The Client object
in 2.0.4 has new invokeWrapped methods that can be used to ALWAYS use
the wrapper objects even if the normal code generators would have
unwrapped it.
Like:
VerifyTerm vt = new VerifyTerm();
vt.set.();
VerifyTermResponse vtr = client.invokeWrapped(verifyTerm, vt);
Dan
On Thursday 24 January 2008, Benjamin Coiffe wrote:
Does not sound to bad...I guess the customization
jaxws:enableWrapperStyle would be in an XML file somewhere in the
cxf JAR.
My final purpose here is to get this soap message:
(Generated in SOAP UI)
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:sii=http://sii.gri.roche.com;
soapenv:Header/
soapenv:Body
sii:verifyTerm
sii:domainNamerandom/sii:domainName
sii:termNameyes/sii:termName
sii:appNamej/sii:appName
sii:viewNameNarrower/sii:viewName
/sii:verifyTerm
/soapenv:Body
/soapenv:Envelope
Instead of that:
(Generated by CXF)
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:sii=http://sii.gri.roche.com;
soapenv:Header/
soapenv:Body
sii:domainNamerandom/sii:domainName
sii:termNameyes/sii:termName
sii:appNamej/sii:appName
sii:viewNameNarrower/sii:viewName
/soapenv:Body
/soapenv:Envelope
The reason behind this is that a Web Service deployed on Web Logic
replied me a weird error message (htmlHello /html) when I
send the cxf message and not the soapui one.
Thanks,
Benjamin
-Original
Re: @ProduceMime support
I've create a JIRA for this issue at:
https://issues.apache.org/jira/browse/CXF-1405
I've also attached a patch to the JIRA which should resolve this for
you.
best regards,
--Frank
On Thu, 2008-01-24 at 12:58 -0500, Frank Lynch wrote:
I just had a chance to look a little closer at this. It appears that
when we use the CXF servlet transport the mime types for the Accept:
Content-Type: headers are not being propagated into the jax-rs
runtime. I'm currently investigating why this is the case.
BTW I was mistaken on the ProduceMime thing yesterday, you can specify
multiple mime types in the @ProduceMime annotation, you simply need to
encose the array of strings in curly braces like the following:
@ProduceMime({application/xml, application/json})
duh! ;)
--Frank
On Wed, 2008-01-23 at 14:33 -0500, Frank Lynch wrote:
I'm seeing the same thing here, no matter what I do the runtime seems to
want to dispatch the call to the method annotated application/json. I
also noted that it isn't possible to annotate a single method with
multiple mime types. i.e. per the dec4th jsr311 draft it should be
possible t0 annotate a method with the following:
@ProduceMime(application/xml, application/json)
alas, this doesn't appear to be supported in cxf yet. I guess we should
log JIRA's for these.
--Frank
On Wed, 2008-01-23 at 07:12 -0800, brmaguir wrote:
Hi,
Does CXF support the JSR311 @ProduceMime annotation fully? Here's the
code:
import com.sun.ws.rest.api.ConsumeMime;
import com.sun.ws.rest.api.HttpMethod;
import com.sun.ws.rest.api.ProduceMime;
import com.sun.ws.rest.api.UriTemplate;
@UriTemplate(/sampleservlet)
public class SampleServlet {
@HttpMethod(PUT)
@ConsumeMime(text/plain)
@ProduceMime(application/xml)
public void getXML() {
System.out.println(### Handle PUT for sampleservlet: XML ###);
}
@HttpMethod(PUT)
@ConsumeMime(text/plain)
@ProduceMime(application/json)
public void getJSON() {
System.out.println(### Handle PUT for sampleservlet: JSON
###);
}
}
When the client specifies the Accept parameter in the http header as
application/json or application/xml I would expect the corresponding
method
to be called according to the @ProduceMime specified before the method. Is
this supported? It doesn't seem to be working as expected for me.
Thanks in advance.
Under what circumstances does a CXF server read the WSDL file?
Hi there, I was playing around with some JAXWS services in CXF, and am wondering under what circumstances does a service actually go and read the WSDL file. In the SOAP/HTTP case it doesn't have to read from the WSDL file - all the information should be implicit from the annotations in the WSDL code so there's no need to read from the WSDL at all. However, if the JMS transport is being used then the WSDL file has to be read, because the service endpoint information is only found in the WSDL. I note that in the jms_queue demo the service explicitly uses the wsdlLocation attribute to point to the WSDL file. So, is the rule go to the WSDL only when you need to?, or, is the rule go to the WSDL only if the wsdlLocation has been specified in an annotation? Thanks, Ade. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Under what circumstances does a CXF server read the WSDL file?
The latter. If there is a wsdlLocation attribute, we always grab the wsdl. Additionaly, if the config (like spring config) specifies a wsdl location, we use it. Dan On Thursday 24 January 2008, Trenaman, Adrian wrote: Hi there, I was playing around with some JAXWS services in CXF, and am wondering under what circumstances does a service actually go and read the WSDL file. In the SOAP/HTTP case it doesn't have to read from the WSDL file - all the information should be implicit from the annotations in the WSDL code so there's no need to read from the WSDL at all. However, if the JMS transport is being used then the WSDL file has to be read, because the service endpoint information is only found in the WSDL. I note that in the jms_queue demo the service explicitly uses the wsdlLocation attribute to point to the WSDL file. So, is the rule go to the WSDL only when you need to?, or, is the rule go to the WSDL only if the wsdlLocation has been specified in an annotation? Thanks, Ade. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Problem: When invoke HttpServletRequet.getRemoteAddr(), it return the old client IP...
Dears:
I put some code into a web method to get client IP.
ex:
public boolean recordIP() {
try {
debugInfo.append( ).append(
((HttpServletRequest) ctx
.get(AbstractHTTPDestination.HTTP_REQUEST))
.getRemoteAddr());
return true;
} catch (Exception e) {
return false;
}
}
When the first client from IP1 call this method, it record the IP1 address.
No problem.
But then the second client from IP2 call this method, it SOMETIMES still
record the IP1 address (the old one).
This situation might occur in some condition (ex: after browsing some other
jsp page in other web ap in the same web instance). I am not sure what
condition may cause this problem exactly.
Has anyone got this problem before? Thanks!
My AP configuration: Apache 2.2.24+Tomcat5.5.20(using AJP13
connector)+CXF2.0.1
--
View this message in context:
http://www.nabble.com/Problem%3A-When-invoke-HttpServletRequet.getRemoteAddr%28%29%2C-it-return-the-old-client-IP...-tp15082583p15082583.html
Sent from the cxf-user mailing list archive at Nabble.com.
