October 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-2188) java.lang.ClassNotFoundException: while deserializing on EJB 3.0 postactivate (SimpleStatefulCache) while doing HTTP Session Logot

by Dhaneesh Nair (JIRA)

java.lang.ClassNotFoundException: while deserializing on EJB 3.0 postactivate (SimpleStatefulCache) while doing HTTP Session Logot ----------------------------------------------------------------------------------------------------------------------------------- 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 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 the UI is been intercepted 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 yeat 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 befor 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
12
0 / 0

[JBoss JIRA] Created: (JBRULES-2756) fireUntilHalt is doing busy wait and consuming 100% of one CPU core

by Edson Tirelli (JIRA)

fireUntilHalt is doing busy wait and consuming 100% of one CPU core ------------------------------------------------------------------- Key: JBRULES-2756 URL: https://jira.jboss.org/browse/JBRULES-2756 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL, 5.1.0.FINAL Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.2.0.M1 Analysis by Greg Barton: ========================= The problem is the race condition fix introduced in rev 30163. The missedNotifyAll flag is set to true immediately which causes the busy loop. missedNotifyAll is initialized to false, but is immediately set to true because notifyHalt() is called in AbstractWorkingMemory.queueWorkingMemoryAction() via ReteooRuleBase.newStatefulSession(). Anyway, I'll move discussions of possible solutions over to the dev list, (crossposting now) or a JIRA if you'd prefer that. Here's a diff for the minimal change I think fixes the problem: Index: src/main/java/org/drools/common/DefaultAgenda.java =================================================================== --- src/main/java/org/drools/common/DefaultAgenda.java (revision 35727) +++ src/main/java/org/drools/common/DefaultAgenda.java (working copy) @@ -1048,10 +1048,10 @@ boolean fired = fireNextItem( agendaFilter ); fired = fired || !((AbstractWorkingMemory) this.workingMemory).getActionQueue().isEmpty(); this.workingMemory.executeQueuedActions(); - if ( !fired && !missedNotifyAll.get()) { + if ( !fired ) { try { synchronized ( this.halt ) { - this.halt.wait(); + if(!missedNotifyAll.get()) this.halt.wait(); } } catch ( InterruptedException e ) { this.halt.set( true ); Basically, move the missedNotifyAll check immediately before the wait. This still avoids the race condition, and only causes one spurious trip through the fireUntilHalt loop on startup. I'd open a JIRA with this in it but I need to get to sleep. :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2186) RemoteBinding annotation not overridden by subclass

by Jason Shepherd (JIRA)

RemoteBinding annotation not overridden by subclass --------------------------------------------------- Key: EJBTHREE-2186 URL: https://jira.jboss.org/browse/EJBTHREE-2186 Project: EJB 3.0 Issue Type: Bug Components: jndi Environment: EAP 5.1.0 with has dependencies on: jboss/jboss-j2ee - 4.0.2 org.jboss.ejb3.bom - 1.0.1 Reporter: Jason Shepherd Two EJBs (defined below) are throwing an JNDI Binding exception when deploying the application. Please see Binding exception below the EJB definitions. And see the support ticket for more details. EJB definitions: DefaultEntityServicesBean ------------------------- @Stateless @Remote(EntityServices.class) @RemoteBinding(jndiBinding="SCMA/Bean/EntityServices") @Pool(value="StrictMaxPool", maxSize=15) public class DefaultEntityServicesBean<T extends Entity> extends DefaultServicesBean implements EntityServices<T>, Serializable DefaultVesselServicesBean ------------------------- @Stateless @Remote(VesselServices.class) @RemoteBinding(jndiBinding="SCMA/Bean/VesselServices") @Pool(value="StrictMaxPool", maxSize=15) public class DefaultVesselServicesBean extends DefaultEntityServicesBean<Vessel> implements VesselServices, Serializable Server log output: DefaultEntityServicesBean Registration: jvm 1 | main 10:26:45,062 INFO [SessionSpecContainer line:296] Starting jboss.j2ee:ear=sifews.ear,jar=mscore_ws.jar, name=DefaultEntityServicesBean,service=EJB3 jvm 1 | main 10:26:45,062 INFO [EJBContainer line:296] STARTED EJB: org.dsta.cma.mscorex.services.bean.DefaultEntity ServicesBean ejbName: DefaultEntityServicesBean jvm 1 | main 10:26:45,093 INFO [JndiSessionRegistrarBase line:296] Binding the following Entries in Global JNDI: jvm 1 | jvm 1 | SCMA/Bean/EntityServices - EJB3.x Default Remote Business Interface jvm 1 | sifews/DefaultEntityServicesBean/remote-org.dsta.cma.mscorex.services.EntityServices - EJB3.x Remote Bus DefaultVesselServicesBean Attempted Registration: main 10:26:45,171 INFO [SessionSpecContainer line:296] Starting jboss.j2ee:ear=sifews.ear,jar=mscore_ws.jar, name=DefaultVesselServicesBean,service=EJB3 jvm 1 | main 10:26:45,171 INFO [EJBContainer line:296] STARTED EJB: org.dsta.cma.mscorex.services.bean.DefaultVessel ServicesBean ejbName: DefaultVesselServicesBean jvm 1 | main 10:26:45,203 INFO [JndiSessionRegistrarBase line:296] Binding the following Entries in Global JNDI: jvm 1 | jvm 1 | SCMA/Bean/VesselServices - EJB3.x Default Remote Business Interface jvm 1 | SCMA/Bean/EntityServices - EJB3.x Default Remote Business Interface jvm 1 | sifews/DefaultVesselServicesBean/remote-org.dsta.cma.mscorex.services.VesselServices - EJB3.x Remote Bus iness Interface jvm 1 | sifews/DefaultVesselServicesBean/remote-org.dsta.cma.mscorex.services.EntityServices - EJB3.x Remote Bus iness Interface jvm 1 | jvm 1 | main 10:26:45,203 INFO [SessionSpecContainer line:296] Stopping jboss.j2ee:ear=sifews.ear,jar=mscore_ws.jar, name=DefaultVesselServicesBean,service=EJB3 jvm 1 | main 10:26:45,203 INFO [EJBContainer line:296] STOPPED EJB: org.dsta.cma.mscorex.services.bean.DefaultVessel ServicesBean ejbName: DefaultVesselServicesBean jvm 1 | main 10:26:45,218 ERROR [AbstractKernelController line:419] Error installing to Start: name=jboss.j2ee:ear=si fews.ear,jar=mscore_ws.jar,name=DefaultVesselServicesBean,service=EJB3 state=Create jvm 1 | java.lang.RuntimeException: Could not bind Reference Class Name: Proxy for: org.dsta.cma.mscorex.services.Ves selServices, org.dsta.cma.mscorex.services.EntityServices jvm 1 | Type: ProxyFactoryKey jvm 1 | Content: ProxyFactory/sifews/DefaultVesselServicesBean/SCMA/Bean/EntityServices jvm 1 | Type: EJB Container Name jvm 1 | Content: jboss.j2ee:ear=sifews.ear,jar=mscore_ws.jar,name=DefaultVesselServicesBean,service=EJB3 jvm 1 | Type: Proxy Factory is Local jvm 1 | Content: false jvm 1 | Type: Remoting Host URL jvm 1 | Type: Remote Business Interface jvm 1 | Content: org.dsta.cma.mscorex.services.VesselServices jvm 1 | Type: Remote Business Interface jvm 1 | Content: org.dsta.cma.mscorex.services.EntityServices jvm 1 | into JNDI at "SCMA/Bean/EntityServices" ... jvm 1 | Caused by: javax.naming.NameAlreadyBoundException: EntityServices -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-8031) Update JBossTS to 4.11

