Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-Id: <5.1.0.14.2.20030505121436.02bab480@localhost>
Date: Mon, 05 May 2003 13:16:25 -0500
To: axis-dev@ws.apache.org,
   "'axis-dev@ws.apache.org'" <axis-dev@ws.apache.org>
From: Thomas Sandholm <sandholm@mcs.anl.gov>
Subject: RE: when is trunk going to be available for new features?
In-Reply-To: <CB1FF0A474AEA84EA0206D5B05F6A4CB0255005D@S1001EXM02.macrom
 edia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sorry for the confusion, below is my take on these things.

At 12:18 PM 5/5/2003 -0400, Glen Daniels wrote:
>Hi Thomas!
>
> > I did look into the existing autotyping, and there are two
> > main differences
> > to my approach and the autotyping.
> > 1) I don't assume that a BeanDeserializer is used, but use
> > the meta data
> > generated by WSDL2Java to find deserialization/serialization factories
>
>Wait.  WSDL2Java?  I must be misunderstanding something here.  If you're 
>using WSDL2Java, why are you requiring extra metadata at all?  That's the 
>whole point of WSDL2Java, no?  The reason we put the autoTyping stuff in 
>there is for serializing classes which DON'T have schema types associated 
>with them already... I thought that was what your stuff was doing as well, 
>but apparently not.

Well, we use WSDL2Java to generate types that we then can pass through 
interfaces that have no prior knowledge of these types, e.g. when using 
SOAP intermediaries that can look at the request and even deserialize it if 
they have the stubs compiled in.  In that scenario it becomes a maintenance 
nightmare to update your deployment descriptor to have the correct 
mappings. This problem becomes even more problematic when we want to 
express that a certain service extends other services, then we don't want 
to duplicate the typemapping in the deployment descriptor, and putting the 
common types in the global typemapping space is also very error prone. 
Another use case that is of great importance to us is that we create 
service instances dynamically at run time, and deploy them using 
ServiceDesc.loadServiceDescByIntrospection() in that case you don't have 
any typemappings available at all. If there had been a nice 
ServiceDesc.loadServiceDescFromWSDL() we could have worked around that last 
problem though. So yes in our approach we always have a WSDL description 
available and we generate meta data from that which is kept in the java 
type itself, as opposed to a deployment descriptor. Note I only had to add 
in the xml type qname meta data in addition to what is already generated by 
WSDL2Java.


>Forgetting about that issue for a minute, I certainly think that custom 
>serializers are reasonable on a per-Class basis, and we already have code 
>to do this, which was put in by Rich S. - did you look at that?

Yeah just did, that code assumes that you have a mapping to a base factory 
though. It is as far as I could see not intended for the dynamic scenario 
when you don't have a typemapping, but rather used to get specialized 
(de)serializers as specified in the getDeserializer/getSerializer methods.

>Right now this code is a little confused (some of it is in 
>Base[De]SerializerFactory and some of it is in SerializationContextImpl, 
>for instance), but it does exist and works, looking for getSerializer() 
>and getDeserializer() static methods in the data class.  If we're going to 
>redo this idea we should do it cleanly, consistently, and hopefully 
>backwards-compatibly with the previous version.

I am not proposing redoing the getDeserializer/getSerializer framework, in 
fact I base all my stuff on that. It is just that I don't call these 
methods to find specialized (de)serializers, I call them to find a 
(de)serializer if none was found through the conventional type mappings. It 
just didn't make sense to me seeing Axis throw an exception that no 
serializer was found for a class when there was a nice getSerializer() 
method on that very same class, which is why I went down this road. I in 
fact already added one call out to these a while back in the existing Axis 
code base in the SerializationContextImpl class. So dynamic serialization 
using this approach is already supported by Axis to some extent.


> > 2) My dynamic deserialization can coexist with manual type
> > mappings. It
> > only kicks in if no typemapping was found (in which case in
> > the existing
>
>This is exactly the way autoTyping works as well.  Explicit mapping always 
>wins.

ok


> > code base an exception is thrown). And no extra flag has to
> > be set to make
> > use of it.
>
>The flag setting for autoTyping is merely because some people don't want 
>automatic type mapping happening because they want tighter control over 
>which classes are exposed as XML and how they are mapped.  I think the 
>flag should still be available no matter how we do this stuff, but I'm 
>fine with making the default "on" instead of "off".

oh ok I see, yes then we probably want to do the same for this new 
serialization/deserialization

> > On your XML Type QName questions.
> > On the serialization side:
> > I changed the WSDL2Java emitters to add in the XMLType in the
> > meta data of
> > the type (not sure why this was not done before). That is
> > what the dynamic
> > serializer looks up at runtime. Seems to work pretty well, even with
> > polymorphic types.
>
>Again, I'm having trouble seeing the use-case here when using WSDL2Java, 
>since you already have all the metadata available...?

Well that is exactly the point. All the metadata is available in the type 
as well as in the deployment descriptor but the meta data in the type is 
never used if the deployment descriptor meta data is missing. That is in 
essence what I tried to fix with my approach. For use cases see my answers 
above. The reason we are hitting this problem is that we have taken a 
doc/literal approach to passing around types in the system (possibly 
through gateways with limited type knowledge), and we have very generic 
interfaces used as primitives to compose services. Looking at .NET where 
they took a similar approach they also make use of the meta data 
associated/compiled in with the types to perform 
serialization/deserialization. This is also related to the xsd:any mapping 
to Java and how to get at the object value of a SOAPElement in a flexible 
manner.


> > On the deserialization side:
> > The class name to be used to deserialize the xml type can be
> > set in the
> > deserialization context. The two main users of this feature are the
> > RPCHandler which sets it based on the parameter types in the
> > operation, and
> > the BeanDeserializer which sets it based on the bean
> > properties. One thing
> > to note is that the dynamic deserialization does not work
> > with polymorphic
> > types. In that case you need to set up typemappings
> > explicitly for the
> > correct derived type to be constructed. I also added a new API to the
> > MessageElement to allow you to pass in the class you want to
> > deserialize it
> > into.
>
>Like getValueAsType, but with a Class instead of an XML type Qname.  Seems 
>right (we've already got this pattern in the 
>Call.setReturnClass()/setReturnType() APIs).
>
>What we need here, I think, is succinct english descriptions of how we 
>want this to work, and then code which follows that spec.  I'd like to see 
>that happen before Yet Another Way To Do Things gets merged in.


Ok I can write something up for review, if you think it makes sense given 
what I have described in this mail.


> > I think this dynamic deserialization/serialization deprecates
> > the existing
> > autotyping, and I have a hard time seeing any features in the
> > existing
> > autotyping that are not covered in the new dynamic deserialization
> > approach. Do you have any test cases for it that I could run?
> > And would you
> > be ok with me dropping it if the test cases run through fine
> > with the new
> > approach? They both coexist nicely now so I can obviously
> > wait for your
> > review of the new stuff before removing the autoTyping.
>
>I don't so much want them to coexist, I want there to be one clean and 
>correct way in which we do this stuff. :)

ok it seems to me now that we are solving two slightly different problems 
if you use it for beans without meta data. I on the other hand assume that 
you always have meta data in the beans or whatever other types WSDL2Java 
generates.

/Thomas


>I need to look around re: test cases; I don't think many people are using 
>the autoTyping stuff right now, so it's probably not a big deal to change 
>it (though we should ping axis-user about it).
>
>--Glen