January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Assigned: (JBAOP-256) java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$... was pruned

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-256?page=all ] Flavia Rainone reassigned JBAOP-256: ------------------------------------ Assignee: Flavia Rainone > java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$... was pruned > --------------------------------------------------------------------------------------------------------- > > Key: JBAOP-256 > URL: http://jira.jboss.com/jira/browse/JBAOP-256 > Project: JBoss AOP > Issue Type: Bug > Affects Versions: 1.5.0.GA > Reporter: Ovidiu Feodorov > Assigned To: Flavia Rainone > > Messaging build fails at the AOPC phase if we dont' do a full clean after modifying advised clases. > An example of exception that is thrown by the AOPC in such cases follows: > compile-classes: > [javac] Compiling 1 source file to C:\work\src\cvs\jboss-head\jms\output\classes > [aopc] java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$close_N4742752445160157748 was pruned. > [aopc] at javassist.CtClassType.checkPruned(CtClassType.java:1093) > [aopc] at javassist.CtClassType.defrost(CtClassType.java:272) > [aopc] at org.jboss.aop.instrument.OptimizedInvocations.defrostClassIfExists(OptimizedInvocations.java:66) > [aopc] at org.jboss.aop.instrument.OptimizedInvocations.makeInvocationClass(OptimizedInvocations.java:96) > [aopc] at org.jboss.aop.instrument.OptimizedMethodInvocations.createOptimizedInvocationClass(OptimizedMethodInvocations.java:78) > [aopc] at org.jboss.aop.instrument.OptimizedMethodExecutionTransformer.transformMethod(OptimizedMethodExecutionTransformer.java:59) > [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.instrument(MethodExecutionTransformer.java:137) > [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:654) > [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:835) > [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:747) > [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:345) > [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:234) > [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:90) > [aopc] [error] failed to transform: org.jboss.jms.client.delegate.ClientBrowserDelegate.. Do verbose mode if you want full stack trace. > [aopc] java.lang.RuntimeException: failed to transform: org.jboss.jms.client.delegate.ClientBrowserDelegate > [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:728) > [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:835) > [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:747) > [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:345) > [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:234) > [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:90) > [aopc] Caused by: java.lang.RuntimeException: defrost(): org.jboss.jms.client.delegate.ClientBrowserDelegate$close_N4742752445160157748 was pruned. > [aopc] at javassist.CtClassType.checkPruned(CtClassType.java:1093) > [aopc] at javassist.CtClassType.defrost(CtClassType.java:272) > [aopc] at org.jboss.aop.instrument.OptimizedInvocations.defrostClassIfExists(OptimizedInvocations.java:66) > [aopc] at org.jboss.aop.instrument.OptimizedInvocations.makeInvocationClass(OptimizedInvocations.java:96) > [aopc] at org.jboss.aop.instrument.OptimizedMethodInvocations.createOptimizedInvocationClass(OptimizedMethodInvocations.java:78) > [aopc] at org.jboss.aop.instrument.OptimizedMethodExecutionTransformer.transformMethod(OptimizedMethodExecutionTransformer.java:59) > [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.instrument(MethodExecutionTransformer.java:137) > [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:654) > [aopc] ... 5 more > [aopc] Exception in thread "main" > BUILD FAILED > C:\work\src\cvs\jboss-head\jms\build.xml:339: Java returned: 1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5104) Upgrade JBossMessaging to 1.4.0.SP3

by Clebert Suconic (JIRA)

Upgrade JBossMessaging to 1.4.0.SP3 ----------------------------------- Key: JBAS-5104 URL: http://jira.jboss.com/jira/browse/JBAS-5104 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JB5-Messaging Affects Versions: JBossAS-5.0.0.Beta3 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: JBossAS-5.0.0.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1170) Create TestSuite to Validate External API

by Andrew Lee Rubinger (JIRA)

Create TestSuite to Validate External API ----------------------------------------- Key: EJBTHREE-1170 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1170 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: HEAD Create a TestSuite for ejb3-ext-api to ensure that a Bean Provider's View may compile with only JavaEE EJB 3.0 API and JBoss EJB 3.0 External API dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1256) Data gravitation cleanup results in data owner containing a backup region for self

by Manik Surtani (JIRA)

Data gravitation cleanup results in data owner containing a backup region for self ---------------------------------------------------------------------------------- Key: JBCACHE-1256 URL: http://jira.jboss.com/jira/browse/JBCACHE-1256 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR3 See unit test for this: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/core/trunk/src/test... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1251) Re-adding invalidated node fails with invalidation + pessimistic locking

