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