axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: -1 for SVN revision 727413 (WSDL2Java change)
Date Wed, 04 Feb 2009 15:33:00 GMT
Hi Amila!

Amila Suriarachchi wrote:
>     > 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"

Again, my strong belief is that we should follow the standard
conventions for mapping by default.  So even if we have both "Foo" and
"foo" I still think the right mapping is "foo()" and "foo1()".  The
backwards-compatible behavior can be "Foo()" and "foo()", that's fine.
And if, using the backwards compatible mode, we have "Foo" and "F-oo" we
should make sure they map to "Foo()" and "Foo1()".

Hey, look, test cases! :)

>     > 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 great.
> However As I saw  axis2  service deployment (I mean .aar files) does not
> follow any JAX standards.

I'm not saying we should switch the API and require the TCK.  I'm saying
that there's no reason NOT to follow, as closely as possible, the
standard mapping, b/c I think that would make life easier for Java
programmers in general.  The mapping was designed to use standard Java
coding conventions, which is IMO a good thing.

In any case, we should have an authoritative test that checks all the

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


As a completely separate topic, do you realize that command line options
like "-uon" are pretty much wrong according to the standard Unix/GNU
conventions?  A single dash is generally used to indicate single-letter
options, and the flag/switch options like this can traditionally be
combined... so "-uon" should really be equivalent to "-u -o -n".  Longer
word-like options are typically indicated GNU-style with a double-dash
and real words: "--useOperationName".  Along these lines, I'd really
like to redo the command-line processing for WSDL2Java/Java2WSDL one of
these days.  It's also been a long-term peeve of mine that you need the
"-uri" option when you should be able to just "wsdl2java"....

> 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 :)

It shouldn't, as Rampart now assumes the correct <Ping> -> ping()
mapping, and I for one would prefer it stay that way.


View raw message