[
https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug...
]
Gabriele Cardosi commented on DROOLS-5372:
------------------------------------------
Most cost-effective solution would be:
# 1) create a new Command with API tailored for new kie-pmml (see ApplyPmmlModelCommand as
example)
# 2) verify the behavior when *both* `PMMLAssemblerService`s (from old and new kie-pmml)
are present in the classpath:
## are both invoked? In such case, use a "property" to define which one has to
be actually invoked
## only one is invoked ? In such case, evaluate how this may be managed for
"openshofit/docker" images wher both modules are expected to be present in the
classpath
# 2) inside DMN:
## 1) inside
`AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...)` add an
"if" to choose wich kie-pmml implementation (old or new) is to be used when the
jpmml one is not in the classpath
Investigate PMML abstraction/coexistence
-----------------------------------------
Key: DROOLS-5372
URL:
https://issues.redhat.com/browse/DROOLS-5372
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Priority: Major
Labels: TrustyAI
New and old PMML implementations should live together for some time.
USer should be able to choose implementation.
Consider creating a "proxy" pmml-module that
1) declare PMMLAssemblerService
2) declare PMMLRuntime
3) delegate actuial executioin based on some variable to actual implementation (ppml-old
- pmml-new, jpmml)
This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl
--
This message was sent by Atlassian Jira
(v7.13.8#713008)