February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-736) Child states are leaking when failover is called

by Clebert Suconic (JIRA)

Child states are leaking when failover is called ------------------------------------------------ Key: JBMESSAGING-736 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-736 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta1, 1.2.0.Beta2 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.0.2.CR1 Delegates created by failover call, those that are supposed to be released after a failover call are still on the heap. We should investigate the cause. -- 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

18 years, 10 months

5
11
0 / 0

[JBoss JIRA] Created: (GPD-46) Review the default sizes of the different configuration forms

by Koen Aers (JIRA)

Review the default sizes of the different configuration forms ------------------------------------------------------------- Key: GPD-46 URL: http://jira.jboss.com/jira/browse/GPD-46 Project: JBoss jBPM GPD Issue Type: Task Components: jpdl Affects Versions: jBPM JPDL Designer 3.1.0 alpha1 Reporter: Koen Aers Assigned To: Koen Aers Fix For: jBPM JPDL Designer 3.1.0.alpha2 -- 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

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4146) Update to JacORB 2.3.0.GA

by Fernando Nasser (JIRA)

Update to JacORB 2.3.0.GA ------------------------- Key: JBAS-4146 URL: http://jira.jboss.com/jira/browse/JBAS-4146 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Fernando Nasser Fix For: JBossAS-5.0.0.Beta3 We are currently using a locally patches JacORB 2.2.4. The 2.30.GA includes our patch and also has some other fixes as well. >From Francisco Reverbel: Yes, that patch is in JacORB 2.3.0, which includes at least another RMI-related fix as well. It would be good to upgrade. (Disclaimer: I have never tested JacORB 2.3.0 with JBossAS. A full run of the iiop testsuite is needed.) Notice that JacORB 2.3.0 has a "new property interop.sun to fix RMI/IIOP related interoperability issues". Perhaps this makes a difference with respect to the iiop testcase that has been recently disabled on JDK1.5... NOTE: This upgrade involves JBoss TS recovery -- 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

18 years, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1079) Add testing of error handling on the Consumer (in particular, retries after errors)

by Chris Laprun (JIRA)

Add testing of error handling on the Consumer (in particular, retries after errors) ----------------------------------------------------------------------------------- Key: JBPORTAL-1079 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1079 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Chris Laprun -- 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

18 years, 11 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAOP-287) Tighten integration with MC 2.0 once it is released

by Kabir Khan (JIRA)

Tighten integration with MC 2.0 once it is released --------------------------------------------------- Key: JBAOP-287 URL: http://jira.jboss.com/jira/browse/JBAOP-287 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha2 -- 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

18 years, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAOP-348) NPE on ConstructorCallMatcher

by Flavia Rainone (JIRA)

NPE on ConstructorCallMatcher ----------------------------- Key: JBAOP-348 URL: http://jira.jboss.com/jira/browse/JBAOP-348 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha2 Reporter: Flavia Rainone Fix For: 2.0.0.alpha3 This bug happens on generated advsior instrumentation, in the following scenario: - class A extends B - B is advised by AOP - A is not advised by AOP - B calls constructor of A - calls to A constructor are identified by a pointcut During the instrumentation of a class B, the call to constructor of A is identified. As a consequence, during the matching process, A temporary advisor is required, through AspectManager.getTempClassAdvisorIfNotExist method. This method identifies A as advisable (since it extends an advisable class, B) and tries to retrieve its advisor instead of getting a temporary class advisor. Since A doesn't have the class advisor field, aspect manager retrieves its super class advisor. However, this value isn't set yet because we are still instrumenting B class. Hence, a null advisor is returned, what triggers the NullPointerException on ConstructorCallMatcher. To reproduce this bug, it is enough to alter beforeafterArgs tests, by making TargetCallerPOJO a superclass of TargetCallerPOJO2. The stack trace: java.lang.ExceptionInInitializerError at org.jboss.test.aop.beforeafterArgs.CallerTestCase.setUp(CallerTestCase.java:60) Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException at org.jboss.aop.ClassAdvisor.doResolveCallerConstructorInfo(ClassAdvisor.java:1563) at org.jboss.aop.ClassAdvisor.access$400(ClassAdvisor.java:83) at org.jboss.aop.ClassAdvisor$ResolveCallerConstuctorInfoAction$1.run(ClassAdvisor.java:2028) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.aop.ClassAdvisor$ResolveCallerConstuctorInfoAction$1 .resolveInfo(ClassAdvisor.java:2024) at org.jboss.aop.ClassAdvisor.resolveCallerConstructorInfo(ClassAdvisor.java:1527) at org.jboss.test.aop.beforeafterArgs.TargetCallerPOJO$TargetCallerPOJOAdvisor.initialiseCallers(TargetCallerPOJO$TargetCallerPOJOAdvisor.java) at org.jboss.test.aop.beforeafterArgs.TargetCallerPOJO$TargetCallerPOJOAdvisor.initialise(TargetCallerPOJO$TargetCallerPOJOAdvisor.java) at org.jboss.test.aop.beforeafterArgs.TargetCallerPOJO$TargetCallerPOJOAdvisor.<init>(TargetCallerPOJO$TargetCallerPOJOAdvisor.java) at org.jboss.test.aop.beforeafterArgs.TargetCallerPOJO.<clinit>(TargetCallerPOJO.java) ... 13 more Caused by: java.lang.RuntimeException:java.lang.NullPointerException at org.jboss.aop.pointcut.ConstructorCallMatcher.visit(ConstructorCallMatcher.java:76) at org.jboss.aop.pointcut.ast.ASTCall.jjtAccept(ASTCall.java:41) at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:89) at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83) at org.jboss.aop.pointcut.PointcutExpression.matchesCall(PointcutExpression.java:243) at org.jboss.aop.ClassAdvisor.doResolveCallerConstructorInfo(ClassAdvisor.java:1548) ... 22 more Caused by: java.lang.NullPointerException at org.jboss.aop.pointcut.ConstructorMatcher.<init>(ConstructorMatcher.java:61) at org.jboss.aop.pointcut.ConstructorCallMatcher.visit(ConstructorCallMatcher.java:71) .. 27 more -- 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

