RE: DO NOT REPLY [Bug 12923] - Message Services don't support m uliple methods anymore

[Glen Daniels <gd...@macromedia.com>]

Namespace does matter in the RPC case, but we will try to fall back to ignoring it, which I think is actually a BAD thing, and I also think ignoring it is especially bad for doc/message services.

If you want to have no namespace (i.e. <method>) that should be fine, but I think we shouldn't just accept anything.  We're going to need to emit schema for this stuff eventually, and that should dictate what people send.

How about this:

We'll generate OperationDescs for every allowed method on Message-based services.  If you specify QNames in the WSDD, they'll be mapped as per usual to those methods.  If you don't, we will use the namespace of the service as specified in the WSDD to generate QNames, defaulting to "".  So:

<service name="foo" provider="java:MSG">
  <parameter name="allowedMethods" value="*"/>
  <parameter name="className" value="Foo"/>
</service>

public class Foo {
    public Element [] method1(Element [] arg);
    public Element [] method2(Element [] arg);
}

will look for "<method1>" and "<method2>".  If you add:

<namespace>http://foo</namespace>

to the WSDD, we'll then look for "<ns:method1 xmlns:ns='http://foo'>", etc.

--Glen

> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Monday, September 23, 2002 12:33 PM
> To: axis-dev@xml.apache.org
> Subject: DO NOT REPLY [Bug 12923] - Message Services don't support
> muliple methods anymore
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12923>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12923
> 
> Message Services don't support muliple methods anymore
> 
> 
> 
> 
> 
> ------- Additional Comments From dug@us.ibm.com  2002-09-23 
> 16:32 -------
> Does the namespace matter in the RPC case?  Not sure, but I 
> don't think it does.
> My inclination would be to get it back to the way it was so that
> it doesn't break existing users.  If its possible to extend it so
> that it will _also_ support the notion of namespace qualification then
> that could be added in addition to the non-NS qualification support.
>