Russell and I talked about this offline and so +1.
Let me add some additional comments:
A) The fault class bean mapping in JSR 101 does require a full
constructor. The same problems apply: 'what is the order of the
parameters?', 'what do we do with attributes?'. So I would like to see
the same decisions on both mappings.
B) Due to (A) the current JavaBeanWriter has a method that will write the
full constructor. Currently this method is disabled for normal beans and
enabled for fault beans. If we need to get past this TCK requirement, we
should enable this bean via a --forTCKOnly option on the emitter.
C) I think that it is okay for a tool to generate a full constructor if it
would like....its just not part of the spec, so the TCK should not depend
on it existing.
Rich 'Shirley' Scheuerle
IBM WebSphere & Axis Web Services Development
512-838-5115 (IBM TL 678-5115)
Richard Sitze/Charlotte/IBM@IBMUS
06/14/2002 08:17 AM
Please respond to axis-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: TCK issue: beans with full constructors?
+1 for your analysis & conclusion
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Russell Butek/Austin/IBM@IBMUS
Russell Butek/Austin/IBM@IBMUS
06/13/2002 06:03 PM
Please respond to axis-dev
To: [EMAIL PROTECTED]
cc:
Subject: TCK issue: beans with full constructors?
The TCK requires generated beans to have full constructors. In other
words, if a bean has properties
int x;
String y;
then you must have a constructor
Bean(int x, String y);
We DO NOT have a full constructor in axis for a number of reasons. I
believe the TCK SHOULD NOT require the full constructor. Let me know
whether you think this is a legitimate argument to take to the JAX-RPC
folks.
1. I don't ever recall seeing that a full constructor is required by any
bean spec.
2. JAX-RPC itself does not explicitly require it.
3. If the WSDL complexType contains <xsd:sequence>... then the order is
fixed. But if the complexType contains <xsd:all>... then you CANNOT know
the order and therefore cannot depend on a bean being generated with some
particular order. When you're programming to a bean, you have no idea
whether this bean was generated from sequence or all, so you cannot depend
on any given order.
4. We in AXIS support attributes as well as elements. Attributes are
optional in JAX-RPC, so it doesn't say anything about how they exist in a
bean. How would they appear in a full constructor? First? Last? What if
they're optional? Do the appear in the constructor at all? Since we only
have the default constructor, these issues don't exist.
For these reasons we've decided NOT to generate full constructors. For
reasons 1, 2, 3, I don't believe the TCK should require them.
Granted the following code:
Bean bean = new Bean(5, "hi");
is simpler to write than:
Bean bean = new Bean();
bean.setX(5);
bean.setY("hi");
But I think I've explained why the former isn't acceptible. Any other
thoughts?
Russell Butek
[EMAIL PROTECTED]
