[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5372:
-------------------------------------
Description:
New and old PMML implementations should live together for some time.
See comment
was:
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
> 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.
> See comment
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5416) [DMN Designer] Header row glitch when Decision Table is included in a Function
by Valentino Pellegrino (Jira)
[ https://issues.redhat.com/browse/DROOLS-5416?page=com.atlassian.jira.plug... ]
Valentino Pellegrino updated DROOLS-5416:
-----------------------------------------
Description:
When a decision table is included in a function and more than one output column is present, the header row is duplicate
!table with duplied header's row.png|thumbnail!
was:
When a decision table is included in a function and more than one output column is present, the header row is duplicate
!image-2020-06-05-11-39-46-794.png|thumbnail!
> [DMN Designer] Header row glitch when Decision Table is included in a Function
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5416
> URL: https://issues.redhat.com/browse/DROOLS-5416
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.38.0.Final
> Reporter: Valentino Pellegrino
> Assignee: Guilherme Gomes
> Priority: Minor
> Attachments: table with duplied header's row.png
>
>
> When a decision table is included in a function and more than one output column is present, the header row is duplicate
> !table with duplied header's row.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5416) [DMN Designer] Header row glitch when Decision Table is included in a Function
by Valentino Pellegrino (Jira)
Valentino Pellegrino created DROOLS-5416:
--------------------------------------------
Summary: [DMN Designer] Header row glitch when Decision Table is included in a Function
Key: DROOLS-5416
URL: https://issues.redhat.com/browse/DROOLS-5416
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.38.0.Final
Reporter: Valentino Pellegrino
Assignee: Guilherme Gomes
When a decision table is included in a function and more than one output column is present, the header row is duplicate
!image-2020-06-05-11-39-46-794.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5415) beans.xml has wrong schemaLocation
by Marek Novotny (Jira)
[ https://issues.redhat.com/browse/DROOLS-5415?page=com.atlassian.jira.plug... ]
Marek Novotny commented on DROOLS-5415:
---------------------------------------
affected files:
./appformer/dashbuilder/dashbuilder-distros:/src/main/tomcat8/WEB-INF/beans.xml
./appformer/dashbuilder/dashbuilder-distros/src/main/wildfly10/WEB-INF/beans.xml
./appformer/uberfire-backend/uberfire-backend-cdi/src/main/resources/META-INF/beans.xml
./appformer/uberfire-commons/src/main/resources/META-INF/beans.xml
./appformer/uberfire-project/uberfire-project-backend/src/test/resources/META-INF/beans.xml
./drools-wb/drools-wb-screens/drools-wb-guided-dtable-editor/drools-wb-guided-dtable-editor-backend/src/test/resources/META-INF/beans.xml
./drools-wb/drools-wb-screens/drools-wb-guided-dtable-editor/drools-wb-guided-dtable-editor-backend/target/test-classes/META-INF/beans.xml
./kie-wb-common/kie-wb-common-cli/kie-wb-common-cli-tools/kie-wb-common-cli-project-migration/src/main/resources/META-INF/beans.xml
./kie-wb-common/kie-wb-common-services/kie-wb-common-datamodel/kie-wb-common-datamodel-backend/src/test/resources/META-INF/beans.xml
./kie-wb-common/kie-wb-common-services/kie-wb-common-services-backend/src/main/resources/META-INF/beans.xml
./kie-wb-common/kie-wb-common-services/kie-wb-common-services-backend/src/test/resources/META-INF/beans.xml
./kie-wb-common/kie-wb-common-services/kie-wb-common-verifier/kie-wb-common-verifier-service/src/main/resources/META-INF/beans.xml
./kie-wb-common/kie-wb-common-widgets/kie-wb-common-ui/src/test/resources/META-INF/beans.xml
./optaplanner-wb/optaplanner-wb-screens/optaplanner-wb-solver-editor/optaplanner-wb-solver-editor-backend/src/main/resources/META-INF/beans.xml
./optaplanner-wb/optaplanner-wb-screens/optaplanner-wb-solver-editor/optaplanner-wb-solver-editor-backend/src/test/resources/META-INF/beans.xml
> beans.xml has wrong schemaLocation
> ----------------------------------
>
> Key: DROOLS-5415
> URL: https://issues.redhat.com/browse/DROOLS-5415
> Project: Drools
> Issue Type: Bug
> Reporter: Marek Novotny
> Assignee: Marek Novotny
> Priority: Blocker
>
> Today's nightly revealed problem with xsd for beans.xml
> {{org.jboss.weld.exceptions.IllegalStateException: WELD-001202: Error parsing jar:file:/home/jenkins/.m2/repository/org/uberfire/uberfire-backend-cdi/7.39.0.20200604-050650/uberfire-backend-cdi-7.39.0.20200604-050650.jar!/META-INF/beans.xml}}
> it seems that from today oracle URL redirected resource got a html page instead of XSD file
> {noformat}
> Stack Trace:
> org.jboss.weld.exceptions.IllegalStateException: WELD-001202: Error parsing jar:file:/home/jenkins/.m2/repository/org/uberfire/uberfire-commons/7.39.0.20200604-050650/uberfire-commons-7.39.0.20200604-050650.jar!/META-INF/beans.xml
> at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:125)
> at org.jboss.weld.bootstrap.WeldBootstrap.parse(WeldBootstrap.java:131)
> at org.jboss.weld.environment.deployment.discovery.AbstractBeanArchiveScanner.parseBeansXml(AbstractBeanArchiveScanner.java:46)
> at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.scan(DefaultBeanArchiveScanner.java:77)
> at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:93)
> at org.jboss.weld.environment.se.Weld.createDeployment(Weld.java:705)
> at org.jboss.weld.environment.se.Weld.initialize(Weld.java:592)
> at org.guvnor.test.CDITestSetup.setUp(CDITestSetup.java:39)
> at org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.setUp(DRLTextEditorServiceImplCDITest.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: org.xml.sax.SAXParseException; systemId: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/beans_1_2.xsd; lineNumber: 1; columnNumber: 134; The element type "META" must be terminated by the matching end-tag "</META>".
> at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:201)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:175)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:398)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.XMLScanner.reportFatalError(XMLScanner.java:1496)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:650)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:623)
> at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(SchemaParsingConfig.java:679)
> at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(SchemaDOMParser.java:527)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168)
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:558)
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:580)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(XMLSchemaValidator.java:2722)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2082)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:789)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:283)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:733)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(SAXParserImpl.java:298)
> at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:119)
> ... 34 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ]
Gabriele Cardosi edited comment on DROOLS-5372 at 6/5/20 5:05 AM:
------------------------------------------------------------------
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# 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)
was (Author: gabriolo):
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# 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
# 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
# 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)
> 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)
6 years, 1 month
[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ]
Gabriele Cardosi edited comment on DROOLS-5372 at 6/5/20 4:59 AM:
------------------------------------------------------------------
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# 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
# 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
# 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)
was (Author: gabriolo):
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# 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
# 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, and a verification snippet that *if both implementations are present, consider the variable*
# 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)
> 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)
6 years, 1 month
[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ]
Gabriele Cardosi edited comment on DROOLS-5372 at 6/5/20 4:58 AM:
------------------------------------------------------------------
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# 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
# 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, and a verification snippet that *if both implementations are present, consider the variable*
# 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)
was (Author: gabriolo):
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# 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
# 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
> 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)
6 years, 1 month