axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: Bean Class/Bean Class Helper Generation
Date Mon, 11 Mar 2002 22:42:02 GMT

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.

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

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.


> -----Original Message-----
> From: R J Scheuerle Jr []
> Sent: Monday, March 11, 2002 5:15 PM
> To:
> 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)

View raw message