Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 91672 invoked by uid 500); 11 Mar 2002 22:33:16 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 91663 invoked from network); 11 Mar 2002 22:33:16 -0000 Subject: Re: Bean Class/Bean Class Helper Generation To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Richard Sitze" Date: Mon, 11 Mar 2002 16:32:34 -0600 X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Release 5.0.9a |January 7, 2002) at 03/11/2002 05:33:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N +1 to stepping back and designing (ie. cease code-checking on current direction) It's critical that we isolate JAX-RPC implementation details (Meta-data) from the classes exposed to the user. We need a design that reflects this in place ASAP, and we need to be writing to the design to minimize unnecessary rework later. I'm all for refactoring, but I'm even more for starting off on the right foot for the users. If we expose the meta-data to the users, we are going to regret it... +1 on an interface. +0 on this specific interface. Those who are dealing with this section of code need to agree on this. ******************************************* Richard A. Sitze rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development R J Scheuerle Jr/Austin/IBM@IB To: axis-dev@xml.apache.org MUS cc: Subject: Bean Class/Bean Class Helper Generation 03/11/2002 04:14 PM Please respond to axis-dev 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)