axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <>
Subject Re: -1 for SVN revision 727413 (WSDL2Java change)
Date Mon, 02 Feb 2009 05:40:34 GMT
Hi Glen,

On Sun, Feb 1, 2009 at 8:24 PM, Glen Daniels <> wrote:

> 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.

yes this is an option. But I would like to have two methods as  "Foo" and
"foo"  since this gives
and indication to user which method has mapped to which operation.
However if the methods are named as "fo-O" and "foO" there is no option
other than "foO" and "foO1"

> > 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,

this depends on whether xmlNameToJavaIdentifier has implemented according to
the JAX-RPC/JAX-WS specifications. I am not sure about it and if so that is
However As I saw  axis2  service deployment (I mean .aar files) does not
follow any JAX standards.

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"

Ok. I 'll rename  -lcmn option as -uon (use operation name) to enable people
backward compatibility and
the feature I have mentioned above.

Then by default it calls to xmlNameToJavaIdentifier and if some need the
feature I have mentioned above or
wants the backward compatibility they can use -uon option.

I am not sure whether this may break rampart again :)



> Thoughts?
> --Glen

Amila Suriarachchi
WSO2 Inc.

View raw message