beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Danner" <jac...@bea.com>
Subject RE: Service Control generation question....
Date Fri, 10 Jun 2005 21:13:50 GMT
I sent an email to Brian Zotter, the 181 spec lead about this about a
month ago. This is what he had to say:
< conversation>
<... />
Thanks for your feedback.  

First some background.  The change was made to be more consistent with
.NET and jaxrpc 2.0.   The name "return" was chosen because the literal
meaning( in our opinion) most expresses the web service action being
described.  "response" was also debated but it is too tied to document
wrapped style.  Where as "result" is more of a mathematical term for the
result of an equation.  

As for consumers, we have tests for .Net, jaxrpc ri and of course wls.
We have also successfully tested this against Axis 1.2.  

Any decent webservice stack should be doing keyword checking and
mangling on any code that they generate.  If return doesn't work for
them, nothing else would.  One can also argue that it is better to
default to a reserved keyword so this type of problem manifests early
rather than after the release.

Which particular client(s) are you concerned or had problems with?

We are unable to make any changes to 181 1.0.   With that said, the
default for WebResult might change for Doc/Literal/Bare binding in the
maintenance release.  The proposed change will be: operation name +
"Return."  This is to avoid global element name clashes.   Currently a
WebResult.name must be set on each method in bare case.

Brian
------------------------------------------------------------------------
----
From: Jacob Danner 
Sent: Wednesday, May 18, 2005 9:53 PM
To: Brian Zotter
Cc: Jacob Danner
Subject: Concerns with @ WebResult - JSR-181

 

Hey Brian,

Daryoush told me you were the guy to chat with about this. Its regarding
the default value for the @WebResult. In revision .91 the value was
changed from 'result' to 'return'. 

<... />

On to my point, right before WLW 7.0 went alpha, we ran into an issue
resulting from the response elements being named 'return'. In many
programming languages return is a reserved keyword and in several soap
toolkits the response element name is mapped into a variable name. The
problem then becomes after consuming a WSDL, the client code was not
compilable. 

With the default value of the @WebResult annotation being 'return', the
specification now opens itself to similar problems. Is there anything we
can do to update the spec and avoid this potential situation? 

<... />
With which toolkits does consuming this service work?

 

Thanks for addressing my concerns,

-Jacob Danner
</conversation>
-----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:chad.schoettger@gmail.com]
> 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

Mime
View raw message