Hi, as far as I recollect there was a discussion around this....(am still trying to pull that thread out) and the exception was intentionally pulled out. I guess a WARNING is something that we must throw at the least.
- Venkat On 9/12/07, ant elder <[EMAIL PROTECTED]> wrote: > > Had this over on the user list about how the binding.ws uri is ignored if > you use wsdlElement with #wsdl.port. We used to throw an exception in that > case which I think makes things much clearer but that code has been > changed > so that no longer happens. Was that removed intentionally or could i add > it > back? > > ...ant > > ---------- Forwarded message ---------- > From: ant elder <[EMAIL PROTECTED]> > Date: Sep 12, 2007 8:46 AM > Subject: Re: uri of binding.ws should be used restrictedly > To: [EMAIL PROTECTED] > > > > On 9/12/07, shaoguang geng <[EMAIL PROTECTED]> wrote: > > > > Hello every one, > > > > uri attribute of <binding.ws/> is much convenient to attach a WS in. > > > > But it works only within a few circumstances, such as another java > > generated WS provided by Tuscany, JAXWS. > > > > But much more WS is complecated, such as JBoss or even a Tuscany WS when > > the wsdl becomes delicate. > > > > Under these circumstances, pre loading wsdl (locally save the wsdl) and > > use "wsdlElement" will do most of them. Up to now, I have gone over it > with > > JBoss and ODE. > > > > So I just think, to make things frank, I would suggest that Tuscany user > > should be warned of uri's limitation, and encouraged of using wsdl > > preloading. > > > The uri attribute should always get used unless the wsdlElement is > pointing > at the port (ie using "#wsdl.port") in which case the uri attribute is > ignored. So you can use both uri and pre loaded wsdl as long as you use > #wsdl.binding within the wsdlElement. > > I agree its confusing that the uri can get completely ignored, the code > did > used to throw an exception in that case so it was obvious there was a > conflict, i'll bring it up on the dev list to see if we can add that back. > > ...ant >
