Hi Glen,
On Sun, Feb 1, 2009 at 8:24 PM, Glen Daniels <[email protected]> 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 great. 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 :) WDYT? thanks, Amila. > > > Thoughts? > > --Glen > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