by Brian Stansberry (JIRA)

Re-adding invalidated node fails with invalidation + pessimistic locking ------------------------------------------------------------------------ Key: JBCACHE-1251 URL: http://jira.jboss.com/jira/browse/JBCACHE-1251 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Brian Stansberry Assigned To: Manik Surtani Scenario is one where a parent node represents a structural node, and then child nodes represent different data elements. Such data structures are set up on both caches, and then the parent node is removed (globally, via INVALIDATION) and re-added (locally) on one cache. This represents an attempt to clear the region -- removing a node and re-adding is one of the only ways to do this. On the second cache, the fact that the structural node is missing is detected, and an attempt is made to re-add it locally. This fails with pessimistic locking: 18:50:34,821 TRACE PessimisticLockInterceptor:71 - PessimisticLockInterceptor invoked for method MethodName: _put; MethodIdInteger: 1; Args: (null, /test/com/foo/test/ENTITY, null, true) 18:50:34,821 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main] 18:50:34,822 TRACE PessimisticLockInterceptor:334 - Directly got child node null 18:50:34,822 TRACE IdentityLock:264 - acquiring RL: fqn=/, caller=Thread[main,5,main], lock=<unlocked> 18:50:34,823 TRACE IdentityLock:270 - acquired RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,823 TRACE PessimisticLockInterceptor:334 - Directly got child node test 18:50:34,824 TRACE IdentityLock:264 - acquiring RL: fqn=/test, caller=Thread[main,5,main], lock=<unlocked> 18:50:34,824 TRACE IdentityLock:270 - acquired RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,825 TRACE PessimisticLockInterceptor:334 - Directly got child node com 18:50:34,825 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com, caller=Thread[main,5,main], lock=<unlocked> 18:50:34,826 TRACE IdentityLock:270 - acquired RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,826 TRACE PessimisticLockInterceptor:334 - Directly got child node foo 18:50:34,827 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=<unlocked> 18:50:34,827 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,828 TRACE PessimisticLockInterceptor:334 - Directly got child node test 18:50:34,828 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=<unlocked> 18:50:34,829 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,829 TRACE PessimisticLockInterceptor:334 - Directly got child node ENTITY 18:50:34,830 TRACE IdentityLock:164 - acquiring WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=<unlocked> 18:50:34,830 TRACE IdentityLock:170 - acquired WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main] 18:50:34,831 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main] 18:50:34,831 TRACE PessimisticLockInterceptor:334 - Directly got child node null 18:50:34,832 TRACE IdentityLock:264 - acquiring RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,832 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for / 18:50:34,833 TRACE IdentityLock:270 - acquired RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,833 TRACE PessimisticLockInterceptor:334 - Directly got child node test 18:50:34,834 TRACE IdentityLock:264 - acquiring RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,834 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test 18:50:34,835 TRACE IdentityLock:270 - acquired RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,835 TRACE PessimisticLockInterceptor:334 - Directly got child node com 18:50:34,836 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,836 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com 18:50:34,837 TRACE IdentityLock:270 - acquired RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,837 TRACE PessimisticLockInterceptor:334 - Directly got child node foo 18:50:34,838 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,838 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com/foo 18:50:34,839 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,839 TRACE PessimisticLockInterceptor:334 - Directly got child node test 18:50:34,840 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,840 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com/foo/test 18:50:34,841 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]] 18:50:34,841 TRACE PessimisticLockInterceptor:334 - Directly got child node ENTITY 18:50:34,842 TRACE IdentityLock:164 - acquiring WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main] 18:50:34,842 TRACE IdentityLock:187 - acquireWriteLock(): caller already owns lock for /test/com/foo/test/ENTITY (caller=Thread[main,5,main]) 18:50:34,843 TRACE IdentityLock:170 - acquired WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main] 18:50:34,843 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main] 18:50:34,844 TRACE PessimisticLockInterceptor:334 - Directly got child node null ..... continues looping through the hierarchy until the timeout kicks in and a TimeoutException is thrown The above described scenario describes what happens with the "region clearing" operations in the Hibernate/JBC integration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JASSIST-40) Bug with 'insertAfter' called with 'asFinally' and the '$w' keyword on methods with a 'void' return type

by Patrice Bouillet (JIRA)

