Just FYI, the TypeDesc stuff also allows us to arbitrarily map Java fields to full XML QNames and vice-versa, which is a feature that doc/lit services often require.
I think the general idea of being able to tease the TypeDesc out from the bean class is a great one, and that's precisely why the TypeDesc.getTypeDescForClass() API is in there. Right now, that code just looks for a static getTypeDesc() API, but it could easily be changed to do what you suggest (look for a Helper class), or do what I'd rather see, namely look for a mapping descriptor file in the classpath right next to the class in question. i.e.: com/bigCo/DataBean.class com/bigCo/DataBean.typeDesc (an XML or other text file containing mapping info) For now, I think the current mechanism is OK (it's easy to write by hand if you want, and is mostly used in generated code anyway), but I agree we should move towards more flexibility later. A side note - I don't see why you want to tie serialization/deserialization mappings to the type metadata. If you want custom serializers/deserializers, shouldn't that happen when you do your type mapping registrations? Seems better to decouple these too, I would think. --Glen > -----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) >
