Maybe I need to be a little more clear about what is happening.
Lets suppose a typeMapping is registered for the Foo.class that is mapped
to org.apache.axis.encoding.ser.BeanSerializerFactory.
So when a Foo needs to be serialized, the BeanSerializerFactory class is
obtained from the TypeMapping.
The BeanSerializerFactory.getSerializerAs() method is invoked .
The BeanSerializerFactory first looks for a getSerializer method on the Foo
class (or its Helper class).
- If it finds the method it invokes it to get the serializer (which
will be the BeanSerializer with meta data attached)
- If it doesn't find it, the default behavior is the construct a
BeanSerializer and return it.
(The analagous processing happens for the Deserializer).
Now if the user wanted to point to their own serializer they can:
- Register a typeMapping with their provided serializer factory which
locates their serializer.
- Or they can provide a getSerializer method in their class.
Does this make more sense.
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 03:20
PM
Please respond to
axis-dev
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)
> > >
> >
> >
> >
>
>
>