by Jonathan Halliday (JIRA)

Update JBossTS to 4.11 ---------------------- Key: JBAS-8031 URL: https://jira.jboss.org/browse/JBAS-8031 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Manager (Arjuna) Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 6.0.0.M4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2697) Description not in documentation

by Tomáš Schlosser (JIRA)

Description not in documentation -------------------------------- Key: JBRULES-2697 URL: https://jira.jboss.org/browse/JBRULES-2697 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.1.1.FINAL Environment: jboss-eap-5.1 brms-guvnor 5.1.0 35066 Reporter: Tomáš Schlosser Assignee: Mark Proctor Although description is set in rules it doesn't appear in documentation generated by Guvnor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2757) It is possible to delete a snapshot by copying it to itself

by Tihomir Surdilovic (JIRA)

It is possible to delete a snapshot by copying it to itself ----------------------------------------------------------- Key: JBRULES-2757 URL: https://jira.jboss.org/browse/JBRULES-2757 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL Reporter: Tihomir Surdilovic Assignee: Mark Proctor If you want to copy a snapshot to an existing one, BRMS deletes the target first and than replaces it with the snapshot that is being copied. This fails if you choose the snapshot that you want to copy as a target. Since the target is deleted first and it is the source at the same time, nothing is left to copy and the original snapshot is lost. To avoid the user doing this unintentionally, the source snapshot shouldn't be made available as the target for the copy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBJCA-426) Track component updates

by Jesper Pedersen (JIRA)

Track component updates ----------------------- Key: JBJCA-426 URL: https://jira.jboss.org/browse/JBJCA-426 Project: IronJacamar Issue Type: Task Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBJCA-437) Ivy 2.2.0

by Jesper Pedersen (JIRA)

Ivy 2.2.0 --------- Key: JBJCA-437 URL: https://jira.jboss.org/browse/JBJCA-437 Project: IronJacamar Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBJCA-454) IronJacamar 1.0.0.Beta3

by Jesper Pedersen (JIRA)

IronJacamar 1.0.0.Beta3 ----------------------- Key: JBJCA-454 URL: https://jira.jboss.org/browse/JBJCA-454 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta3 Release notes: https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBJCA-443) Refactor RaXmlDeployer and DsXmlDeployer

by Stefano Maestri (JIRA)

Refactor RaXmlDeployer and DsXmlDeployer ---------------------------------------- Key: JBJCA-443 URL: https://jira.jboss.org/browse/JBJCA-443 Project: IronJacamar Issue Type: Task Reporter: Stefano Maestri Assignee: Stefano Maestri Fix For: 1.0.0.Beta3 We need to refactor these classes to extend an Abstract class not depending from fungal doing the important part of the job. That abstract class will be extended in AS7 too with its specific implementation and dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2010