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 Mon, 26 Jan 2009 05:21:15 GMT
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 <
amilasuriarachchi@gmail.com> wrote:

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



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Mime
View raw message