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/
