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 element=s0
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
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: http://jcp.org/en/jsr
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 Message
