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 Wed, 07 Jan 2009 06:24:15 GMT
On Wed, Jan 7, 2009 at 10:26 AM, Glen Daniels <glen@thoughtcraft.com> wrote:

> Hi Amila!
>
> Hope you had a very happy new year.
>
> Amila Suriarachchi wrote:
> > On Tue, Jan 6, 2009 at 8:18 PM, Glen Daniels <glen@thoughtcraft.com
> > <mailto:glen@thoughtcraft.com>> wrote:
> >
> >     Hi Amila,
> >
> >     The Rampart build was broken with the Axis2 1.5 branch, and Andreas
> >     clued me in that the problem was that change 727413 (adding the -lcmn
> >     option) hadn't been made on the branch.  After taking a look at that
> >     change, I'm going to belatedly -1 it for Axis2.
> >
> >
> > Let me explain the problem.
> > 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.

>
> > names in the WSDL file PortType section. Then I changed this to generate
> > the methods start with the lower case letters
>
This is the change which causes compilation problems. if there are two
operation names like Foo and foo.

> as that is the java
> > convention.
>
> 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.


> If so, that was clearly an enormous bug in 1.4 (and previous revisions?).
>
> > But this causes a problem. WSDL allows users to have two operations like
> > Foo and foo which gives a compilation problems for earlier fix.
>
> 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.

>
>
> > So now the default behaviour is same as were in Axis2 1.4 release and
> > have an additional option of -lcmn.
> > IMHO this is the correct way since wsdl allows operation names such as
> > Foo and foo.
>
> -1, see above. :)
>
> >     Here's my reasoning.  First and foremost, the change was implemented
> not
> >     by changing the JavaUtils.xmlNameToJavaIdentifier() method (for
> instance
> >     by adding another override with a flag), but by simply not calling it
> >     unless the lcmn option was specified.
> >
> > Please see the above reason. earlier(menas when the time of Axis2 1.4)
> > it did not call any method and use the localpart as it is. Now if -lcmn
> > is given it calls this method.
> > [...]
> > IMHO changing the rampart code (which as changed to first change) is the
> > correct solution. I accept the fact that
> > I have made a mistake doing the first change without adding it as an
> > option in the first place. But now it has been reverted and has done the
> > correct 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.

thanks,
Amila.

>
>
> Can you send your reply to axis-dev so we can have this discussion on-list?

Sorry. I always make this mistake of clicking replyTo instead of replyToall.


>
>
> Thanks,
> --Glen
>



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

Mime
View raw message