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]> wrote: > hi Glen, > > What is the motivation behind this change? > > 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]> wrote: > >> >> >> On Thu, Jan 8, 2009 at 8:22 PM, Glen Daniels <[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 >> >> >>> >>> >>> > 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/
