[rules-users] Fusion : must declare @role(event) for all class hierarchy ?

[Vincent LEGENDRE]

Tried to load my fusion package before any others. Same problem.... 

----- Mail original -----

De: "Vincent LEGENDRE" <vincent.legendre at eurodecision.com> 
À: "Rules Users List" <rules-users at 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 at lists.jboss.org 
https://lists.jboss.org/mailman/listinfo/rules-users 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111128/d9ea97d8/attachment.html