axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <amilasuriarach...@gmail.com>
Subject Re: -1 for SVN revision 727413 (WSDL2Java change)
Date Fri, 09 Jan 2009 05:24:33 GMT
On Thu, Jan 8, 2009 at 8:22 PM, Glen Daniels <glen@thoughtcraft.com> 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/

Mime
View raw message