> Actually, I think the empty interfaces are not the problem. It seems to me that they are just marker interfaces for subclassing whatever [de]serializer(s) you want to use and store in a TypeMappingRegistry.
Well, they're a syptom of a deeper problem--JAX-RPC doesn't specify the semantics of the serializers/deserializers. So even if you *could* register them, there's no guarantee in general that the run-time framework will know what to do with them. For example, I'm not sure that the JAX-RPC RI would know what to do with an Axis serializer. > IMHO, this seems to be a shortcoming of the JAXRPC standard. If web services are to become widely adopted, I think that developers need a "plug and play" approach to [de]serialization that encourages a market for such tools to develop. It doesn't seem to be high priority for JAX-RPC 2.0 either: http://jcp.org/en/jsr/detail?id=224 - Rob > -----Original Message----- > From: Robert Lowe [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 26, 2003 3:22 PM > To: [EMAIL PROTECTED] > Subject: Re: accessing the TypeMappingRegistry in a JAXRPC > implemenation > > > JAX-RPC 1.0/1.1 defines Serializer and Deserializer > interfaces. However, > both are empty except for a getMechanismType() method that > returns a String. > The meaning of the return value is not defined. > > In other words, you're out of luck. :-( > > - Rob > > > ----- Original Message ----- > From: "Anne Thomas Manes" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, July 26, 2003 8:50 PM > Subject: Re: accessing the TypeMappingRegistry in a JAXRPC > implemenation > > > > Mark, > > > > I don't believe that the JAX-RPC spec defines a standard > way to do custom > > [de]serialization. The Axis classes are used by many vendors (IBM, > Borland, > > Macromedia, Pramati, etc), but I wouldn't say that it has > been established > > as a defacto standard. There are lots of other > implementations that use > > their own classes. > > > > Anne > > > > ----- Original Message ----- > > From: "Mark D. Hansen" <[EMAIL PROTECTED]> > > To: "AXIS Users (E-mail)" <[EMAIL PROTECTED]> > > Sent: Friday, July 25, 2003 11:13 PM > > Subject: accessing the TypeMappingRegistry in a JAXRPC implemenation > > > > > > > Not much is going on on the JAXRPC-INTEREST discussion, > so I'm also > > > posting this here. I hope it is not considered too "off topic". > > > > > > > -----Original Message----- > > > > From: Public discussion on JAX-RPC > > > > [mailto:[EMAIL PROTECTED] Behalf Of Mark D. Hansen > > > > Sent: Friday, July 25, 2003 6:37 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: accessing the TypeMappingRegistry in a JAXRPC > implemenation > > > > > > > > > > > > I am looking for a way to do custom > > > > serialization/deserialization that will run on any JAXRPC > > > > runtime implementation in a Servlet container. Is this > > > > possible? I would think that you could get to the > > > > TypeMappingRegistry for a service endpoint by implementing > > > > the service with the ServiceLifecycle interface and getting > > > > the endpoint's MessageContext from the implementation > > > > supplied ServletEndpointContext. But, I see that > > > > javax.xml.rpc.handler.SOAPMessageContext does not define a > > > > getTypeMappingRegistry() method. > > > > > > > > Does this mean that JAXRPC does not define a standard way for > > > > developers to access the TypeMappingRegistry of a > service endpoint? > > > > > > > > BTW, I notice that the Axis implemenation of > > > > SOAPMessageContext (org.apache.axis.MessageContext) does in > > > > fact have a getTypeMappingRegistry() method. Is this a "de > > > > facto" standard approach that other implementations use? > > > > > > > > Thanks for your help, > > > > > > > > Mark > > > > > > > > > >
