[JBoss JIRA] Created: (JBRULES-3033) java.lang.ClassCastException when change rule condition and declarative facts/events are used
by Federico Weisse (JIRA)
java.lang.ClassCastException when change rule condition and declarative facts/events are used
---------------------------------------------------------------------------------------------
Key: JBRULES-3033
URL: https://issues.jboss.org/browse/JBRULES-3033
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Reporter: Federico Weisse
Assignee: Mark Proctor
We have drl files where we declare events. we use declarative events (there is no java class AlertaPosManual)
(like this)
declare AlertaPosManual
@role (event)
@expires(10s)
idTerminal : java.lang.String
end
We use a StatefullSession for fusion cep and we need that changes in rules refresh the kBase in runtime. But when a rule condition changes this exception in throw
Exception in thread "Thread-2" java.lang.ClassCastException: com.sample.ConsumoPostManual cannot be cast to com.sample.ConsumoPostManual
at org.drools.base.com.sample.ConsumoPostManual17710704$getIdTerminal.getValue(Unknown Source)
at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:192)
at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193)
at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:582)
at org.drools.core.util.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:360)
at org.drools.core.util.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:243)
at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:246)
at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:276)
at org.drools.reteoo.PropagationQueuingNode.updateSink(PropagationQueuingNode.java:111)
at org.drools.reteoo.BetaNode.attach(BetaNode.java:214)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:151)
at org.drools.reteoo.builder.CollectBuilder.build(CollectBuilder.java:114)
at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:111)
at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:72)
at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:132)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:78)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:428)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:721)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:545)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445)
at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106)
at java.lang.Thread.run(Thread.java:619)
I think that's because the statefullSession has an instance of
com.sample.ConsumoPostManual (loaded with the classLoader
org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1218b25) But when
the kBase is regenerated and the class com.sample.ConsumoPostManual to, the
classLoader org.drools.rule.JavaDialectRuntimeData is recreated so there
are two versions of the class com.sample.ConsumoPostManual in differents
classLoader (one in the statefullSession and the other in the kBase)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBRULES-2962) Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts
by Ross Hall (JIRA)
Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts
------------------------------------------------------------------------------------------------
Key: JBRULES-2962
URL: https://issues.jboss.org/browse/JBRULES-2962
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.2.0.M1, 5.1.1.FINAL
Reporter: Ross Hall
Assignee: Mark Proctor
When reloading rules in a KnowledgeAgent declared facts will cause ClassCastExceptions when new-instance is set to false. When new-instance is set to true, the KnowledgeBase is rebuilt, however declared facts are not recognized and associated rules will not fire. Rules not using declared facts will fire normally. Using POJOs works fine.
In both cases the KnowledgeAgent will build the rule base the first time, the issue only seems to occur when the changeset resources are modified and are detected by the resource notifier and scanner.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBRULES-2791) Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager
by Anatoly Polinsky (JIRA)
Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager
------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2791
URL: https://jira.jboss.org/browse/JBRULES-2791
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL, FUTURE
Environment: Spring Based Applications
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
Instead of having two different components: "DroolsSpringTransactionManager" and "DroolsSpringJpaManager" that aim to do the work of "org.springframework.orm.jpa.JpaTransactionManager", and trying to fit a JTA model into it, the Spring's "JpaTransactionManager" itself should be used.
And instead of manually managing and constantly getting references to a "proper entity manager" from JpaManger within a SingleSessionCommandService, a @PersistenceContext should be injected. This will decouple SingleSessionCommandService from JpaManager interface, and will allow _any_ JPA provider to inject an entity manager.
It has more benefits, such as trust in underline JPA providers ( e.g. Hibernate ) and Spring Transaction Management capabilities to manage the process that they are actually excellent at.
/Anatoly
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBCOMMON-114) Warning for non File URLs should also check for vfszip URLs
by Darran Lofthouse (JIRA)
Warning for non File URLs should also check for vfszip URLs
-----------------------------------------------------------
Key: JBCOMMON-114
URL: https://jira.jboss.org/browse/JBCOMMON-114
Project: JBoss Common
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: common-core (2.x)
Affects Versions: 2.2.17.GA
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 2.2.18.GA
Within the resolveSystemIDasURL method the following check is performed: -
if (warnOnNonFileURLs && url.getProtocol().equalsIgnoreCase("file") == false)
{
log.warn("Trying to resolve systemId as a non-file URL: " + systemId);
}
With the introduction of vfszip URLs from JBoss 5 these should also be checked and the warning skipped if it is a vfszip URL.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months