Duplicate rule name

[Nico Vanden]

Hello,

In drools 5.5, it was possible to override a rule with another one (same package but different drl).  In drools 6.2, an exception is raised by the KnowledgeBuilderImpl.validateUniqueRuleNames() method.  I tried to use the "

drools.kbuilder.severity.duplicateRule/duplicateFunction

" properties without success.  (Cfr doc: 4.2.2.5. Changing the Default Build Result Severity).  

Is this a regression or the feature has been removed from drools 6.x ?  Does the chapter 4.2.2.5 is up to date ? 

Kind regards,

Nicolas-Xavier

[Mark Proctor]

that was a bug and fixed in 5.3

https://issues.jboss.org/browse/JBRULES-3063

Mark

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/0800206a-3823-4cd4-a235-f2629aecba59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nico Vanden]

That's what I said in my previous post . It worked with version >= 5.3 but it no longer works with the 6.2.  A simple example, I just copy/paste the same drl twice in the same folder.  (2 different drl files with the same content ).  The second drl loaded should override the rules of the first drl.

17:27:30,056 ERROR [AbstractKieModule] Unable to build KieBaseModel:kb-qualification

[28,0]: Duplicate rule name: Qualification##Commons##Unblock Messages##From ExpectedMessage fact

[45,0]: Duplicate rule name: Qualification##Commons##Unblock Messages##From Process fact

[63,0]: Duplicate rule name: Qualification##Commons##Unblock Messages##Replay message

Rule Compilation error : [Rule name='Qualification##Commons##Unblock Messages##From Process fact']

qualification/standard/commons/unblockMessages/Rule_Qualification$u35$$u35$Commons$u35$$u35$Unblock_Messages$u35$$u35$From_Process_fact644692114.java (6:1116) : Duplicate method defaultConsequence(KnowledgeHelper, Message, FactHandle) in type Rule_Qualification$u35$$u35$Commons$u35$$u35$Unblock_Messages$u35$$u35$From_Process_fact644692114

qualification/standard/commons/unblockMessages/Rule_Qualification$u35$$u35$Commons$u35$$u35$Unblock_Messages$u35$$u35$From_Process_fact644692114.java (13:1502) : Duplicate method defaultConsequence(KnowledgeHelper, Message, FactHandle) in type Rule_Qualification$u35$$u35$Commons$u35$$u35$Unblock_Messages$u35$$u35$From_Process_fact644692114

qualification/standard/commons/unblockMessages/Rule_Qualification$u35$$u35$Commons$u35$$u35$Unblock_Messages$u35$$u35$From_Process_fact644692114.java (3:939) : The type Rule_Qualification$u35$$u35$Commons$u35$$u35$Unblock_Messages$u35$$u35$From_Process_fact644692114 is already defined

[Davide Sottara]

Nico,

that was never the intended behaviour. Rule names are still supposed to be unique. If you want to update a rule, you will have to build the KB incrementally.

When two rules have the same name, how do you guarantee that the "desired" one will override the other, rather than the other way around?

It is not safe to rely on the DRL loading order: KieBases are assumed to be sets, not lists, of knowledge resources.

Do you have a specific use case for the override? Maybe there are alternatives

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/0266be81-2148-4095-8458-dcd95c970813%40googlegroups.com.

[Mark Proctor]

I suspect in 5.x you could do it, as long as it wasn’t loaded in the same DRL at the same time. As we had scoped incremental updates to any given dl file. (but not 100% sure, it’s been a while).

In 6.x we now have this scope, which is tied to a jar version. If you want to update a rule, it needs a new version.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/CANinqmfkjwwx0qBifJXbuLsuL%3DtckXvgkLTk6c%3D-VXvdNZL1Mg%40mail.gmail.com.

[Adam Davis]

Hi guys,

