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 Thu, 05 Feb 2009 05:50:55 GMT
On Wed, Feb 4, 2009 at 9:03 PM, Glen Daniels <> wrote:

> 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
> mappings.
> >     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.
> +1.

Ok. then I'll add this option so that we can end up this discussion with an
agreement. Please give me one or two days I'll do it once I get the time.

> 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

I accept your criticism about the convention. But on the other hand I don't
think users find any critical
difficulty  using it.
First of all this may break you own idea you have mentioned above

- If we weren't doing things RIGHT before, then we should fix the
default behaviour.  But fixing a bug is the *only* reason to change the

Of course here also you can define not following Unix/GNU convention as a
critical bug worth changing
existing code.

Second issue is the backward compatibility. This make an impact on both
written code and articles. For an example Chinthaka has done a good
job[1][2][3] in documenting all these parameters. your change may make these
documents invalid.

So I am -0 on this change.

(Please start a new discussions if you need to talk this since people
interested this topic may ignore it with the discussion thread name)



> > 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.
> Thanks,
> --Glen

Amila Suriarachchi
WSO2 Inc.

View raw message