[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 commented on JBRULES-3708:
-------------------------------------------
If the TestObject is defined as a Java class having: Map<JCpSimParameter, Double> data; then everything works as expected.
So, another workaround is to avoid DRL declared classes containing maps.
> 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
13 years, 6 months
[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ]
Marek Schmidt updated AS7-6186:
-------------------------------
Attachment: AS7-6186-viewMap-v3.tar
> Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations
> -----------------------------------------------------
>
> Key: AS7-6186
> URL: https://issues.jboss.org/browse/AS7-6186
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Priority: Critical
> Attachments: AS7-6186-viewMap-v3.tar, AS7-6186-viewMap-v3.war, AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear
>
>
> Recent Mojarra upgrade seems to break Seam 2.3.0 conversations.
> Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't.
--
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
13 years, 6 months
[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ]
Marek Schmidt updated AS7-6186:
-------------------------------
Attachment: AS7-6186-viewMap-v3.war
> Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations
> -----------------------------------------------------
>
> Key: AS7-6186
> URL: https://issues.jboss.org/browse/AS7-6186
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Priority: Critical
> Attachments: AS7-6186-viewMap-v3.war, AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear
>
>
> Recent Mojarra upgrade seems to break Seam 2.3.0 conversations.
> Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't.
--
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
13 years, 6 months
[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ]
Marek Schmidt commented on AS7-6186:
------------------------------------
And a third one, which IMHO finally proves Mojarra 2.1.16 breaks viewMap (see below and the attached AS7-6186-viewMap-v3.war reproducer)
With 2.1.16, no foo value is displayed after the first click, even though the value has been put there before the render response, so mojarra had plenty time to store it somewhere and retrieve it until the next invoke application phase:
{code}
@Model
public class Action
{
private String foo;
public String getFoo() {
return foo;
}
public void recordViewMap() {
System.out.println("XXX recording the viewmap state to the model, so we can be sure the value is there in the INVOKE APPLICATION phase");
foo = (String)FacesContext.getCurrentInstance().getViewRoot().getViewMap().get("foo");
}
}
{code}
{code}
public class MyPhaseListener implements PhaseListener {
@Override
public void afterPhase(PhaseEvent event) {
System.out.println("XXX: afterPhase: " + event.getPhaseId().toString());
}
@Override
public void beforePhase(PhaseEvent event) {
System.out.println("XXX: beforePhase: " + event.getPhaseId().toString());
if (event.getPhaseId().equals(PhaseId.RENDER_RESPONSE)) {
Map<String, Object> map = event.getFacesContext().getViewRoot().getViewMap();
if (!map.containsKey("foo")) {
System.out.println("XXX: putting foo:1 into the viewMap:");
map.put("foo", Integer.toString(1));
}
else {
System.out.println("XXX: setting foo to " + map.get("foo") + " + 1");
map.put("foo", "" + (Integer.parseInt((String)map.get("foo")) + 1));
}
}
}
@Override
public PhaseId getPhaseId() {
// TODO Auto-generated method stub
return PhaseId.ANY_PHASE;
}
}
{code}
{code}
<h:form>
<div>
Foo:
<h:outputText value="#{action.getFoo()}" />
</div>
<div>
<h:commandButton value="Record" action="#{action.recordViewMap()}"/>
</div>
</h:form>
{code}
> Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations
> -----------------------------------------------------
>
> Key: AS7-6186
> URL: https://issues.jboss.org/browse/AS7-6186
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Priority: Critical
> Attachments: AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear
>
>
> Recent Mojarra upgrade seems to break Seam 2.3.0 conversations.
> Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't.
--
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
13 years, 6 months
[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
13 years, 6 months
[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
13 years, 6 months
[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
13 years, 6 months