You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org> on 2004/10/28 15:01:32 UTC
[jira] Created: (AXIS-1631) Missing TypeMapping removal when undeploy service
Missing TypeMapping removal when undeploy service
-------------------------------------------------
Key: AXIS-1631
URL: http://issues.apache.org/jira/browse/AXIS-1631
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
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1631?page=comments#action_54747 ]
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: http://issues.apache.org/jira/browse/AXIS-1631
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1631?page=comments#action_54874 ]
Davanum Srinivas commented on AXIS-1631:
----------------------------------------
Guillaume,
Does this patch resolve all issues? (including the MethodCache problem?) maybe we can store the MethodCache as a member of AxisEngine?
thanks,
dims
> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>
> Key: AXIS-1631
> URL: http://nagoya.apache.org/jira/browse/AXIS-1631
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1631?page=history ]
Guillaume Sauthier updated AXIS-1631:
-------------------------------------
Attachment: patch.txt
undeploy typeMappings (first try ;))
> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>
> Key: AXIS-1631
> URL: http://issues.apache.org/jira/browse/AXIS-1631
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1631?page=comments#action_54740 ]
Guillaume Sauthier commented on AXIS-1631:
------------------------------------------
The stackTrace :
2004-10-28 11:34:58,762 : BeanPropertyTarget.set : Could not convert java.lang.Integer to bean field 'areaCode', type int
2004-10-28 11:34:58,795 : AxisServlet.processAxisFault : AxisFault:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.lang.IllegalArgumentException: object is not an instance of declaring class
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.axis.utils.BeanPropertyDescriptor.set(BeanPropertyDescriptor.java:117)
at org.apache.axis.encoding.ser.BeanPropertyTarget.set(BeanPropertyTarget.java:89)
at org.apache.axis.encoding.DeserializerImpl.valueComplete(DeserializerImpl.java:248)
at org.apache.axis.encoding.DeserializerImpl.endElement(DeserializerImpl.java:511)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1077)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:845)
at org.apache.axis.encoding.DeserializerImpl.startElement(DeserializerImpl.java:371)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1038)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:159)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:845)
at org.apache.axis.encoding.DeserializerImpl.startElement(DeserializerImpl.java:371)
at org.apache.axis.encoding.ser.BeanDeserializer.startElement(BeanDeserializer.java:130)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1038)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:159)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:845)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:198)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:323)
at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:146)
at bpel.engine.BPELProvider.processMessage(BPELProvider.java:109)
at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:455)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:285)
at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:301)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:239)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:268)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:157)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:50)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:140)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:136)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>
> Key: AXIS-1631
> URL: http://issues.apache.org/jira/browse/AXIS-1631
> 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
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1631?page=comments#action_55082 ]
Guillaume Sauthier commented on AXIS-1631:
------------------------------------------
Using MethodCache inside AxisEngine seems to be not so easy to implements !
Because the classes that uses MethodCache do not have a handle to the current AxisEngine.
Is there a way to get the current AxisEngine in a static way ? (something that looks like AxisEngine.getCurrentEngine())
I tried MessageContext.getCurrentMessageContext().getEngine() but the only things I got was NPE !
Simple solution is the static Map in MethodCache.
> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>
> Key: AXIS-1631
> URL: http://nagoya.apache.org/jira/browse/AXIS-1631
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1631?page=comments#action_54929 ]
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) method.
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: http://nagoya.apache.org/jira/browse/AXIS-1631
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Guillaume Sauthier (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1631?page=comments#action_54920 ]
Guillaume Sauthier commented on AXIS-1631:
------------------------------------------
This patch doesn't resolve the methodCache problem.
It's just the undeployment of typeMappings in WSDDDeployment and WSDDService.
Before creating a patch for MethodCache (using a static Map instead of a ThreadLocal), I want to know if there is any reason to keep the ThreadLocal ?
> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>
> Key: AXIS-1631
> URL: http://nagoya.apache.org/jira/browse/AXIS-1631
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1631) Missing TypeMapping removal when undeploy service
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1631?page=comments#action_54930 ]
Davanum Srinivas commented on AXIS-1631:
----------------------------------------
yes, please. you can do whatever it takes :)
-- dims
> Missing TypeMapping removal when undeploy service
> -------------------------------------------------
>
> Key: AXIS-1631
> URL: http://nagoya.apache.org/jira/browse/AXIS-1631
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira