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, 30 Jan 2009 06:23:21 GMT
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 <
amilasuriarachchi@gmail.com> 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 <
> 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/
>



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

Mime
View raw message