December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JASSIST-188) CtClass detach does not completely clean class from pool.

by J D (JIRA)

J D created JASSIST-188: --------------------------- Summary: CtClass detach does not completely clean class from pool. Key: JASSIST-188 URL: https://issues.jboss.org/browse/JASSIST-188 Project: Javassist Issue Type: Bug Affects Versions: 3.17.0-GA Environment: Ubuntu, Windows, JDK 1.6/1.7 Reporter: J D Assignee: Shigeru Chiba Priority: Critical Description: Class with same qualified name cannot be recreated even if previous class was detached successfully from pool. Creation#1: Consider class eg.foo.MyClass is created using default pool and private int myArg1 private member along with some getter/setter methods. After its creation, the CtClass.detach is invoked successfully. Creation#2: Subsequently, create eg.foo.MyClass using same default pool succeeds but any attempt to add members e.g. private int myArg1 fails with error: Field myArg1 in eg.foo.MyClass is private. Bug Analysis: MemberCodeGen.isAccessibleField has f.getDeclaringClass from Creation#1 but thisClass is from Creation#2. This was traced to MemberResolver.invalidNamesMap. When Creation#1 detached the CtClass, it got removed from pool but not from the invalidNamesMap for default pool. Subsequently when MemberResolver.lookupClass looks for "eg.foo.MyClass", the Creation#1's CtClass gets returned. This is a bug because that class was detached earlier and must not be reused for any processing - we are creating another instance because a new definition is needed for that class. The bug is critical as erroneous unintended cached class definitions could be used even when not intended leading to potentially very severe runtime problems. Remember that cache is a good only if it accurately provided cached results. In this case, stale/incorrect results will be returned. Proposed Fix: Add a static method detachInvalidNames in MemberResolver that removes a qualified class-name from invalidNamesMap for that class's pool. CtClass.detach must invoke this detachInvalidNames. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized

by Esteban Aliverti (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3708?page=com.atlassian.jira.plug... ] Esteban Aliverti updated JBRULES-3708: -------------------------------------- Workaround Description: The workaround I've found is to cast the result of Map.get() to Double: rule "Rule 2" when TestObject(((Double)data[Parameter.PARAM_A]) > 3) then System.out.println("Rule 2 fired!"); end was: The workaround I've found is to cast the result of Map.get() to Double: rule "Rule 2" when TestObject((*(Double)*data[Parameter.PARAM_A]) > 3) then System.out.println("Rule 2 fired!"); end > Map-accessing constraints stop matching after they are jit-optimized > -------------------------------------------------------------------- > > Key: JBRULES-3708 > URL: https://issues.jboss.org/browse/JBRULES-3708 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.5.0.Final > Reporter: Esteban Aliverti > Assignee: Mario Fusco > Labels: jit > Attachments: JITProblems.zip > > > Having the following rules: > declare TestObject > data : java.util.Map //This is a Map<Parameter, Double> > end > rule "Rule 2" > when > TestObject(data[Parameter.PARAM_A] > 3) > then > System.out.println("Rule 2 fired!"); > end > And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. > Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3708?page=com.atlassian.jira.plug... ] Mario Fusco reassigned JBRULES-3708: ------------------------------------ Assignee: Mario Fusco (was: Mark Proctor) > Map-accessing constraints stop matching after they are jit-optimized > -------------------------------------------------------------------- > > Key: JBRULES-3708 > URL: https://issues.jboss.org/browse/JBRULES-3708 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.5.0.Final > Reporter: Esteban Aliverti > Assignee: Mario Fusco > Labels: jit > Attachments: JITProblems.zip > > > Having the following rules: > declare TestObject > data : java.util.Map //This is a Map<Parameter, Double> > end > rule "Rule 2" > when > TestObject(data[Parameter.PARAM_A] > 3) > then > System.out.println("Rule 2 fired!"); > end > And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. > Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-946) IronJacamar 1.0.14.Final

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-946?page=com.atlassian.jira.plugin.... ] Jesper Pedersen resolved JBJCA-946. ----------------------------------- Resolution: Done > IronJacamar 1.0.14.Final > ------------------------ > > Key: JBJCA-946 > URL: https://issues.jboss.org/browse/JBJCA-946 > Project: IronJacamar > Issue Type: Release > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.14.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized

