axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject RE: Bean Class/Bean Class Helper Generation
Date Tue, 12 Mar 2002 01:36:49 GMT
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
butek@us.ibm.com


Tom Jordahl <tomj@macromedia.com> on 03/11/2002 05:00:34 PM

Please respond to axis-dev@xml.apache.org

To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
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:scheu@us.ibm.com]
Sent: Monday, March 11, 2002 5:15 PM
To: axis-dev@xml.apache.org
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)



Mime
View raw message