6:23 a.m.
As part of my drools-scala project I am implementing evalators for scala
collections. This means that the some default evaluator operators like
"contains" and "memberOf" need to be overridden. My problem is that
drools
seems to load the evaluators as defined in meta-infa/(I forget the file
name) in an arbitrary manner. This results in my scala evaluator getting
registered and then the default evaluator getting registered, overriding the
scala evaluator.
Has this variant of extensibility been considered -- not adding evaluators
as that works great -- but overriding a drools implementation? If not, I'll
have to do some internals hacking.
-bk
--
View this message in context:
http://n3.nabble.com/Overriding-default-evaluators-tp441342p441342.html
Sent from the Drools - User mailing list archive at Nabble.com.
3:57 p.m.
Barry,
Any user registered evaluators should override the default ones, not the
other way around. How are you registering your implementations?
Edson
2010/3/11 Barry Kaplan <groups1(a)memelet.com>
As part of my drools-scala project I am implementing evalators for scala
collections. This means that the some default evaluator operators like
"contains" and "memberOf" need to be overridden. My problem is that
drools
seems to load the evaluators as defined in meta-infa/(I forget the file
name) in an arbitrary manner. This results in my scala evaluator getting
registered and then the default evaluator getting registered, overriding
the
scala evaluator.
Has this variant of extensibility been considered -- not adding evaluators
as that works great -- but overriding a drools implementation? If not, I'll
have to do some internals hacking.
-bk
--
View this message in context:
http://n3.nabble.com/Overriding-default-evaluators-tp441342p441342.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
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
5:17 p.m.
That may be how its supposed to work, but it does not.
PackageBuilderConfiguration#buildEvaluatorRegistry selects properties from
'chainedProperties' from the two collections of properties -- the drools
default and the scala extensions -- into a single map. It then adds the
evaluators from that combined map, which is now intermingled so the add
order is undefined.
My workaround was, after the registry is first created but before any drls
are parsed (hack alert):
def registerScalaEvaluators(kbuilder: KnowledgeBuilder) {
val kbuilderConfig =
kbuilder.asInstanceOf[KnowledgeBuilderImpl].getPackageBuilder.getPackageBuilderConfiguration
val chainedProperties = kbuilderConfig.getChainedProperties
val evaluatorRegistry = kbuilderConfig.getEvaluatorRegistry
val scalaEntries = new java.util.HashMap[String, String]
chainedProperties.mapStartsWith(scalaEntries,
EvaluatorOption.PROPERTY_NAME+"scala_", true)
for (className <- scalaEntries.values) {
evaluatorRegistry.addEvaluatorDefinition(className)
}
}
--
View this message in context:
http://n3.nabble.com/Overriding-default-evaluators-tp441342p442360.html
Sent from the Drools - User mailing list archive at Nabble.com.
5:24 p.m.
I should point out that this is only a problem when overriding operators.
But I won't, at least here, go into the other nasty hacks I have to do to
get around the non-polymorphic ValueType systems. I'm assuming that that
design is there for performance reasons (ie, to eliminate the need for
instanceOf checks) but it really creates serious smells all over the code
base. Ok, I guess I'm going into it ;-)
Consider SetEvaluatorDefintion. It has to define duplicate evaluators for
all the ValueTypes -- even though they all do the same thing. This
duplication is seems to exists only to support the lookup of evaluators by
ValueType. Of course I did not follow this pattern in the scala evaluators
since I'm way too lazy for that ;-)
Anyway, I've worked around all my issues for now. Once I get mostly done
with scala extensions to the DRL syntax I'll compile my issues and maybe we
can discuss modifications to drools internals.
--
View this message in context:
http://n3.nabble.com/Overriding-default-evaluators-tp441342p442366.html
Sent from the Drools - User mailing list archive at Nabble.com.
5221
days inactive
5221
days old
3 comments
2 participants
participants (2)
-
Barry Kaplan -
Edson Tirelli