Yeah, the proliferation of files DOES worry me. Perhaps whatever solution we end up with should continue along the path you set? Right now the meta-data ONLY exists if we have attributes, so whether it's inline or outline, the meta data will only be generated when we need it (though I fear we'll start needing it everywhere).
What I meant by "if this non-bean stuff changes" is if the AXIS APIs change. The generated bean now has a static typeDesc and a static block of code that initializes it. At best, when the APIs change, there will be an addition and the old static code won't fill in everything the runtime expects. At worst, the APIs actually change and the old static code simply won't compile. But this isn't my biggest worry. As you said, we have this same problem with Stubs/Skeletons. What I really worry about is keeping the beans clean and clear of anything that's non-bean, so AXIS can use non-AXIS beans and AXIS beans can be used outside of AXIS. I read your note to Greg. Give me a real-world scenario where the client will need the meta-data. My understanding of the meta-data stuff is that it is necessary for serialization/deserialization, NOTHING MORE. Clients shouldn't get involved in ser/deser. This info is GENERATED code, meaning it came from WSDL. We don't want the client mucking with the meta-data because then they're essentially modifying the WSDL contract. You suggest supporting both a unified model and a separation model, but since the unified model exposes stuff to the client we don't want exposed, I don't think that's a good idea. Russell Butek [EMAIL PROTECTED] Glen Daniels <[EMAIL PROTECTED]> on 03/11/2002 08:47:54 PM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: Bean Class/Bean Class Helper Generation 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) > >
