It is possible for an element to have a default= attribute. We just don't
support it yet.
So elements have the same problems as attributes.
Unless I get a disagreement, I am going to remove the full constructor
emission and
fix the testcases.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Tom Jordahl
<tomj@macromedia. To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
com> cc:
Subject: RE: Full Constructor Issue
02/22/2002 01:30
PM
Please respond to
axis-dev
I am hesitant about removing the full constructor.
It would be easy to remove the attribute elements from the argument list.
In fact, I might argue that it is a bug that I let them be generated that
way.
The argument about enforcing restriction in set methods is a good one
however.
My vote: +0 (the cowards way out)
--
Tom Jordahl
Macromedia
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 1:19 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Full Constructor Issue: was Re: cvs commit:
xml-axis/java/test/wsdl/interop3/groupE/client
InteropTestDocLitServiceTestCase.java
InteropTestRpcEncServiceTestCase.java
+1 to getting rid of the full constructor in the generated bean classes.
Now that Tom and Glen have added attribute support, the attribute
parameters also appear in the full constructor list.
This is a bad idea since attributes are supposed to be order independent.
Since it is not a dependable API, it should be eliminated.
The testcases depend on the full constructor, so getting rid of the full
constructors will require a number of changes.
I am willing to make the change if I get some more +1's.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Russell
Butek/Austin/IBM@ To:
[EMAIL PROTECTED]
IBMUS cc:
Subject: Re: cvs commit:
xml-axis/java/test/wsdl/interop3/groupE/client
02/22/2002 07:37
InteropTestDocLitServiceTestCase.java InteropTestRpcEncServiceTestCase.java
AM
Please respond to
axis-dev
This issue only arises when you write code to a given binding, and then
pass the WSDL for that binding AND YOUR CODE somewhere else. If that
somewhere-else were going to write their own code based on their own
bindings, there'd be no problem (I think).
I suspect we see this problem when we cross JVM lines. Somewhere, the
parameters are put into a Hashtable or HashMap or something of that nature.
I wonder whether IBM's JVM and Sun's use different algorithms for their
Hashtable implementations. Doing things in the same JVM always produces
the same order, so the constructor is usable and useful if you stay in one
JVM. I guess you're asking whether we should depend on that?
OK, what do folks think? The constructor that takes all the elements is
useful, but could go astray. Do we leave it there for its usefulness or do
we remove it to avoid problems like Glyn's?
My vote? +1 to leave the constructor as is. (I COULD add a warning
comment to that constructor when the WSDL has an <all> collection.)
Russell Butek
[EMAIL PROTECTED]
Glyn Normington/UK/IBM@IBMGB on 02/22/2002 07:06:43 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: cvs commit: xml-axis/java/test/wsdl/interop3/groupE/client
InteropTestDocLitServiceTestCase.java
InteropTestRpcEncServiceTestCase.java
Russell,
Thanks for fixing those tests. What's the use of WSDL2Java generating those
constructors if their signatures can't be relied upon not to change?
Glyn