I'm running into a similar problem, and this post is the closest to addressing it that I have found.  What we are trying to do is have two drl files - one is the default supplied by us, and the other is a client-configurable custom file.  The custom should ideally be able to override one of the default rules if they want.  If they do not override it, then the default should be executed.  The easiest approach to this seemed to be using the rule name to override. This is hinted at in the 6.1 documentation section 7.8 - "If you add a DRL that includes a rule name already in the package, it replaces the previous rule."  This is very easy to accomplish in the 5.x syntax:

KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
builder.add(defaultFileResource, ResourceType.DRL); //compiles the default file
builder.add(customFileResource, ResourceType.DRL); //compiles the custom file, overriding rules with the same name in the default

KnowledgeBase base = KnowledgeBaseFactory.newKnowledgeBase();
base.addKnowledgePackages(builder.getKnowledgePackages());

Is there a way to do this using 6.x syntax?  The examples from the 6.1 documentation that cover programmatically building a knowledge base use the old syntax (the "Banking Tutorial" in section 19.5).  I am rather new to drools, so if what I am trying to do is not recommended, please let me know.

Adam

[Karl H.]

Hello,
we also use the approach for customisation as Adam describes. We deliver a WAR archive including our base rules to our customers and they override some rules using rule files in their config folder.
I don't understand why this was changed as since https://issues.jboss.org/browse/JBRULES-3063 it was already possible to change duplicate rule name behaviour through configuration when needed.

So what's the way to go in JBPM6.2 to implement this?

Regards
Karl

[Mark Proctor]

5.x had no notion of life cycles or batching. So when you do two separate .add() it cannot tell if that is to be part of the same or a different version.

In 6.x we support versioning and life cycles. That means if you wish to over-ride  right now, you need to do it in two different versions. So deploy the base default rule in 1.0 and then deploy the update in 1.1.

We might look into more flexibility in the future, if we can be sure to avoid users making mistakes. Maybe something similar to @Override.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/14c41bbc-e5a2-4cde-8e7d-b36c5d40c80b%40googlegroups.com.

[Karl H.]

Maybe you can give me a little hint how to do this using the KIE API?
Right now I create one KieContainer and use it to create my StatelessKieSession instances:

KieServices kieServices = KieServices.Factory.get()
KieModuleModel kieModuleModel = kieServices.newKieModuleModel()
...
KieBaseModel kieBaseModel = kieModuleModel.newKieBaseModel('statelessKieBase')
...
kieBaseModel.newKieSessionModel('statelessKieSession')
...
KieFileSystem kfs = kieServices.newKieFileSystem()
kfs.writeKModuleXML(kieModuleModel.toXML())

// write some resources to the file system
kfs.write(...)

kfs.writeKModuleXML(kieModuleModel.toXML())
KieBuilder kieBuilder = kieServices.newKieBuilder(kfs)
kieBuilder.buildAll()
...
KieContainer kieContainer = kieServices.newKieContainer(kieServices.getRepository().getDefaultReleaseId())

StatelessKieSession kieSession = kieContainer.newStatelessKieSession('statelessKieSession')

[Karl H.]

I'm still struggling on this. Can anyone lead me in the right direction?

Regards
Karl

[Mark Proctor]

The customer will need to create a second version of the jar, that has their changes. They will need to remove the default version, and add theirs.

You install the base jar, then install the updated version with “updateToVersion”.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/6a9a5fa7-783e-4377-9998-21b562f430b2%40googlegroups.com.

[Adam Davis]

Mark,

So does that mean that the new customer version would need to contain all relevant rule files, not just their modification?

Say we deploy a default version with three rules ("Rule 1", "Rule 2", and "Rule 3") as version 1.0.  The client wants to alter the functionality of "Rule 2", but leave the other rules alone.  Does their version 1.1 jar contain just "Rule 2", or would it need to contain the default versions of "Rule 1" and "Rule 3"?

