Hi Russell!
See the note I just sent to Greg. I do see the need for, and want to see, a good out-of-band solution for this, but that doesn't mean the in-band one we have now is bad or should go away. I don't think there's a real impasse here, I suspect Tom was just having a bout of "file-o-phobia" (fear of proliferating metadata files - "get 'em off me!" :)). Let's just make sure everyone groks everyone else's position. Can you give an example of what you mean by "if this non-bean stuff changes"? You mean if the XML serialization of a bean changes, or if the APIs in Axis change? --Glen > -----Original Message----- > From: Russell Butek [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 11, 2002 8:37 PM > To: [EMAIL PROTECTED] > Subject: RE: Bean Class/Bean Class Helper Generation > > > 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) > >
