[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi edited comment on DROOLS-5372 at 6/8/20 6:05 AM: ------------------------------------------------------------------ Most cost-effective solution could be: # verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath ( "openshift/docker" images): ## only one is invoked; evaluate how this may be managed when both modules are expected to be present in the classpath # different issue for the PMMLRuntime, since it is defined and used in the new kie-pmml but not in the old one # Create a "NO_OP" resourcetype # Define an _environmental_ variable used to choose the implementation *but only if both are presents* (this variable is ignored if only one implementation is present) # Inside both PMMLRuntimes.getResourceType, add a verification snippet that *if both implementations are present*, consider the variable - return "NO_OP" resource type from the PMMLAssembler that has to be excluded # inside DMN: ## Create `DMNKiePMMLNewInvocationEvaluator` ## Put common code with `DMNKiePMMLInvocationEvaluator` inside `AbstractDMNKiePMMLInvocationEvaluator` ## inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich `AbstractDMNKiePMMLInvocationEvaluator` implementation (old or new) is to be used when the jpmml one is not in the classpath # Code written for *old* kie-pmml will be incompatible for new one (and the other way around) was (Author: gabriolo): Most cost-effective solution could be: # verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath ( "openshift/docker" images): ## only one is invoked; evaluate how this may be managed when both modules are expected to be present in the classpath # different issue for the PMMLRuntime, since it is defined and used in the new kie-pmml but not in the old one # Create a "NO_OP" resourcetype # Define an _environmental_ variable used to choose the implementation *but only if both are presents* (this variable is ignored if only one implementation is present) # Inside both PMMLRuntimes.getResourceType, add a verification snippet that *if both implementations are present*, consider the variable - return "NO_OP" resource type from the PMMLAssembler that has to be excluded # inside DMN: ## inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} 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 # Code written for *old* kie-pmml will be incompatible for new one (and the other way around) -- This message was sent by Atlassian Jira (v7.13.8#713008)