axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject RE: method mapping
Date Fri, 07 Dec 2001 15:25:11 GMT
I like this approach.  It works for the mapping problem.  BUT there are
other problems.  Greg brought up the overloaded method problem.  If we have
3 methods called "X", but we only want to expose 2 of them, there's no way
to do that now.  Either all are exposed or all are hidden.  Option 2 seems
to most cleanly fix this problem as well as our mapping problem.

Since this is a discussion that may go on for a few hours (days?), I say
implement your fix now, so we can bring the JavaNames test back up to where
it was.  That way we'll have a test for when the wsdd solution is finally
implemented in place of this one.

Russell Butek
butek@us.ibm.com


Tom Jordahl <tomj@macromedia.com> on 12/07/2001 09:00:17 AM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: method mapping




Hey guys!

I know we all love XML and little config files that are incredibly hard for
users to understand and create, but how about Option X:

Since we know exactly how the Java keyword mapping works per JAX-RPC, just
add the following code to the server side lookup for the method:

  if (Utils.isJavaKeyword(methodName)){
     methodName = Utils.makeNonJavaKeyword(methodName)
  }

This will fix the problem without adding a whole 'nother config file
option.


Simple, fast and it works.

Is anyone going to deploy a web service with a method named 'new' unless
they generated it from existing WSDL (so they would be using Wsdl2java,
which follows well known rules)?

--
Tom Jordahl


-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Friday, December 07, 2001 8:38 AM
To: axis-dev@xml.apache.org
Subject: method mapping


This note is mostly directed to Sam, Glen, Tom, Rich, and I; we were
chatting about it yesterday; but it might be of interest to others.  A
problem arises when a WSDL operation has the name of a Java keyword, like
"new".  This "new" operation becomes the Java method "_new".  In the SOAP
message, "new" is sent across the wire, but this string is used to search
for the method implementation.  Since there is no "new" method, we get a
method not found error.  Note that, while sending "_new" across the wire
works, it only works for us because we have Java mappings on both sides.
If the other side was implemented in a language where "new" was not a
keyword, then no mapping would take place and "_new" would not exist and we
would again get a method not found error.  What we need in cases like this
is a mapping from the WSDL operation name to the Java method name.  This
mapping would be in deploy.wsdd.

Per our chat yesterday, here's where I think we stand.  I'd like to tackle
this today (though I probably need someone to point me to the parts in the
runtime that will have to change) and get the JavaNames test back to where
it was.

For simplicity, I would suggest that we add a methodMap parameter.  Assume
we add a "new" operation to the AddressBook sample:

  <service name="AddressBook" provider="java:RPC">
      <parameter name="className" value
="samples.addr.AddressBookSOAPBindingSkeleton"/>
      <parameter name="methodName" value=" addEntry getAddressFromName
new"/>
      <parameter name="methodMap" value="addEntry getAddressFromName
_new"/>
      <parameter name="scope" value="Session"/>
  </service>

Sam wanted a new element "method" with an optional attribute "map" which
I'm guessing would change the above to look something like:

  <service name="AddressBook" provider="java:RPC">
      <parameter name="className" value
="samples.addr.AddressBookSOAPBindingSkeleton"/>
      <parameter name="scope" value="Session"/>
      <method name="addEntry"/>
      <method name="getAddressFromName"/>
      <method name="new" map="_new"/>
  </service>

Option 1 is closer to what we have today and it only requires one new line,
and only when necessary.  The obvious downside is, if only one method needs
mapping, we still have to list all methods in the "methodMap" parameter.

Option 2 is a bit cleaner and allows us to provide the mapping for only
those methods that need it.  But the one (or two) line(s) from above become
many lines and I would guess it would take a bit more to implement.
Besides, doing this only for method looks a bit odd to me; it would look
better if we changed all parameters to elements; more work.

I opt for option 1 since it will be a rare case that this is ever
encountered and I'd hate to complicate things to accommodate border
conditions.

Thoughts?

Russell Butek
butek@us.ibm.com



Mime
View raw message