You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Ron Reynolds <Ro...@RonReynolds.com> on 2005/10/05 22:55:06 UTC

serializer being overwritten

ok, so i'm trying to register a custom serializer and appearantly i have the right entry in my client-config.wsdd
because i see the call to TypeMappingImpl.internalRegister() with my ser factory when the locator is first created. 
but then on the very first call i see this:
SOAPHTTPBindingStub.createCall() (ln:379)
-> Call.registerTypeMapping() (ln:2303)
-> Call.registerTypeMapping() (ln:2266)
-> TypeMappingDelegate.register() (ln:73)
-> TypeMappingImpl.register() (ln:220)
-> TypeMappingImpl.internalRegister()
and lo and behold it's overwriting my mapping with the BeanSerializerFactory! :(
looking back through the Axis code the only thing i can see that might prevent this is this code in my
SOAPHTTPBindingStub:

                    for (int i = 0; i < cachedSerFactories.size(); ++i) {
                        java.lang.Class cls = (java.lang.Class) cachedSerClasses.get(i);
                        javax.xml.namespace.QName qName =
                                (javax.xml.namespace.QName) cachedSerQNames.get(i);
                        java.lang.Object x = cachedSerFactories.get(i);
                        if (x instanceof Class) {
                            java.lang.Class sf = (java.lang.Class)
                                 cachedSerFactories.get(i);
                            java.lang.Class df = (java.lang.Class)
                                 cachedDeserFactories.get(i);
                            _call.registerTypeMapping(cls, qName, sf, df, false); // line 379
                        }

so if i can prevent this cachedSerFactories guy from containing anything this code won't stomp on my mapping. 
question is - how do i prevent this?  will continue hunting but hoping someone has already solved this... :-/

..................ron.



Re: serializer being overwritten

Posted by Ron Reynolds <Ro...@RonReynolds.com>.
ok, so wsdl2java-generated code created the cachedSerFactories list.  so if i want a custom serializer/deserializer am
i supposed to change the generated stub code?  that does NOT seem right at all...  if that was the way to do it then
what's the point of the client-config.wsdd file?

> ok, so i'm trying to register a custom serializer and appearantly i have the right entry in my client-config.wsdd
> because i see the call to TypeMappingImpl.internalRegister() with my ser factory when the locator is first created.
> but then on the very first call i see this:
> SOAPHTTPBindingStub.createCall() (ln:379)
> -> Call.registerTypeMapping() (ln:2303)
> -> Call.registerTypeMapping() (ln:2266)
> -> TypeMappingDelegate.register() (ln:73)
> -> TypeMappingImpl.register() (ln:220)
> -> TypeMappingImpl.internalRegister()
> and lo and behold it's overwriting my mapping with the BeanSerializerFactory! :(
> looking back through the Axis code the only thing i can see that might prevent this is this code in my
> SOAPHTTPBindingStub:
>
>                     for (int i = 0; i < cachedSerFactories.size(); ++i) {
>                         java.lang.Class cls = (java.lang.Class) cachedSerClasses.get(i);
>                         javax.xml.namespace.QName qName =
>                                 (javax.xml.namespace.QName) cachedSerQNames.get(i);
>                         java.lang.Object x = cachedSerFactories.get(i);
>                         if (x instanceof Class) {
>                             java.lang.Class sf = (java.lang.Class)
>                                  cachedSerFactories.get(i);
>                             java.lang.Class df = (java.lang.Class)
>                                  cachedDeserFactories.get(i);
>                             _call.registerTypeMapping(cls, qName, sf, df, false); // line 379
>                         }
>
> so if i can prevent this cachedSerFactories guy from containing anything this code won't stomp on my mapping.
> question is - how do i prevent this?  will continue hunting but hoping someone has already solved this... :-/
>
> ..................ron.
>
>
>