What I meant was that I think it's interesting that you could potentially have a "deployment-free" type mapping if you introspect the class and find that it knows how to serialize itself (and knows it's XML type). The same is clearly not true of deserialization without some kind of registration process (though there is an interesting possibility there too involving static intializers which register mappings).
I do not think it's a good idea to allow a class to override an existing typemapping - this will cause a ton of headaches. This is perhaps somewhat analagous to the Skeleton/WSDD dichotomy... Russell and I discussed this and we both agree that if a service has BOTH WSDD-based service metadata AND a Skeleton it should be a fault, because otherwise someone is going to get confused at some point when their [wsdd/skeleton] doesn't do what they expect it to. In a similar vein, I don't think that we should "surprise" people with custom serializers when they've explicitly mapped classes to particular ones. So I guess I'd like to see mappings which specify "real" ser/deser classes be respected, and ones which specify "ask the class" would use the custom ones. Does that make sense? --Glen > -----Original Message----- > From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 28, 2002 4:09 PM > To: [EMAIL PROTECTED] > Subject: RE: getSerializer/getDeserilizer methods in the Bean > > > My intent was not to change the TypeMapping. The TypeMapping > information > is used for other reasons beyond getting the > serializer/deserializer (i.e. > getting the qname <-> javaType mapping). > > Rich Scheuerle > XML & Web Services Development > 512-838-5115 (IBM TL 678-5115) > > > > > Glen Daniels > > <gdaniels@macrome To: > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > dia.com> cc: > > Subject: RE: > getSerializer/getDeserilizer methods in the Bean > > 03/28/2002 12:37 > > PM > > Please respond to > > axis-dev > > > > > > > > > > So you still have to do a registration in the TypeMapping > which says "use > the base ser/deser"? > > > -----Original Message----- > > From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, March 28, 2002 1:36 PM > > To: [EMAIL PROTECTED] > > Subject: RE: getSerializer/getDeserilizer methods in the Bean > > > > > > Both methods provide a place to get custom serializer/deserializer. > > > > In both cases the Base(De)SerializerFactory looks for these > > methods to get > > the serializer /deserializer. > > > > Rich Scheuerle > > XML & Web Services Development > > 512-838-5115 (IBM TL 678-5115) > > > > > > > > > > Glen Daniels > > > > <gdaniels@macrome To: > > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > > > dia.com> cc: > > > > Subject: RE: > > getSerializer/getDeserilizer methods in the Bean > > > > 03/28/2002 12:20 > > > > PM > > > > Please respond to > > > > axis-dev > > > > > > > > > > > > > > > > > > > > Interesting stuff! > > > > So, I get how getSerializer() might work - you've got a Class you're > > serializing, so you can just use that instead of going to the > > TypeMapping. > > > > I don't understand getDeserializer, though - when > could/would that get > > used? > > > > --Glen > > > > > -----Original Message----- > > > From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, March 28, 2002 1:15 PM > > > To: [EMAIL PROTECTED] > > > Subject: getSerializer/getDeserilizer methods in the Bean > > > > > > > > > Some cool changes I am working on. > > > > > > I am adding getSerializer/getDeserializer methods in the > > java bean (or > > > _Helper). > > > > > > These methods construct the corresponding > > > serializer/deserializer (passing > > > in the TypeDesc meta data). > > > > > > This change prevents unnecessary introspection and gives > > > users a place to > > > hang their own custom serializer/deserializer. > > > > > > I also made some cosmetic changes to make it easier to extend > > > some of these > > > classes. > > > > > > Rich Scheuerle > > > XML & Web Services Development > > > 512-838-5115 (IBM TL 678-5115) > > > > > > > > > > > >
