Whoa! A -1 on moving the meta data out of the bean class!?!?! I hate to be nasty, but I'm moving closer and closer (not QUITE there, yet) to saying -1 on keeping it IN! It puts non-bean stuff on beans (bad bad bad). It locks out the possibility of using beans that come from somewhere else in AXIS. It might require users - who only use the bean stuff - to recompile if this non-bean stuff changes.
I hope we're not at a philosophical impasse! I'm gonna have to relearn the BeanInfo class, I think. See if Doug's suggestion is doable. Russell Butek [EMAIL PROTECTED] Tom Jordahl <[EMAIL PROTECTED]> on 03/11/2002 05:00:34 PM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: Bean Class/Bean Class Helper Generation -1 on moving the meta data out of the bean class and in to some other place. I find this mechanism simple and easy to understand and use (hey, what do you know, I coded it). I do not think a helper class would be as straightforward, nor would it be as easy for users to grasp quickly. I don't see the advantage of emitting (another!) class. I also don't see how we are limited by this architecture. It has already proven its flexibility by getting extended (in a cool way!) by Glen. I see nothing that would prevent us from dealing with "future expansion". P.S. What do you mean the equals method "needs work"? I think its pretty good for getting whipped off in 10 minutes at the interop. :-) -- Tom Jordahl Macromedia -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 5:15 PM To: [EMAIL PROTECTED] Subject: Bean Class/Bean Class Helper Generation There have been several recent changes to the Bean Class generation to support more advanced xml features...namely attributes. I applaud the new functionality, but we need to step back and consider a more flexible architectural direction. I would like to see all of the meta data information removed from the java bean class and placed in a Helper class that extends a Helper interface. Here is a first pass at the Helper interface: interface Helper { public org.apache.axis.description.TypeDesc getTypeDesc(); public org.apache.axis.encoding.Serializer getSerializerAs(String mechanismType); public org.apache.axis.encoding.Deserializer getDeserializerAs(String mechanismType); } The generated bean class should contain ONLY the getters/setters describing the bean (and perhaps the equals() method...which needs some work). This would adequately decouple the logical bean from the serialization/deserialization of the bean. The BeanSerializerFactory/BeanDeserializerFactory could be tweaked to always look for a corresponding Helper class to find the meta data or find the custom serializer/deserializer. The generic serializer/deserializer classes should use default behaviour if the helper class is not available. (In fact I am in favor of having separate meta data aware serializers/deserializers.) Separating the bean and the bean helper would allow users to provide custom Helper emitters to add custom serializers etc. Please comment. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115)