by Esteban Aliverti (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3708?page=com.atlassian.jira.plug... ] Esteban Aliverti updated JBRULES-3708: -------------------------------------- Attachment: JITProblems.zip Test case attached > Map-accessing constraints stop matching after they are jit-optimized > -------------------------------------------------------------------- > > Key: JBRULES-3708 > URL: https://issues.jboss.org/browse/JBRULES-3708 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.5.0.Final > Reporter: Esteban Aliverti > Assignee: Mark Proctor > Labels: jit > Attachments: JITProblems.zip > > > Having the following rules: > declare TestObject > data : java.util.Map //This is a Map<Parameter, Double> > end > rule "Rule 2" > when > TestObject(data[Parameter.PARAM_A] > 3) > then > System.out.println("Rule 2 fired!"); > end > And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. > Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized

by Esteban Aliverti (JIRA)

Esteban Aliverti created JBRULES-3708: ----------------------------------------- Summary: Map-accessing constraints stop matching after they are jit-optimized Key: JBRULES-3708 URL: https://issues.jboss.org/browse/JBRULES-3708 Project: JBRULES Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.5.0.Final Reporter: Esteban Aliverti Assignee: Mark Proctor Having the following rules: {{monospaced}} declare TestObject data : java.util.Map //This is a Map<Parameter, Double> end rule "Rule 2" when TestObject(data[Parameter.PARAM_A] > 3) then System.out.println("Rule 2 fired!"); end {{monospaced}} And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized

by Esteban Aliverti (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3708?page=com.atlassian.jira.plug... ] Esteban Aliverti updated JBRULES-3708: -------------------------------------- Workaround Description: The workaround I've found is to cast the result of Map.get() to Double: rule "Rule 2" when TestObject((*(Double)*data[Parameter.PARAM_A]) > 3) then System.out.println("Rule 2 fired!"); end was: The workaround I've found is to cast the result of Map.get() to Double: {{monospaced}} rule "Rule 2" when TestObject((*(Double)*data[Parameter.PARAM_A]) > 3) then System.out.println("Rule 2 fired!"); end {{monospaced}} > Map-accessing constraints stop matching after they are jit-optimized > -------------------------------------------------------------------- > > Key: JBRULES-3708 > URL: https://issues.jboss.org/browse/JBRULES-3708 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.5.0.Final > Reporter: Esteban Aliverti > Assignee: Mark Proctor > Labels: jit > > Having the following rules: > {{monospaced}} > declare TestObject > data : java.util.Map //This is a Map<Parameter, Double> > end > rule "Rule 2" > when > TestObject(data[Parameter.PARAM_A] > 3) > then > System.out.println("Rule 2 fired!"); > end > {{monospaced}} > And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. > Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized

by Esteban Aliverti (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3708?page=com.atlassian.jira.plug... ] Esteban Aliverti updated JBRULES-3708: -------------------------------------- Description: Having the following rules: declare TestObject data : java.util.Map //This is a Map<Parameter, Double> end rule "Rule 2" when TestObject(data[Parameter.PARAM_A] > 3) then System.out.println("Rule 2 fired!"); end And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. was: Having the following rules: {{monospaced}} declare TestObject data : java.util.Map //This is a Map<Parameter, Double> end rule "Rule 2" when TestObject(data[Parameter.PARAM_A] > 3) then System.out.println("Rule 2 fired!"); end {{monospaced}} And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. > Map-accessing constraints stop matching after they are jit-optimized > -------------------------------------------------------------------- > > Key: JBRULES-3708 > URL: https://issues.jboss.org/browse/JBRULES-3708 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.5.0.Final > Reporter: Esteban Aliverti > Assignee: Mark Proctor > Labels: jit > > Having the following rules: > declare TestObject > data : java.util.Map //This is a Map<Parameter, Double> > end > rule "Rule 2" > when > TestObject(data[Parameter.PARAM_A] > 3) > then > System.out.println("Rule 2 fired!"); > end > And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching. > Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6207) Improve HornetQ interceptor support

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-6207: -------------------------------- Summary: Improve HornetQ interceptor support Key: AS7-6207 URL: https://issues.jboss.org/browse/AS7-6207 Project: Application Server 7 Issue Type: Feature Request Components: JMS Affects Versions: 7.1.3.Final (EAP) Reporter: Jeff Mesnil Assignee: Jeff Mesnil HornetQ interceptors requires to tweak the org.hornetq module's module.xml to add a dependency to a JBoss module containing the interceptor class. Instead, the messaging subsystem should have a "module" attribute to load the remoting-interceptors without requiring any changes to hornetq or messaging subsystem modules. This will require to transform the remoting-interceptors attribute (which is a list of class names) to a messaging child resource identified by its class-name and with a module attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-947) Hibernate Validator 4.3.1.Final

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-947: ------------------------------------- Summary: Hibernate Validator 4.3.1.Final Key: JBJCA-947 URL: https://issues.jboss.org/browse/JBJCA-947 Project: IronJacamar Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.0.Beta4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2012