If version 1.1 must contain all three rules, what is the expected upgrade path when we eventually modify the default "Rule 1" and "Rule 3" and release version 2.0?  Does that mean the client would need to re-package their modified "Rule 2" along with the newer versions of the other rules and upload a version 2.1 jar?  Using the 5.x API, we can safely update the default "Rule 1" and "Rule 3", and as long as we install the default rule files before the client-configured rule files, the client does not need to do anything when we release updates.

Thanks,

Adam

[Mario Fusco]

So does that mean that the new customer version would need to contain all relevant rule files, not just their modification?

Yes.

 

Say we deploy a default version with three rules ("Rule 1", "Rule 2", and "Rule 3") as version 1.0.  The client wants to alter the functionality of "Rule 2", but leave the other rules alone.  Does their version 1.1 jar contain just "Rule 2", or would it need to contain the default versions of "Rule 1" and "Rule 3"?

It needs to contains "Rule 1" and "Rule 3".

 

If version 1.1 must contain all three rules, what is the expected upgrade path when we eventually modify the default "Rule 1" and "Rule 3" and release version 2.0?  

You have to provide a jar version 2.0 containing the Rule2 modified in 1.1 plus the new modified Rule1 and Rule3.

 

Does that mean the client would need to re-package their modified "Rule 2" along with the newer versions of the other rules and upload a version 2.1 jar?  

Yes. Not doing so will be interpreted as the fact that Rule2 is no longer in use and will then be removed from the knowledge base.

 

Using the 5.x API, we can safely update the default "Rule 1" and "Rule 3", and as long as we install the default rule files before the client-configured rule files, the client does not need to do anything when we release updates.

You should think of a kjar (a jar containing drls or any other kie artifacts) as any other normal jar. If you have the version 1.0 of a jar containing the java classes Person and Cheese and you want to modify the Cheese class in a subsequent version 1.1 leaving the Person one unchanged you'll create a jar version 1.1 with the old Person and the modified Cheese, correct? Well, Drools 6 works exactly in the same way ;)

One final note about the strategy to "override" the behaviour of a rule with a drl containing a rule with the same name as originally outlined by NIco. As already written by Davide this was the effect of an unintended behaviour or, in my opinion, a bug. In particular it is true that rule names are always supposed to be unique. Moreover there's no such a thing in Drools 6 llke a 1st, 2nd or nth drl file. All the drls belong to the same project (jar) and there's no way to say which one comes first. For this reason the only meaningful thing we can do when we find a duplicated rule name is raising a compilation error.

I hope this helps,

Mario

[Mark Proctor]

5.x had no overall life cycle, in the way that 6.x has, beyond addDrl. So during the same addDrl we made sure that all rule names were unique, as this is a common mistake that needs to be caught. Because there was no life cycle, there is no scope, which means an additional addDrl would allow overrides.

With 6.x we have deployment life cycles and thus scoping for duplicate naming, this catches a common mistake, and is a good thing. The scoping does allow you to replace rules, as long as they are in a future version. In the future we’ll revisit this and see if we can find a way to allow explicit overrides.

Mark

I hope this helps,

Mario

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
To post to this group, send email to drools...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/CAPYjU_mXF-G%3DCHZATYWWmzzmWjFs4ij%3DZJZ%2BwstNtoZtDiRZcw%40mail.gmail.com.

[Adam Davis]

OK, that makes sense.  Thanks everyone!  

I just need to adjust my thinking - since we are compiling these rules programmatically, it appeared as though the order of file addition mattered (and the way we are currently implementing things, it does).  This allowed us to override previous rules with versions from subsequent files.  The move to the 6.x way is more onerous - I think we will have to parse through our rule files and strip out duplicate rules so that things compile correctly, as clients will not have direct access to "install" their own versions and will only give us the rule files they want to be applied on top of our defaults - but it is also more powerful, especially the "updateToVersion" functionality.

That being said, explicit overrides would still be a very nice feature to have :).

Adam

[Eugene Kamenev]

+1 for overriding feature, should be very useful in some cases

понедельник, 10 августа 2015 г., 20:42:18 UTC+6 пользователь Adam Davis написал: