Re: [jira] Updated: (TUSCANY-2332) reconsider non-support for Holders
Hi Scott, more comments... Simon On Wed, May 28, 2008 at 2:34 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: > Simon, > > I used my own interpretation of the JAX-WS spec (in Sec 2.3 and its > subsections) to construct my example WSDL, and noticed that the JAXWS-RI > wsimport tool handled it by generating Holder(s) in Java as I expected. > Note that my example does only have a single part per message, in spite of > the way the part wrapper elements' children map to Java (via Holders). > > WSDL 1.1 Sec. 2.4.6 seems to discuss parameterOrder. This is also > discussed > in JAX-WS. However I'm not sure why this is especially helpful to discuss > in this context and I don't see what the conflict is with my approach. > I just looked at JAX-ws 2.3.1.2 and see the rules you are talking about. I mentionedsection 2.4.6 of WSDL1.1 as IIUC it gives the same list of in, in/out, out options but with different rules for determining them. In particular it's not talking about what to do with wrapped style WSDL. As the SCA spec points us toward JAX-WS I expect the rules you point out are the right ones. I should have looked there first. > > > BTW, I should add an important note... I'm not at all sure what Tuscany > does > with this WSDL today and didn't spend any time trying to understand this. > I > just made a leap and assumed we didn't support this today. > > I suspect you are generally correct. As the specs expressly say that this is not supported we haven't looked at this. To see what the actual effect is of trying to use a WSDL like to one you provide we'll have to try it. I can imagine these cases where you have more than one element children of the return type will be problematic but I'd be interested to know what the error message is.
Re: [jira] Updated: (TUSCANY-2332) reconsider non-support for Holders
Simon, I used my own interpretation of the JAX-WS spec (in Sec 2.3 and its subsections) to construct my example WSDL, and noticed that the JAXWS-RI wsimport tool handled it by generating Holder(s) in Java as I expected. Note that my example does only have a single part per message, in spite of the way the part wrapper elements' children map to Java (via Holders). WSDL 1.1 Sec. 2.4.6 seems to discuss parameterOrder. This is also discussed in JAX-WS. However I'm not sure why this is especially helpful to discuss in this context and I don't see what the conflict is with my approach. BTW, I should add an important note... I'm not at all sure what Tuscany does with this WSDL today and didn't spend any time trying to understand this. I just made a leap and assumed we didn't support this today. On Tue, May 27, 2008 at 5:18 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > On Wed, May 21, 2008 at 7:19 PM, Scott Kurz (JIRA) < > tuscany-dev@ws.apache.org> wrote: > > > > > [ > > > https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > > > Scott Kurz updated TUSCANY-2332: > > > > > >Attachment: guessAndGreet.wsdl > > > > > reconsider non-support for Holders > > > -- > > > > > > Key: TUSCANY-2332 > > > URL: > https://issues.apache.org/jira/browse/TUSCANY-2332 > > > Project: Tuscany > > > Issue Type: Improvement > > > Components: Java SCA Data Binding Runtime > > >Reporter: Scott Kurz > > > Attachments: guessAndGreet.wsdl > > > > > > > > > Though the Java annotations/API spec specifically says wrt WSDL-> Java > > mapping: > > > The JAX-WS mappings are applied with the following restrictions: > > > • No support for holders > > > I'd like to suggest that we look into enabling such support anyway, as > > this seems overly restrictive and prevents us from supporting existing > WSDLs > > with inout data. > > > At least I don't see how we'd map these WSDLs to Java and would think > > we'd be way better off relying on the mapping defined by JAX-WS which > does > > use Holders. > > > (Not sure what this statement in the spec was trying to accomplish.) > > > I attached an example WSDL with two operations which we'd want to use > > Holders in the corresponding Java methods. One has a common child > element > > of both input/output wrapper elem and the other has a common part of > > input/output message. > > > (Maybe it would be better to bring this up before opening a JIRA, but I > > wanted to attach the WSDL.) > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > Hi Scott > > I have a couple of questions/comments related to this. > > I don't know why the spec specifically stated that we won't support this > either but I can make a guess. > > On a philosophical note if you are in the business of writing coarse > grained > service interfaces with the intention of being protocol independent then > relying on in/out or out parameters in you interface is unlikely to make > your interfaces clear and easy to use. Like everything, as a purely > technical challenge, I'm sure it could be made to work but IMHO it doesn't > add clarity or achieve anything that can't be achieved with clearly > delineated input parameters and a response value. > > As we only deal with doc/lit/wrapped WSDL currently Tuscany only expects > one > part per message and would always expect there to be a set of input > parameters and a response. If this WSDL has come from some other existing > system with the intention of representing in/out or out parameters then the > SOAP engine on the service end will be marshalling from request parameters > and to a responses so Tuscany would just take the WSDL at face value. > > As a slight aside, looking at the WSDL attached, I had to go and check in > the WSDL spec what the hints are for in/out and out params. In WSDL 1.1 I > found some words in section 2.4.6 which don't seem to chime with the > approach you have taken. What rules are you following to indicate in/out > and > out parameters. > > Regards > > Simon >
Re: [jira] Updated: (TUSCANY-2332) reconsider non-support for Holders
On Wed, May 21, 2008 at 7:19 PM, Scott Kurz (JIRA) < tuscany-dev@ws.apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Scott Kurz updated TUSCANY-2332: > > >Attachment: guessAndGreet.wsdl > > > reconsider non-support for Holders > > -- > > > > Key: TUSCANY-2332 > > URL: https://issues.apache.org/jira/browse/TUSCANY-2332 > > Project: Tuscany > > Issue Type: Improvement > > Components: Java SCA Data Binding Runtime > >Reporter: Scott Kurz > > Attachments: guessAndGreet.wsdl > > > > > > Though the Java annotations/API spec specifically says wrt WSDL-> Java > mapping: > > The JAX-WS mappings are applied with the following restrictions: > > • No support for holders > > I'd like to suggest that we look into enabling such support anyway, as > this seems overly restrictive and prevents us from supporting existing WSDLs > with inout data. > > At least I don't see how we'd map these WSDLs to Java and would think > we'd be way better off relying on the mapping defined by JAX-WS which does > use Holders. > > (Not sure what this statement in the spec was trying to accomplish.) > > I attached an example WSDL with two operations which we'd want to use > Holders in the corresponding Java methods. One has a common child element > of both input/output wrapper elem and the other has a common part of > input/output message. > > (Maybe it would be better to bring this up before opening a JIRA, but I > wanted to attach the WSDL.) > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > Hi Scott I have a couple of questions/comments related to this. I don't know why the spec specifically stated that we won't support this either but I can make a guess. On a philosophical note if you are in the business of writing coarse grained service interfaces with the intention of being protocol independent then relying on in/out or out parameters in you interface is unlikely to make your interfaces clear and easy to use. Like everything, as a purely technical challenge, I'm sure it could be made to work but IMHO it doesn't add clarity or achieve anything that can't be achieved with clearly delineated input parameters and a response value. As we only deal with doc/lit/wrapped WSDL currently Tuscany only expects one part per message and would always expect there to be a set of input parameters and a response. If this WSDL has come from some other existing system with the intention of representing in/out or out parameters then the SOAP engine on the service end will be marshalling from request parameters and to a responses so Tuscany would just take the WSDL at face value. As a slight aside, looking at the WSDL attached, I had to go and check in the WSDL spec what the hints are for in/out and out params. In WSDL 1.1 I found some words in section 2.4.6 which don't seem to chime with the approach you have taken. What rules are you following to indicate in/out and out parameters. Regards Simon
