Thanks Daryoush - it makes sense to me now. - Chad
On 6/11/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > > Both forms are accurate, and you are right the 2nd form is better. > > As to why we generate the first form.... The logic right now has a > rather simplistic logic, if there are just one OUT parameter then > that is the return value of the call, if there are more than one OUT > then there are all included as argument to the call and the methods > returns void. > > The logic can be improved by adding more heuristics, like if you have > an OUT parameter that is named "return" or may be even "result" it > should be the return value of the call (which makes the logic work > well with the WSM defaults) Or if you have more than one OUT, the > one that is boolean or integer is more likely to be return value. > Unfortunately, AFAIK, there are no rules that the WSDL has to be > structured as such. > > Daryoush > > On 6/10/05, Chad Schoettger <[EMAIL PROTECTED]> wrote: > > Sure, I'll file a bug on this issue. > > > > I'm still a bit curious as to why the method signature generated by the > > ExtensionMaker is: > > > > public void > > UpdatePhoneNumbers( > > > > org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address> > > address1, > > web.webparam.Phone phone, javax.xml.rpc.holders.IntHolder > > return, > > > > org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address > >address2) > > throws Exception; > > > > INSTEAD OF: > > public int > > UpdatePhoneNumbers( > > > > org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address> > > address1, > > > > org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address > >address2) > > throws Exception; > > > > It seems the second form would be a more accurate representation of the > > webservice call than the first. But perhaps there is some technical > reason > > for this? > > > > - Chad > > > > > > > > > > > > > > On 6/10/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > > > I don't discount the use of headers, in fact last time I checked EBay > > > does use it for it authentication.. As you pointed out Header makes a > > > lot of sense for things like Authentication, transaction mgmt, etc. > > > But if you were to implement these services you would implement them > > > using a Handler as oppose to arguments on the methods, very similar to > > > the EJB model were the beans are not involved in security or > > > transaction aspects of the call. > > > > > > Lets say you want to have a security header parameter that is your > > > message checksum, at the time the JWS methods is called there is no > > > message for you to checksum, you would have to have a handler to get > > > the outgoing message (or incoming) to generate (or validate) the > > > checksum. So having the checksum as an argument to the methods wont > > > make any sense. Something with transaction you want that handled > > > outside the method call. > > > > > > The 181 spec does require header=true, which means we do have to > > > implement it on the server side. But I don't believe this will be a > > > common use case and I question the priority of this test on the > > > service control compare to other tests we could be developing. > > > > > > Daryoush > > > > > > > > > > > > On 6/10/05, Jacob Danner < [EMAIL PROTECTED]> wrote: > > > > Just to chime in here on top of my last 181 post. > > > > > > > > "I am curious to know why you think having INOUT parameters in the > > > > Header would be useful." > > > > > > > > The soap spec says the following about SOAP Headers (4.2): > > > > SOAP provides a flexible mechanism for extending a message in a > > > > decentralized and modular way without prior knowledge between the > > > > communicating parties. Typical examples of extensions that can be > > > > implemented as header entries are authentication, transaction > > > > management, payment etc. > > > > > > > > So using Headers allows for future extensions. With WS being > relatively > > > > new, the possibilities are endless. > > > > I don't think it's feasible at this early in the game to say that > using > > > > an INOUT header doesn't make sense only because few standards really > > > > make use of it at this point. There are many standards still in > draft > > > > and being developed that may make use of information in the header. > We > > > > shouldn't discount it soo soon. > > > > -Jacobd > > > > > > > > > > > > -----Original Message----- > > > > From: Daryoush Mehrtash > > > > Sent: Friday, June 10, 2005 1:05 PM > > > > To: Chad Schoettger; Beehive Developers > > > > Subject: RE: Service Control generation question.... > > > > > > > > I haven't looked at this, but I do have a question, (and this may > not > > > > have anything to do with the problem you are having) why are you > putting > > > > INOUT parameters in Header? This is an area were we do have known > > > > issues (I believe there are two bugs already filed on this) also I > > > > can't imagine this case being a realistic usage scenario. I am > curious > > > > to know why you think having INOUT parameters in the Header would be > > > > useful. > > > > > > > > Does the test work if the parameters were not in the header? > > > > > > > > Daryoush > > > > > > > > > -----Original Message----- > > > > > From: Chad Schoettger [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, June 10, 2005 12:52 PM > > > > > To: Beehive Developers; Daryoush Mehrtash > > > > > Subject: Service Control generation question.... > > > > > > > > > > So I'm working some new drt's for the webservice system control > and > > > > > have run into a bug but I'm not sure how to classify it: > > > > > > > > > > It occurs when I try to generate a service control from the > > > > > wsm-samples/webparams webservice's wsdl. > > > > > > > > > > > > > > > The annotated web service method is: > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ------------------- > > > > > @WebMethod > > > > > public int updatePhoneNumbers( > > > > > Phone phone, > > > > > @WebParam(name="address1", header=true, > > > > > mode=WebParam.Mode.INOUT) AddressHolder addressHolder1, > > > > > @WebParam(name="address2", header=true, > > > > > mode=WebParam.Mode.OUT) AddressHolder addressHolder2 > > > > > ) { .... } > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > > > > > > The WSDL is attached. > > > > > > > > > > The generated webservice control method is: > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > --------------------- > > > > > public void > > > > > > > > > > > UpdatePhoneNumbers(org.apache.beehive.wsm.databinding.GenericHolder<web. > > > > we > > > > > bparam.Address> > > > > > address1, web.webparam.Phone phone, > javax.xml.rpc.holders.IntHolder > > > > > return, > > > > > > > org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address> > > > > > address2) throws Exception; > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > --------------------- > > > > > > > > > > When the generated webservice control is compiled, apt blows up > due to > > > > > the 'return' parameter name in the arg list. > > > > > > > > > > Questions: > > > > > > > > > > 1) Is the control method being generated correctly? Should the > > > > > 'return' parameter be the return value for the generated method? > like: > > > > > > > > > > public int > > > > > > > > > > > UpdatePhoneNumbers(org.apache.beehive.wsm.databinding.GenericHolder<web. > > > > we > > > > > bparam.Address> > > > > > address1, web.webparam.Phone phone, > > > > > > > org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address> > > > > > address2) throws Exception; > > > > > > > > > > > > > > > 2) If the method is being generated correctly - it seems the > proper > > > > > fix would be to modify the ExtensionGenerator class to check for > param > > > > > names which are Java keywords and modify them to non-keywords so > that > > > > > the control can be compiled. Or would the proper fix be to modify > the > > > > > wsm model to correctly 'encode' the param as a non-java keyword? > > > > > > > > > > Thanks for any input on this. Once I have determined where the fix > > > > > needs to be made I will file a bug. > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -------- > > > > > > > > Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique > > > > online > > > > event, giving you the first look at a new category of enterprise > > > > software > > > > built specifically for Service-Oriented Architecture (SOA). > > > > > > > > Register Now. It's Free! > > > > > > > > http://www.bea.com/events/june15 > > > > > > > > > > > -------------------------------------------------------------------------------- > > > > > > > > Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique > > online > > > > event, giving you the first look at a new category of enterprise > > software > > > > built specifically for Service-Oriented Architecture (SOA). > > > > > > > > Register Now. It's Free! > > > > > > > > http://www.bea.com/events/june15 > > > > > > > > > > > > > -- > > > Daryoush > > > > > > Weblog: http://perlustration.blogspot.com/ > > > > > > > > > > -- > Daryoush > > Weblog: http://perlustration.blogspot.com/ >
