This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In the WSDL Editor wizard, the binding type needs to be defaulted to 'Document'. I don't think this is specified in any specs, but I spoke to Alex and he said that he would choose Document to be the default. Either way, it should be consistent whenever you use the wizard. Sherry noted that sometimes the default is Document and sometimes it is RPC. So if the decision is to keep it defaulted to RPC, we need to ensure that it is ALWAYS defaulted to RPC
The default is now always rpc literal. The reason is that by default one part is added to porttype configuration step in wizard and there type is xsd:string or basically could be any built in type for that matter and according to basic profile if a part is of schema type ( simple/complex) then document literal is invalid as it works with only part of schema element whereas rpc literal works with type only, not element. Also I have tested with following: ejb implementing rpc literal wsdl generated by wizard and invoke that from bpel and bpel implementing rpc literal wsdl generated by wizard and both works.
on 060922 coke build
I'm concerned about the default in the WSDL editor being rcp/literal. Doc/literal is best practice and the default for all EJBs is doc/literal. Why do we want to encourage users to build non-best-practice WSDLs? I disagree that consistency necessarily is the right thing here--if there are cases where rpc/literal is necessary, that's a reasonable deviation from doc/literal, but in my opinion we should not change the default to non-standard value. Comments?
I just want to clarify the impact on the mapper. If an rpc/encoded binding is used the SOAP message the operation name (with targetNamespace of WSDL) and a element for each part. In addition, to the message and part information the namespaces from the given schema are not used. Thus namespace based assignment information (such as XPath queries would be different between the two approaches). I just want to ensure that this is being handled.
Todd, This is in wizard not editor. First rpc/literal is also WS-I basic profile compliant so it is not non standard. The reason we made rpc\literal default in wizard is to make it easy for user to create a wsdl by just clicking next/next on wizard. With doc-literal as default user needs to make sure that he specifies message part of schema element, by default message part are defaulted to xsd:string so, user needs to make sure they point message part to xsd element not type. (We show error so user knows he needs to change it, so not a issue) rpc/encoded is a seperate issue, there is enhancement filed for this to support in mapper, Its not done in this release.
The difference between rpc-literal and doc-literal is of no interest when generating xpath query in mapper. This is always same no matter what is the underlying protocol one is using. The reason is that bpel does not say that for rpc-literal generating this kind of query and for doc-literal generate that kind of query. This is resolved tranparently by JBI and bpel engine.
Todd, please take a look at the comments from Ritesh and let me know if this is ok. I am not too familiar with the WSDL specifications to know what is best practice.
rpc-literal is the default in the wizard, This was needed since we use default builit in types for default message parts.
BP-compliant or not, my point was that doc/literal is what's expected these days, especially when creating document-centric business processes with BPEL. I also believe doc/literal is required for Microsoft interoperability. UI limitations should not drive runtime architecture choices. The "next-next" wizard behavior does not support a use case, but creating a doc/literal WSDL does (of creating a standards-compliant, best-practice, interoperable WSDL file). In my opinion, this needs to be addressed. What was actually wrong with the "inconsistent" behavior before? Was this truly an inconsistency that the user would have a problem with, or was it a matter of the wizard actually being intelligent about what it generated? Reopening and lowering priority.
If we want to use doc literal as the default binding type in wsdl, then we should do following to make sure user still can have next-next experience of creating wsdls. In wizard second step, select tns:string as the default element, make sure we show elements for all the built in schema types under inline schema in element/type chooser. This way user can either select built in schema types or inline schema element for the schema types in the wsdl.
*** Issue 94506 has been marked as a duplicate of this issue. ***
We can make document-literal as the default. The other option to solve this is: If user selects types in portType step, and document-literal in binding step, then we can auto create the elements for each types selected in the previous step. These elements are new elements created in types section pointing to original type selected by user. We can also show a message to user about this auto conversion.
*** Issue 117364 has been marked as a duplicate of this issue. ***
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss