2:49 p.m.
Hi all
We are using Fusion to make some simplification and grouping on some events.
We have several classes of events, all derivated from a top-level class .
With fusion version 5.3 (and 5.2 too), we must declare the @role(event) for the top-level
class, but also for all its classes hierarchy , ie the role is not inherited by
subclasses.
Is it done and purpose ?
Is it a bug ?
Thanks.
8:09 p.m.
Vincent,
Fact types are supposed to inherit the @role of their parent classes, so
if you define the parent class/interface as an event, all subclasses will
inherit the event role. If it is not working like this, it is a bug, but I
am pretty sure we have tests for it. Please open a JIRA and provide a test
case to reproduce the behavior otherwise.
Thank you,
Edson
2011/11/14 Vincent LEGENDRE <vincent.legendre(a)eurodecision.com>
Hi all
We are using Fusion to make some simplification and grouping on some
events.
We have several classes of events, all derivated from a top-level class.
With fusion version 5.3 (and 5.2 too), we must declare the @role(event)
for the top-level class, *but also for all its classes hierarchy*, ie the
role is not inherited by subclasses.
Is it done and purpose ?
Is it a bug ?
Thanks.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
1:17 a.m.
I think have already fixed it in a trait-related pull request I'm working on.
It also fixes a couple of bugs, including the metadata inheritance problem.
Nevertheless, please provide a test case and a JIRA :)
Thanks
Davide
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Fusion-must-declare-role-ev...
Sent from the Drools: User forum mailing list archive at Nabble.com.
9:54 a.m.
Strange ...
When trying to build a minimal sample that reproduce my problem ... well ... did not
manage to reproduce ...
I will try to find out why my first attempt is different from my minimal sample now ...
Will get back here asap.
5:01 p.m.
New subject: Fusion : must declare @role(event) for all class hierarchy ?
Well, after trying and trying to reproduce with a simpler case, @role is always correctly
inherited.
But in my application, it seems not, or may be it is another problem.
I have 3 classes : ChantierEvent (the main mother class) and its 2 subClasses : InitEvent
and DisposeEvent
When I declare @role(event) for all 3 classes, everything works wells
When I only declare for the motherclass, this exception is raised (at insertion of a
InitEvent) :
java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot be cast to
org.drools.common.EventFactHandle
at
org.drools.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:316)
at
org.drools.rule.VariableRestriction.isAllowedCachedRight(VariableRestriction.java:122)
at org.drools.rule.VariableConstraint.isAllowedCachedRight(VariableConstraint.java:121)
at
org.drools.common.TripleBetaConstraints.isAllowedCachedRight(TripleBetaConstraints.java:208)
at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:458)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:386)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
--> call of insert(new InitEvent(...));
at com.sncf.morse.server.MVFusionThreadSession.addEvent(MVFusionThreadSession.java:158)
I first think about a problem on "after" operator, so I commented out the rule
that uses it, and this error is raised then (I also use sliding windows) :
java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot be cast to
org.drools.common.EventFactHandle
at org.drools.rule.SlidingTimeWindow.updateNextExpiration(SlidingTimeWindow.java:211)
at org.drools.rule.SlidingTimeWindow.assertRightTuple(SlidingTimeWindow.java:128)
at org.drools.rule.BehaviorManager.assertRightTuple(BehaviorManager.java:84)
at org.drools.reteoo.NotNode.assertObject(NotNode.java:114)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:458)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:386)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
--> call of insert(new InitEvent(...));
at com.sncf.morse.server.MVFusionThreadSession.addEvent(MVFusionThreadSession.java:158)
Do you have any ideas on why this could happend ?
In what case the role could not be inherited (I tried to make my minimal sample class look
like the real one, but I can't reproduce ..).
thanks
6:05 p.m.
Vincent,
It seems it is a merging problem on declarations, but unfortunately, the
exceptions you are seeing are the symptoms, not the cause, so I can't infer
much from them.
Some suggestions to try to isolate the problem: are the fact types
(classes) in the same package or different packages? Are the
declaration(s)/rules in the same file or different files? Are you using a
single kbuilder to build the whole thing on your application or using
different kbuilders? Is the order in which you are loading the files into
the kbuilder and the order you add packages in your kbase the same on your
application and your test?
These are some of the conditions that trigger declaration merges. I know
it is not much, but try checking these things... maybe you get lucky and
manage to reproduce the problem so that we can debug it and fix it.
Also, which version of Drools are you using? Did you tried with latest
snapshot from the 5.3.x branch or with master branch (5.4.x)?
Any additional information you can give us might help us figure out the
problem.
Thanks,
Edson
On Mon, Nov 28, 2011 at 11:01 AM, Vincent LEGENDRE <
vincent.legendre(a)eurodecision.com> wrote:
Well, after trying and trying to reproduce with a simpler case, @role
is
always correctly inherited.
But in my application, it seems not, or may be it is another problem.
I have 3 classes : ChantierEvent (the main mother class) and its 2
subClasses : InitEvent and DisposeEvent
When I declare @role(event) for all 3 classes, everything works wells
When I only declare for the motherclass, this exception is raised (at
insertion of a InitEvent) :
java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot
be cast to org.drools.common.EventFactHandle
at
org.drools.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:316)
at
org.drools.rule.VariableRestriction.isAllowedCachedRight(VariableRestriction.java:122)
at
org.drools.rule.VariableConstraint.isAllowedCachedRight(VariableConstraint.java:121)
at
org.drools.common.TripleBetaConstraints.isAllowedCachedRight(TripleBetaConstraints.java:208)
at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:458)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:386)
at
org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215)
at
org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244)
at
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330)
at
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
--> call of insert(new InitEvent(...));
at
com.sncf.morse.server.MVFusionThreadSession.addEvent(MVFusionThreadSession.java:158)
I first think about a problem on "after" operator, so I commented out the
rule that uses it, and this error is raised then (I also use sliding
windows) :
java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot
be cast to org.drools.common.EventFactHandle
at
org.drools.rule.SlidingTimeWindow.updateNextExpiration(SlidingTimeWindow.java:211)
at
org.drools.rule.SlidingTimeWindow.assertRightTuple(SlidingTimeWindow.java:128)
at
org.drools.rule.BehaviorManager.assertRightTuple(BehaviorManager.java:84)
at org.drools.reteoo.NotNode.assertObject(NotNode.java:114)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:458)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:386)
at
org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215)
at
org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244)
at
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330)
at
org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
--> call of insert(new InitEvent(...));
at
com.sncf.morse.server.MVFusionThreadSession.addEvent(MVFusionThreadSession.java:158)
Do you have any ideas on why this could happend ?
In what case the role could not be inherited (I tried to make my minimal
sample class look like the real one, but I can't reproduce ..).
thanks
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
7:48 p.m.
Hi Edson, and thanks for answering
? - are the fact types (classes) in the same package or different packages?
Different packages. But I tried this on my little sample (put the sub-class in another
package than the mother class), and this works
? - Are the declaration(s)/rules in the same file or different files?
Same file (DRL)
? - Are you using a single kbuilder to build the whole thing on your application or using
different kbuilders?
? - Is the order in which you are loading the files into the kbuilder and the order you
add packages in your kbase the same on your application and your test?
My kbase has a unique package, got from a single DRL file, built by a single (new)
kbuilder.
But I use one kbuilder per package, only for build time, and I have other packages /
kbases, for other rule sessions ...
Here I create 3 packages (and 3 kbases), using one new kbuilder for each. These 3 packages
don't have any fusion construction in them.
Then I build the 4th package / kbase, using one new kbuilder, and this is this package
which contains some fusion rules.
Does kbuilders can collide in some way ? May be that as the 3 first package don't use
any fusion, all the classes are tagged as "not event", kept somewhere, and
reused in the 4th kbuilder, that only update the explicitely "event" classes ? I
will try to load the fusion kb first to see what happend ... but I am sceptic, as the 3
first package don't use the ***Event objects ...
There is another difference on my package build process.
My little test is built over the Hello World sample. My app uses more sophisticated way of
getting resources, but finally calls the same kbuilder.add ... magic method ...
The only difference is that :
- HelloWorld sample, and my little test, uses kbuilder.add( newClassPathResource(...) ,
ResourceType.DRL) to get resources that are located in a eclipse source folder
- My application uses kbuilder.add( newFileResource(...) , ResourceType.DRL) to fetch
resources in the file system
I am quite sure that the difference cannot be here for real ... I guess that all of these
methods finally result in opening a InputStream that contains DRL raw text to feed a
parser, which don't care about how the inputStream was created ...
? - Also, which version of Drools are you using? Did you tried with latest snapshot from
the 5.3.x branch or with master branch (5.4.x)?
5.3.Final official stable version. and before that the 5.2.Final version (problem is there
too).
Did not tried with any "not official" version (I already experienced problem
when migrating guvnor repos from candidates releases ...).
? - Any additional information you can give us might help us figure out the problem.
Ok. The problem here is that I can't provide you the full code, and anyway you
won't go into this code for some mysterious bug ...
The two sub classes (InitEvent, and DisposeEvent) are very basic derivated classes. They
only use "extends ChantierEvent" and nothing more (no interfaces).
They have a different constructor signature than their parent, but I also test that with
my little sample and this is not the problem .. .
These classes have attributes that links to other classes in the project. By transitivity,
all business objects are loaded (by the class loader). These BO contains annotations for
DB persistance (but they are attributes, the ***Event classes does not have any
annotations).
I don't know what to add ...
I will go on testing a bit, and report back here.
Thanks !
8:34 p.m.
New subject: Fusion : must declare @role(event) for all class hierarchy ?
Tried to load my fusion package before any others. Same problem....
----- Mail original -----
De: "Vincent LEGENDRE" <vincent.legendre(a)eurodecision.com>
À: "Rules Users List" <rules-users(a)lists.jboss.org>
Envoyé: Lundi 28 Novembre 2011 19:48:03
Objet: Re: [rules-users] Fusion : must declare @role(event) for all class hierarchy ?
Hi Edson, and thanks for answering
? - are the fact types (classes) in the same package or different packages?
Different packages. But I tried this on my little sample (put the sub-class in another
package than the mother class), and this works
? - Are the declaration(s)/rules in the same file or different files?
Same file (DRL)
? - Are you using a single kbuilder to build the whole thing on your application or using
different kbuilders?
? - Is the order in which you are loading the files into the kbuilder and the order you
add packages in your kbase the same on your application and your test?
My kbase has a unique package, got from a single DRL file, built by a single (new)
kbuilder.
But I use one kbuilder per package, only for build time, and I have other packages /
kbases, for other rule sessions ...
Here I create 3 packages (and 3 kbases), using one new kbuilder for each. These 3 packages
don't have any fusion construction in them.
Then I build the 4th package / kbase, using one new kbuilder, and this is this package
which contains some fusion rules.
Does kbuilders can collide in some way ? May be that as the 3 first package don't use
any fusion, all the classes are tagged as "not event", kept somewhere, and
reused in the 4th kbuilder, that only update the explicitely "event" classes ? I
will try to load the fusion kb first to see what happend ... but I am sceptic, as the 3
first package don't use the ***Event objects ...
There is another difference on my package build process.
My little test is built over the Hello World sample. My app uses more sophisticated way of
getting resources, but finally calls the same kbuilder.add... magic method ...
The only difference is that :
- HelloWorld sample, and my little test, uses kbuilder.add( newClassPathResource(...) ,
ResourceType.DRL) to get resources that are located in a eclipse source folder
- My application uses kbuilder.add( newFileResource(...) , ResourceType.DRL) to fetch
resources in the file system
I am quite sure that the difference cannot be here for real ... I guess that all of these
methods finally result in opening a InputStream that contains DRL raw text to feed a
parser, which don't care about how the inputStream was created ...
? - Also, which version of Drools are you using? Did you tried with latest snapshot from
the 5.3.x branch or with master branch (5.4.x)?
5.3.Final official stable version. and before that the 5.2.Final version (problem is there
too).
Did not tried with any "not official" version (I already experienced problem
when migrating guvnor repos from candidates releases ...).
? - Any additional information you can give us might help us figure out the problem.
Ok. The problem here is that I can't provide you the full code, and anyway you
won't go into this code for some mysterious bug ...
The two sub classes (InitEvent, and DisposeEvent) are very basic derivated classes. They
only use "extends ChantierEvent" and nothing more (no interfaces).
They have a different constructor signature than their parent, but I also test that with
my little sample and this is not the problem ...
These classes have attributes that links to other classes in the project. By transitivity,
all business objects are loaded (by the class loader). These BO contains annotations for
DB persistance (but they are attributes, the ***Event classes does not have any
annotations).
I don't know what to add ...
I will go on testing a bit, and report back here.
Thanks !
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4539
days inactive
4553
days old
7 comments
3 participants
participants (3)
-
Davide Sottara -
Edson Tirelli -
Vincent LEGENDRE