Bug with 'insertAfter' called with 'asFinally' and the '$w' keyword on methods with a 'void' return type -------------------------------------------------------------------------------------------------------- Key: JASSIST-40 URL: http://jira.jboss.com/jira/browse/JASSIST-40 Project: Javassist Issue Type: Bug Reporter: Patrice Bouillet Assigned To: Shigeru Chiba Altering a method with a void return type by calling insertAfter containing the $_ keyword results in the following exception for example: Exception in thread "main" java.lang.VerifyError: (class: VoidReturnType, method: doNothing signature: ()V) Register 2 contains wrong type at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1618) at java.lang.Class.getConstructor0(Class.java:1930) at java.lang.Class.newInstance0(Class.java:278) at java.lang.Class.newInstance(Class.java:261) at InsertAfterAsFinally.main(InsertAfterAsFinally.java:16) The test source code to generate this error: public class InsertAfterAsFinally { public static void main(String[] args) { ClassPool cp = ClassPool.getDefault(); try { CtClass cc = cp.get("VoidReturnType"); CtMethod cm = cc.getDeclaredMethod("doNothing"); cm.insertAfter("System.out.println(\"return value: \" + $_);", true); Class clazz = cc.toClass(); VoidReturnType vrt = (VoidReturnType) clazz.newInstance(); vrt.doNothing(); } catch (NotFoundException e) { e.printStackTrace(); } catch (CannotCompileException e) { e.printStackTrace(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } } } public class VoidReturnType { void doNothing() { } } ======================================== The problem seems to be in the insertAfterHandler method in the CtBehaviour class. The following modification from if (rtype.isPrimitive()) to: if (rtype.isPrimitive() && (rtype != CtClass.voidType)) fixes the error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1161) Interceptors are loaded from the wrong class loader

by Carlo de Wolf (JIRA)

Interceptors are loaded from the wrong class loader --------------------------------------------------- Key: EJBTHREE-1161 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1161 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Interceptors defined in another jar of the same ear can not be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1154) 2.1 Home create() implementation returns wrong type

by Andrew Lee Rubinger (JIRA)

2.1 Home create() implementation returns wrong type --------------------------------------------------- Key: EJBTHREE-1154 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1154 Project: EJB 3.0 Issue Type: Bug Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Priority: Critical Fix For: AS 5.0.0.Beta3 EJB3 Mirror issue of JBAS-5036. Local home (and presumably remote, too) implementation for EJB 3 sessions creates an object that is an instance of the local *business* interface of the EJB 3 session, and returns that. This is contrary to EJB 3 specification, which says that local home create methods must return an instance of the local interface of the EJB 3 session (as in: not local business interface). The type of the local interface is apparently deduced from the return type of the create method in the local home interface (there is no annotation for it). For beans that follow the specification, this causes a class cast exception when create() is called: the local home interface is specified to return an instance of local interface, but the implementation JBoss supplies creates a instance of local business interface (I presume so, because changing local home to return that works), and then we end up with class cast exception. There is no workaround other than going against specification in code: define local home interface to return instance of local business interface. This simple session, which as far as I can see is exactly according to EJB 3 spec, illustrates the problem, and does not work on JBoss 4.2.1.GA: -- @javax.ejb.Stateless(name="Stateless") @javax.ejb.LocalHome(StatelessHome.class) @javax.ejb.Local({StatelessLocal.class}) public class StatelessBean implements StatelessLocal { public void ejbCreate() {} } -- public interface StatelessLocal {} -- public interface StatelessHome extends javax.ejb.EJBLocalHome { public StatelessLocal21 create() throws javax.ejb.CreateException;} -- public interface StatelessLocal21 extends javax.ejb.EJBLocalObject, StatelessLocal {} -- When home is looked up, and create is called, the result is: java.lang.ClassCastException: $Proxy271 cannot be cast to StatelessLocal21 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1157) Ensure Session EJBs 2.1 Home define at least one "create()" method

by Andrew Lee Rubinger (JIRA)

Ensure Session EJBs 2.1 Home define at least one "create()" method ------------------------------------------------------------------ Key: EJBTHREE-1157 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1157 Project: EJB 3.0 Issue Type: Bug Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: AS 5.0.0.Beta3 EJB3 Core Specification 4.6.8 Bullet 4: A session bean's remote home interface must define one or more create<METHOD> methods. A stateless session bean must define exactly one create method with no arguments. Enforce this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1145) Ensure SVN History for ejb3-ext-api is complete

by Andrew Lee Rubinger (JIRA)

Ensure SVN History for ejb3-ext-api is complete ----------------------------------------------- Key: EJBTHREE-1145 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1145 Project: EJB 3.0 Issue Type: Sub-task Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Priority: Blocker Fix For: AS 5.0.0.Beta3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008