axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignacio J. Ortega" <na...@siapi.es>
Subject RE: when is trunk going to be available for new features?
Date Mon, 05 May 2003 18:24:55 GMT


> -----Original Message-----
> From: Thomas Sandholm [mailto:sandholm@mcs.anl.gov]
> Sent: Monday, May 05, 2003 8:16 PM
> To: axis-dev@ws.apache.org; 'axis-dev@ws.apache.org'
> Subject: RE: when is trunk going to be available for new features?
> 
> 
> 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
> 

Mime
View raw message