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