axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <>
Subject RE: method mapping
Date Fri, 07 Dec 2001 15:00:17 GMT

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 []
Sent: Friday, December 07, 2001 8:38 AM
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
      <parameter name="methodName" value=" addEntry getAddressFromName
      <parameter name="methodMap" value="addEntry getAddressFromName
      <parameter name="scope" value="Session"/>

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
      <parameter name="scope" value="Session"/>
      <method name="addEntry"/>
      <method name="getAddressFromName"/>
      <method name="new" map="_new"/>

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


Russell Butek

View raw message