axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject Re: -1 for SVN revision 727413 (WSDL2Java change)
Date Sun, 01 Feb 2009 14:54:38 GMT
Hi Amila!

Amila Suriarachchi wrote:
> Earlier Rampart has matched the WSDL "Ping" to java "Ping". Then once I
> did the first change this did not get compiled since generated code was
> "ping". To fix this it was changed (by nandana I think) to "ping".
> 
> Then I changes code again (which you had put -1) so that by default it
> generates method name as "Ping". Now again rampart had a problem. This
> can be solved by either converting back the name as "Ping" or by using
> the -lcmn option when generating the code.

Ahhhh, I see.  Sorry, I got the wrong impression from your earlier
mails; I thought the behavior was always to lower-case the method names,
which IMO is in fact the *correct* behavior.  Now I understand why you
put in the option.

> just think what we had on the time Axis2 1.4 release. At that time the
> Operation name "Foo" mapped to java method name "Foo".  This has no any
> technical problem. But java coding convention requires method names to
> start with lower case letters. So I wanted to generate method names
> according to that (i.e. "foo")

I would characterize "not meeting the expectations of Java programmers"
to be a technical problem that I think we should fix.  See below.

> Just changing wsdl2java tool to generate such method name (which I did
> earlier) has two problems.
> 1. WSDL allows to have two operation names as "Foo" and "foo". Generated
> code won't compile for such WSDL files.

We need to fix this anyway, regardless of the option, so this is a
separate problem.  The answer is to generate "foo()", "foo1()", etc.

> 2. the generated code is not backward compatible with Axis2 1.4 release
> code.

Yeah, this is the part I didn't get before.

OK, here's my suggestion.  I consider the 1.4 behavior to be a bug, and
we should IMO fix it for 1.5 and beyond.  The fix should change the
default behavior to the standard JAX-RPC/JAX-WS mapping, and we should
at LEAST support (examples are imagined in one single WSDL):

WSDL              Java
------------------------------------
Foo               foo()
FoO               foo1()
Fo-O              foo2()

We're going to be living with this code for a long time, and I'd really
rather not have people forced to use "-lcmn" forever in order to get
what is actually the correct mapping to Java.  Of course, this WILL mean
problems with some pre-1.5 WSDLs, but we've already dealt with that in
Rampart (since the trunk has been converting to lower case) and others
can deal by switching to the correct mapping as well.  For backwards
compatibility, I *do* think we should add an option, but the option
should be something like "-14" for "1.4 backwards compatible"

Thoughts?

--Glen

Mime
View raw message