[JBoss JIRA] (DROOLS-600) ClassCastException when using FactTemplates
by Stephanie Kroll (JIRA)
[ https://issues.jboss.org/browse/DROOLS-600?page=com.atlassian.jira.plugin... ]
Stephanie Kroll commented on DROOLS-600:
----------------------------------------
As an aside, any chance of making FactTemplates part of the public API again? It is a good feature and necessary when facts don't conform to the standard pattern.
> ClassCastException when using FactTemplates
> -------------------------------------------
>
> Key: DROOLS-600
> URL: https://issues.jboss.org/browse/DROOLS-600
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Reporter: Stephanie Kroll
> Assignee: Mark Proctor
>
> We have embedded Drools in our project and use FactTemplates. While attempting to upgrade from Drools 5.3 to 6.1, we are receiving a ClassCastException in org.drools.compiler.rule.builder.PatternBuilder when loading and compiling rules.
> The problem is evident upon inspection of the code. In method build(RuleBuildContext, BaseDescr, Pattern), the local var objectType can be either a FactTemplateObjectType or a ClassObjectType, but line 258 does not check the type before attempting the cast.
> {noformat}
> java.lang.ClassCastException: org.drools.core.facttemplates.FactTemplateObjectType cannot be cast to org.drools.core.base.ClassObjectType
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:258)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:138)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:89)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1652)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:968)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:844)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:838)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:339)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:315)
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (DROOLS-600) ClassCastException when using FactTemplates
by Stephanie Kroll (JIRA)
[ https://issues.jboss.org/browse/DROOLS-600?page=com.atlassian.jira.plugin... ]
Stephanie Kroll commented on DROOLS-600:
----------------------------------------
We are using FactTemplates from the org.drools.core.FactTemplates package. This is an undocumented feature but has been in the Drools product since at least version 4.0 when we started using it. It is critical to our integration since it allows the use of fact objects that don't implement the standard java bean getters/setters. In our case, our facts are backed by hashmaps.
The code example below will reproduce the problem. We load the FactTemplates and rules programmatically. Yes, it is true that we are referencing the Drools non-public API's and internal objects. This is because the FactTemplate feature is not exposed through the public API's and has become buried deeper in the releases since 4.0.
{noformat}
public class FactTemplateTest {
public static final void main(final String[] args) {
String ruleText = "package com.testfacttemplate;" +
" rule \"test rule\" " +
" dialect \"mvel\" " +
" when " +
" $test : TestFactTemplate( status == 1 ) " +
" then " +
" System.out.println( \"Hello World\" ); " +
" end ";
KnowledgePackageImpl kPackage = new KnowledgePackageImpl("com.testfacttemplate");
FieldTemplate fieldTemplate = new FieldTemplateImpl("status", 0, Integer.class);
FactTemplate factTemplate = new FactTemplateImpl(kPackage, "TestFactTemplate", new FieldTemplate[]{fieldTemplate});
KnowledgeBuilder kBuilder = new KnowledgeBuilderImpl(kPackage);
StringReader rule = new StringReader(ruleText);
try {
((KnowledgeBuilderImpl) kBuilder).addPackageFromDrl(rule);
} catch (DroolsParserException | IOException e) {
e.printStackTrace();
}
System.out.println("Test Completed Successfully");
}
}
{noformat}
Regardless of using the code above to reproduce the issue, the problem can be observed by reviewing the code in the PatternBuilder.build method shown in the ClassCastException referenced in this issue's description. The FactTemplate feature within Drools still works and our integration with Drools is working correctly with version 6.1.0.Final once I added the instanceof check shown below to the PatternBuilder.build method:
{noformat}
boolean duplicateBindings = false;
if (objectType instanceof ClassObjectType) {
duplicateBindings = context.getDeclarationResolver().isDuplicated( context.getRule(),
patternDescr.getIdentifier(), ((ClassObjectType) objectType).getClassName() );
}
{noformat}
Thank you
> ClassCastException when using FactTemplates
> -------------------------------------------
>
> Key: DROOLS-600
> URL: https://issues.jboss.org/browse/DROOLS-600
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Reporter: Stephanie Kroll
> Assignee: Mark Proctor
>
> We have embedded Drools in our project and use FactTemplates. While attempting to upgrade from Drools 5.3 to 6.1, we are receiving a ClassCastException in org.drools.compiler.rule.builder.PatternBuilder when loading and compiling rules.
> The problem is evident upon inspection of the code. In method build(RuleBuildContext, BaseDescr, Pattern), the local var objectType can be either a FactTemplateObjectType or a ClassObjectType, but line 258 does not check the type before attempting the cast.
> {noformat}
> java.lang.ClassCastException: org.drools.core.facttemplates.FactTemplateObjectType cannot be cast to org.drools.core.base.ClassObjectType
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:258)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:138)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:89)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1652)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:968)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:844)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:838)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:339)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:315)
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (DROOLS-493) Error to declare Map/List with generics when having a modify() on RHS
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-493?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-493:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1142886|https://bugzilla.redhat.com/show_bug.cgi?id=1142886] from ASSIGNED to MODIFIED
> Error to declare Map/List with generics when having a modify() on RHS
> ---------------------------------------------------------------------
>
> Key: DROOLS-493
> URL: https://issues.jboss.org/browse/DROOLS-493
> Project: Drools
> Issue Type: Bug
> Environment: * OS: Mac OS X 10.9.2
> * Java SE 1.7
> * Drools Runtime 6.1.0-Final
> Reporter: Jinghai Rao
> Assignee: Mario Fusco
> Fix For: 6.2.0.CR1
>
>
> For the following rule
> -----------------------------
> package com.sample
>
> import java.util.Map;
> import java.util.HashMap;
> declare TestFact
> @propertyReactive
> data : String
> end
> rule "Test Rule"
> when
> $fact : TestFact()
> then
> Map<String,String> a = new HashMap<String,String>();
> modify ($fact) {setData("0")}
> end
> ------------------------
> We get the following exception:
> java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=rules/Sample.drl, line=11, column=0
> text=Unable to resolve type Map<String,String>:
> Unable to find class 'Map<String,String>']]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> at com.sample.DroolsTest.main(DroolsTest.java:17)
> If we remove the generics, or not using modify(), this has no error.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-122) Remove extended exception rendering from default log patterns
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-122?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-122:
---------------------------------
Description: The default log format patterns use {{%E}} which renders an extended version of the stack trace. There are performance hits when rendering an extended stack trace. The default should be {{%e}} which would render the stack trace without text like the JAR name and version of each element. (was: The default log format patterns use {%E} which renders an extended version of the stack trace. There are performance hits when rendering an extended stack trace. The default should be {%e} which would render the stack trace without text like the JAR name and version of each element.)
> Remove extended exception rendering from default log patterns
> -------------------------------------------------------------
>
> Key: WFCORE-122
> URL: https://issues.jboss.org/browse/WFCORE-122
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The default log format patterns use {{%E}} which renders an extended version of the stack trace. There are performance hits when rendering an extended stack trace. The default should be {{%e}} which would render the stack trace without text like the JAR name and version of each element.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-122) Remove extended exception rendering from default log patterns
by James Perkins (JIRA)
James Perkins created WFCORE-122:
------------------------------------
Summary: Remove extended exception rendering from default log patterns
Key: WFCORE-122
URL: https://issues.jboss.org/browse/WFCORE-122
Project: WildFly Core
Issue Type: Task
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Priority: Minor
The default log format patterns use {%E} which renders an extended version of the stack trace. There are performance hits when rendering an extended stack trace. The default should be {%e} which would render the stack trace without text like the JAR name and version of each element.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned LOGMGR-99:
-----------------------------------
Assignee: James Perkins (was: David Lloyd)
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
> Key: LOGMGR-99
> URL: https://issues.jboss.org/browse/LOGMGR-99
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: James Perkins
> Priority: Critical
> Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
> {code}
> ...
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:527)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:266)
> at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
> at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
> at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (DROOLS-600) ClassCastException when using FactTemplates
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-600?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-600:
------------------------------------
Can you send a reproducer for this issue? I tried to reproduce this problem with the following DRL but it works for me.
{code}
declare Bean @format( template )
value : String
end
rule Init when
then
insert( new Bean("test") );
end
rule R when
$b: Bean( value == "test" )
then
System.out.println("OK");
end
{code}
> ClassCastException when using FactTemplates
> -------------------------------------------
>
> Key: DROOLS-600
> URL: https://issues.jboss.org/browse/DROOLS-600
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Reporter: Stephanie Kroll
> Assignee: Mark Proctor
>
> We have embedded Drools in our project and use FactTemplates. While attempting to upgrade from Drools 5.3 to 6.1, we are receiving a ClassCastException in org.drools.compiler.rule.builder.PatternBuilder when loading and compiling rules.
> The problem is evident upon inspection of the code. In method build(RuleBuildContext, BaseDescr, Pattern), the local var objectType can be either a FactTemplateObjectType or a ClassObjectType, but line 258 does not check the type before attempting the cast.
> {noformat}
> java.lang.ClassCastException: org.drools.core.facttemplates.FactTemplateObjectType cannot be cast to org.drools.core.base.ClassObjectType
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:258)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:138)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:89)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1652)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:968)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:844)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:838)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:339)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:315)
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month