On Wed, Feb 4, 2009 at 9:03 PM, Glen Daniels <[email protected]> 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 > http://host.com/my.wsdl";.... 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 default. 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) thanks, Amila. [1] http://wso2.org/library/tutorials/reference-guide-axis2-code-generation-parameters-part-1 [2] http://wso2.org/library/tutorials/reference-guide-axis2-code-generation-parameters-part-2 [3] http://wso2.org/library/tutorials/reference-guide-axis2-code-generation-parameters-part-3 > > > 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. blog: http://amilachinthaka.blogspot.com/
