[jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-2188) java.lang.ClassNotFoundException on EJB 3.0 postactivate (SimpleStatefulCache) while doing HTTP Session Logout

java.lang.ClassNotFoundException on EJB 3.0 postactivate (SimpleStatefulCache) while doing HTTP Session Logout ---------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2188 URL: https://jira.jboss.org/browse/EJBTHREE-2188 Project: EJB 3.0 Issue Type: Bug Components: cache Affects Versions: EJB3_1 1.0.4 Environment: We are using JBOSS AS 4.2.3 and Seam with jdk6 Reporter: Dhaneesh Nair Assignee: jaikiran pai Fix For: EJB3_1 1.0.4 A java.lang.ClassNotFoundException: is thrown while doing an http session logout for the components which are passivated. JBoss is throwing class not found exception in the postactivate task of JBOSS while doing the session logoff with SimpleStatefulCache. This is occuring while doing a logoff from the UI .The exact scenario to reproduce is as below. Step 1: Allow any bean to get passivated which is there in the HTTP Session context. Step 2: Do a log off from the UI. The logoff event is coming from UI is been intercepted by Stateful interceptors and try to destroy the session beans. At this time JBOSS is trying to remove the beans from the local cache which are not been passivated yet as well as the passivated beans. If the bean is passivated,it has to activate it before the removal task. For this it uses the activate method inside the corresponding cache implementation. Our cache configuration is SimpleStatefulCache. Now JBOSS actually has to deserialize the object which is serialized before as part of the passivate task.I will paste the passivate code snippet here to get it clarified. protected void passivate(StatefulBeanContext ctx) { ClassLoader oldCl = Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(((EJBContainer) ctx.getContainer()).getClassloader()); pm.passivateSession(ctx); ++passivatedCount; } finally { Thread.currentThread().setContextClassLoader(oldCl); } } Here JBOSS sets the current class loader as the corresponding EJBContainer class loader before going for a serialization of the bean which is perfectly fine. But before doing a post activate method there is no code which sets the current class loader .There it is not require for the case in which the activate call comes from the same container contexts like corresponding applications web context. But when the HTTP Session timeout is getting dispatched from the root class loader which is the Webapp class loader (org.apache.catalina.loader.WebappClassLoader). Now the Individual applications class loaders are below this root class loader and the classes loader by these children are not available to the root according to classloader visibility and delegations principles. This makes the application to throw a ClassNotFoundException at this time. The issue is primarily with the class loader user while doing the operation. The classloader which is used while doing the normal serialization and deserialization of objects from UI is the WebContext class loader which has the access to all the beans loaded. While logout the class loader is org.apache.catalina.loader.WebappClassLoader which doesnot have the loaded beans. I have tried to fix this problem by setting the Classloader as the EJBContainer class loader before postactivate call and it worked. Fix Suggession from me : Create a static field in SimpleStatefulCache with type as HashMap(<String>,<ClassLoader>) The key is the StatefulBeanContext id's which are uniqely identifies the session beans. In the protected void passivate(StatefulBeanContext ctx) method put the ClassLoader evaluated from the expression (EJBContainer) ctx.getContainer()).getClassloader() to the map against the key ctx.getId() . On the get method of SimpleStatefulCache get the classLoader corresponding to this key before doing the activateSession() call. Keep the current classloader to a temp variable and set the classloader as the one which got from the map. Now , immediately after this call set the current thread classloader as the one stored in the temp variable. Remove the map entry on the remove method for cleaning memory. I have tried this and worked it.