+1 .. beans can only have no-args constructors; otherwise it breaks
the entire programming model they espouse.
Sanjiva.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 14, 2002 5:03 AM
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]
