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 Thu, 28 Oct 2004 16:07:32 GMT
     [ ]
Guillaume Sauthier commented on AXIS-1631:

I have a first patch that undeploy the typeMappings

but that's not completely satisfacting because our problem is not resolved (see scenario)
We have found that all comes from MethodCache (it seems :) )!
Each Thread try to cache the Method to avoid reflection, and when we undeploy the Services,
we cannot reset the cache (no resetCache).
Even is we implements this method, that fails (randomly, depending on the thread that execute
our request) because it use a ThreadLocal to store data !!!

That leads me to a question, why are you using ThreaLocal ? Why not using a simple static
field instead ? concurrent modifications ? in my mind, using a single Map (1 for the entire
JVM) instead of multiple Map (1 for each Thread) is faster for caching ??

I attach the patch right now ...

> 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