June 2020 - jboss-jira - Jboss List Archives

[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/4/20 12:18 PM: ------------------------------------------------------------------- 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 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: ## only one is invoked; evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 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)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13353) Add a Galleon layer for the POJO subsystem

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13353?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13353: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13235 (was: https://github.com/wildfly/wildfly/pull/13235, https://github.com/wildfly/wildfly-proposals/pull/309) > Add a Galleon layer for the POJO subsystem > ------------------------------------------ > > Key: WFLY-13353 > URL: https://issues.redhat.com/browse/WFLY-13353 > Project: WildFly > Issue Type: Feature Request > Components: Build System, POJO > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Optional > Fix For: 21.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13351) Add a Galleon layer for the Mail subsystem

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13351?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13351: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13233 (was: https://github.com/wildfly/wildfly/pull/13233, https://github.com/wildfly/wildfly-proposals/pull/308) > Add a Galleon layer for the Mail subsystem > ------------------------------------------ > > Key: WFLY-13351 > URL: https://issues.redhat.com/browse/WFLY-13351 > Project: WildFly > Issue Type: Feature Request > Components: Build System, Mail > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > Fix For: 21.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[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/4/20 12:13 PM: ------------------------------------------------------------------- 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: ## only one is invoked; evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 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 was (Author: gabriolo): Most cost-effective solution would 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: ## only one is invoked; evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 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)

4 years, 7 months

1
0
0 / 0

[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/4/20 12:13 PM: ------------------------------------------------------------------- Most cost-effective solution would 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: ## only one is invoked; evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 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 was (Author: gabriolo): Most cost-effective solution would 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: ## 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 "openshift/docker" images where both modules are expected to be present in the classpath # 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)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-110) Release Elytron Web 2.0.0.Alpha4

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELYWEB-110?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved ELYWEB-110. ------------------------------------- Resolution: Done > Release Elytron Web 2.0.0.Alpha4 > -------------------------------- > > Key: ELYWEB-110 > URL: https://issues.redhat.com/browse/ELYWEB-110 > Project: Elytron Web > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-110) Release Elytron Web 2.0.0.Alpha4

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-110: --------------------------------------- Summary: Release Elytron Web 2.0.0.Alpha4 Key: ELYWEB-110 URL: https://issues.redhat.com/browse/ELYWEB-110 Project: Elytron Web Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-109) Upgrade WildFly Elytron to 2.0.0.Alpha7

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELYWEB-109?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved ELYWEB-109. ------------------------------------- Resolution: Done > Upgrade WildFly Elytron to 2.0.0.Alpha7 > --------------------------------------- > > Key: ELYWEB-109 > URL: https://issues.redhat.com/browse/ELYWEB-109 > Project: Elytron Web > Issue Type: Component Upgrade > Components: Parent > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-109) Upgrade WildFly Elytron to 2.0.0.Alpha7

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-109: --------------------------------------- Summary: Upgrade WildFly Elytron to 2.0.0.Alpha7 Key: ELYWEB-109 URL: https://issues.redhat.com/browse/ELYWEB-109 Project: Elytron Web Issue Type: Component Upgrade Components: Parent Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1725) Remove 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1725?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1725: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Remove 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ---------------------------------------------------------------------- > > Key: ELY-1725 > URL: https://issues.redhat.com/browse/ELY-1725 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Blocker > Fix For: 2.0.0.Alpha8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020