Hey Amila, all: Apologies if the tone of that last mail was a bit intense. :) I don't mean to be confrontational here, clearly we all want things to work. I'm just having trouble understanding what you want here. Maybe you could just answer a couple of questions:
It seems like your changes broke the Rampart build. That's issue #1. Do you think Rampart is wrong in mapping WSDL "Ping" to Java "ping()"? If so, why? Issue #2 is why you think the option is necessary at all. Could you please explain that? Thanks, --Glen Glen Daniels wrote: > Hi Amila: > > Sorry for the late reply, I had a logjam with my axis-dev mail for a few > days (I *thought* it was weird that nothing was coming in). > > I don't know how much more clearly I can put this than [1], but I'll try. > > -1 to the change you just made, Amila, and -1 to the option. I never > withdrew my previous -1, so that's why I reverted your change after you > didn't. Sorry, but what you're trying to do here is just wrong as far > as I can tell, and until you explain exactly what you're trying to do > and why we need it I'm not going to accept a change which BREAKS > previous codegen behavior in incorrect ways. I'm going to ask that you > please revert 739189 and 739190, and I will once again explain my reasoning. > > Let's forget, for the moment, what previous revisions did or did not do, > and focus on the way it SHOULD work, ok? We'll get back to history later. > > * We MUST call xmlNameToJavaIdentifier() when translating XML stuff > (i.e. WSDL) to Java stuff. This is not negotiable. XML's lexical > identifier space is simply not compatible with Java's, and we therefore > must do some mapping in order to guarantee compilable Java code. The > simple examples here are a) a WSDL operation "foo-bar", and b) multiple > XML elements/operations that map to the same Java (for instance "Foo", > "foo", and "FoO"). > > * We MUST guarantee compilable Java code from *any* valid WSDL. > > * The mapping SHOULD be exactly the same as the standard JAX-RPC/JAX-WS > mapping rules. Why would it ever be otherwise? > > Please let me know if you have any issues with this analysis. And > others, please feel free to chime in here! > > So, a few results from this: > > - If we weren't doing things RIGHT before, then we should fix the > default behavior. But fixing a bug is the *only* reason to change the > default. > > - We should have a set of tests that confirms the correct behavior. > Have a WSDL that demonstrates all the conversions, including generations > for "foo1()", "foo2()" etc. when there are identical mapping results. > Axis1 did this right, Axis2 should too. > > - Why would we ever need an option to change this behavior? > > As I understand it, we *were* doing the right thing - mostly - before > you added the option. That's why Rampart assumes the WSDL "Ping" > operation generates a Java "ping()", which is correct. When you added > the option, you changed the default behavior and broke things. > > Please respect the -1 and revert your changes. If you can explain > (preferably with a concrete example/test) why you still think we need an > option, I'm happy to discuss it. > > Thanks, > --Glen > > [1] http://markmail.org/message/7iq6wrgxdtxg5wfu > > Amila Suriarachchi wrote: >> Added an option to make the method name lower case. By default wsdl2java >> generates the code using the operation name of the wsdl. Rampart can >> either add this option (i.e -lcmn ) or revert the earlier change. >> >> thanks, >> Amila. >> >> On Mon, Jan 26, 2009 at 10:51 AM, Amila Suriarachchi >> <[email protected] <mailto:[email protected]>> wrote: >> >> hi Glen, >> >> What is the motivation behind this change? >> >> http://svn.apache.org/viewvc?view=rev&revision=733776 >> <http://svn.apache.org/viewvc?view=rev&revision=733776> >> >> 1. You have done this after my fix for this issue which has been >> discussed this this thread without any further discussions. IMHO you >> should have send a notification to this thread at least after doing >> this change. >> >> 2. -lcmn is an option. IMHO there is no reason to revert an option. >> >> 3. What is the best way you suggest? >> >> thanks, >> Amila. >> >> >> >> >> On Fri, Jan 9, 2009 at 10:54 AM, Amila Suriarachchi >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> >> On Thu, Jan 8, 2009 at 8:22 PM, Glen Daniels >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Amila: >> >> Amila Suriarachchi wrote: >> > > Originally (i.e. even for Axis2 1.4 ) the generated >> method names were >> > > exactly same as the Operation >> > >> > This has no compilation problem. since port type operation >> names differ >> > from each other. >> >> Let me put this as directly as possible. If we don't call >> xmlNameToJavaIdentifier() when translating names, we can end >> up with >> uncompilable stuff. Just run WSDL2Java on a WSDL with an >> operation name >> containing a dash or any other illegal Java identifier >> character. That >> MUST be fixed. >> >> If we don't have some way of munging names so that we handle >> the case >> where multiple XML names map to the same Java name, we will >> also likely >> end up with uncompilable code (due to duplicate method >> names). That >> MUST be fixed. >> >> >> Here I have made a mistake of reverting the first commit. see >> the initial commit[1] >> it was calling to xmlToJava method to avoid the problem you have >> mentioned. I changed the current accordingly. >> thanks for pointing out this. >> >> thanks, >> Amila. >> >> [1] >> >> http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/codegen/src/org/apache/axis2/wsdl/codegen/emitter/AxisServiceBasedMultiLanguageEmitter.java?r1=644817&r2=660424 >> >> <http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/codegen/src/org/apache/axis2/wsdl/codegen/emitter/AxisServiceBasedMultiLanguageEmitter.java?r1=644817&r2=660424> >> >> >> >> >> > So you're telling me that Axis2 1.4 would generate >> uncompilable names? >> > >> > No. It generates the names correctly. please see above. >> The only thing >> > is if a wsdl operation name starts with >> > some thing like 'Foo' then the generated method name is >> also 'Foo' which >> > is not the java convention. >> >> And if an operation name is "Do-Something"? >> >> > If there are two or more XML names which map to a >> common Java name, then >> > it's our responsibility to disambiguate them, >> typically by adding a >> > suffix. So for XML operation names "Foo" "F-oO" and >> "foo", you'd get >> > Java names "foo()", "foo2()", and "foo3()". The >> metadata/code should >> > handle making sure that each method correctly >> serializes/deserializes >> > the appropriate XML. This is the way Axis1 works, and >> I believe it is >> > the way most other Java toolkits work. >> > >> > this is also an option. But isn't it better to go with the >> way we were >> > in the Axis2 1.4. Otherwise >> > as you have mentioned this may cause problems to users. >> >> However things were, we must do things the right way - if we >> were doing >> this in a buggy/wrong way before, then fixing that is a good >> thing. >> >> > I disagree. If ANY valid WSDL can produce Java code >> that does not >> > compile, then we have a bug. Just because we had a >> bug before doesn't >> > mean it's ok to exchange one bug for another. >> > >> > I may not have made this clear. >> > First Axis2 1.4 worked fine and Rampart was also worked >> accordingly and >> > worked fine. >> > >> > Then I made the change I have mentioned and *Rampart has >> also changed* >> > accordingly. >> > Therefore now rampart is compatible with the first change. >> > >> > Then I reverted the first change and made this as an >> option. Since >> > rampart is compatible with the first change now it is failing. >> > Therefore basically reverting the change made to the >> rampart (so that it >> > looks like at the Axis2 1.4 release ) fix this issue. >> >> As far as I can tell, we are still doing things wrong. >> There should be >> NO way, with an option or without, to ever generate >> uncompilable Java >> code from a valid WSDL. As I understand it right now if you >> do not >> specify the "-lcmn" option we will not do XML->Java name >> translation, >> and if so, that is just broken. >> >> Thanks, >> --Glen >> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/
