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:enableWrapperStyle>false</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:domainName>random</sii:domainName>
> > <sii:termName>yes</sii:termName>
> > <sii:appName>j</sii:appName>
> > <sii:viewName>Narrower</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:domainName>random</sii:domainName>
> > <sii:termName>yes</sii:termName>
> > <sii:appName>j</sii:appName>
> > <sii:viewName>Narrower</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 (<html>Hello.... </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();
> > > > >
> > > > > Collection<OperationInfo> operationInfos =
> > > > > interfaceInfo.getOperations();
> > > > >
> > > > > for(OperationInfo operationInfo:operationInfos){
> > > > >
> > > > > MessageInfo outputMessageInfo =
> > > > > operationInfo.getInput();
> > > > >
> > > > > Map<QName,MessagePartInfo> map =
> > > > > outputMessageInfo.getMessagePartsMap();
> > > > >
> > > > > for(Entry<QName,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,
> > > > >
> > > > >
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
