axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sc...@us.ibm.com
Subject Re: TCK issue: beans with full constructors?
Date Fri, 14 Jun 2002 13:27:59 GMT
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:     axis-dev@xml.apache.org
        cc: 
        Subject:        Re: TCK issue:  beans with full constructors?

 

+1 for your analysis & conclusion
<ras>

*******************************************
Richard A. Sitze rsitze@us.ibm.com
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: axis-dev@xml.apache.org
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
butek@us.ibm.com



Mime
View raw message