January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-585) syntax sugar for binding to a field on a bound fact

by Michael Neale (JIRA)

syntax sugar for binding to a field on a bound fact --------------------------------------------------- Key: JBRULES-585 URL: http://jira.jboss.com/jira/browse/JBRULES-585 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.5 Reporter: Michael Neale Assigned To: Mark Proctor Fix For: 3.1-m3 For example: c: Customer($id: id) p: Person(customerId == $id.....) could become: c: Customer() p: Person(customerId == c.id) much more OO looking. Can use an extractor (if possible). -- 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

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-456) Nested field accessor - contributions from Patrick Niemeyer

by Michael Neale (JIRA)

Nested field accessor - contributions from Patrick Niemeyer ----------------------------------------------------------- Key: JBRULES-456 URL: http://jira.jboss.com/jira/browse/JBRULES-456 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Affects Versions: 3.0.4 Reporter: Michael Neale Assigned To: Mark Proctor Priority: Critical Fix For: 3.1-m3 Attachments: jboss-nested-asm.jar This is from Patrick Niemeyer <pat(a)pat.net>. Provides Foo(a.b.c etc). We are hoping for some more enhancements that can also do map/array access like javascript. -- 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

4
5
0 / 0

[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: (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, 10 months

3
8
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, 10 months

2
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, 10 months

2
10
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, 10 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, 10 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, 10 months

4
4
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 January 2007