18 years, 11 months

2
8
0 / 0

[JBoss JIRA] Created: (JBPM-783) isPropagated calculation for event is not correct

by Olga Ivanova (JIRA)

isPropagated calculation for event is not correct ------------------------------------------------- Key: JBPM-783 URL: http://jira.jboss.com/jira/browse/JBPM-783 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.2 alpha 1 Reporter: Olga Ivanova Assigned To: Tom Baeyens As it is stated in comment inside org.jbpm.graph.def.GraphElement.fireAndPropagateEvent method // calculate if the event was fired on this element or if it was a propagated event boolean isPropagated = (this.equals(executionContext.getEventSource())); I believe code does not correspond to the intent and should look following: boolean isPropagated = !(this.equals(executionContext.getEventSource())); i.e if event source is same element that this, event is not propagated, if they are different - event is propagated. -- 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

18 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-713) PojoCache when it has been detached remotely, accessing it again will throw PojoCacheAlreadyDetachedException

by Ben Wang (JIRA)

PojoCache when it has been detached remotely, accessing it again will throw PojoCacheAlreadyDetachedException ------------------------------------------------------------------------------------------------------------- Key: JBCACHE-713 URL: http://jira.jboss.com/jira/browse/JBCACHE-713 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 This is the use case here: cacheA.attach(id, pojo); p = cacheB.find(id); cacheA.detach(id); p.getName(); // this will throw PojoCacheAlreadyDetachedException -- 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

18 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3992) Race condition in JBossManagedConnectionFactory

by Derek Lewis (JIRA)

Race condition in JBossManagedConnectionFactory ----------------------------------------------- Key: JBAS-3992 URL: http://jira.jboss.com/jira/browse/JBAS-3992 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.4.GA Environment: I'm running JBoss 4.0.4.GA on jaba 1.5.0_07-b03. I haven't tried a newer JBoss, however the code I've determined is causing the problem looks the same on 5.0.0.Beta1. Reporter: Derek Lewis Assigned To: Weston Price The problem happens when calling flush() on JBossManagedConnectionPool via the jmx-console. If a call to getConnection() is made by the application at the same time, there is a potential for getConnection() to throw a ResourceException saying "The pool has been shutdown". Thread 1: calls flush() Thread 2: calls getConnection() In Thread 1, in JBossManagedConnectionPool.flush(), after the pools are iterated through and shut down (this is synchronized on subPools). Assume that a context switch happens here, and Thread 2 runs now, with Thread 1 paused, before calling subPools.clear(). When thread 2 gets to where it calls getSubPool(...), this is not synchronized, so subPools.get(key) returns a pool which is not null though it has been shutdown), and returns it. getConnection() is then called on this pool, causing the exception to be thrown. Thread 1 then proceeds to clear the pool, so that the shutdown subpools are not returned. (But it's too late for this one case) -- 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

18 years, 11 months

4
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-333) Implement translation of generic types

by Kabir Khan (JIRA)

Implement translation of generic types -------------------------------------- Key: JBBUILD-333 URL: http://jira.jboss.com/jira/browse/JBBUILD-333 Project: JBoss Build System Issue Type: Task Components: JBossRetro Affects Versions: JBossRetro-1.0.4.GA Reporter: Kabir Khan This causes jdk14 test failures in the retroed container project (and so in retroed aop which depends on container) Things like Class.getGenericInterfaces() Class.getGenericSuperClass() Field.getGenericType() Method/Constructor.getGenericExceptionTypes() Method/Constructor.getGenericParameterTypes() Method/Constructor.getTypeParameters() need to be moved into a GenericTypeRedirects or something. -- 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

18 years, 11 months

4
5
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 February 2007