axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Sauthier (JIRA)" <>
Subject [jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Date Tue, 02 Nov 2004 12:48:33 GMT
     [ ]
Guillaume Sauthier commented on AXIS-1631:

I found that my first patch is not very good !
I remove the entire TypeMapping from the TypeMappingRegistry given the encodingStyle !!
But I don't find a way to remove a pair Class/QName from the TypeMapping class! there is a
register() method, removeSerializer()/removeDeserializer() but no unregister(Class/QName)
Should we add it ?

I'm also working for the usage of MethodCache inside AxisEngine...

> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>          Key: AXIS-1631
>          URL:
>      Project: Axis
>         Type: Bug
>   Components: Deployment / Registries
>     Versions: 1.2RC2
>  Environment: Debian Linux, Java 1.4.2_05, JOnAS 4.2.0
>     Reporter: Guillaume Sauthier
>  Attachments: patch.txt
> I saw in axis sources that when we deploy a service, there are several things done. One
of them is to register type mapping.
> When a service a undeployed, reverse things as done except unregistering type mapping.
> The scenario is the following :
> I create a ClassLoader for each service I deploy (contains the Bean A class), so deploying
a service for the first will create a new ClassLoader (say CL_1), Axis Admin class will merge
my deploy.wsdd into the registry and load my described Beans (say A loaded from CL_1).
> But if I undeploy the service, TypeMapping is not changed, not removed (we're stuck with
Bean A from CL1).
> To finish, I redeploy the same service (creating a new ClassLoader (CL_B)), but TypeMapping
for the service is not changed (Bean A from CL_1). And the following error comes when I call
the deployed service, while deserializing Bean A : DeserializerImpl has created the right
object instance (Bean A from CL_2) but the setter/getter method invoked come from Bean A from
CL_1 !!! And thus, that causes the following IllegalArgumentException !!!

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message