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: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)

5 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)

5 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)

5 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)

5 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)

5 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1539) Remove deprecated AuthConf setHost, setProtocol, setPort properties

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1539?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1539: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Remove deprecated AuthConf setHost, setProtocol, setPort properties > ------------------------------------------------------------------- > > Key: ELY-1539 > URL: https://issues.redhat.com/browse/ELY-1539 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Priority: Critical > Fix For: 2.0.0.Alpha8 > > > We should deprecate (with a view towards removal) the setHost, setPort, and setProtocol properties of AuthenticationConfiguration. These properties are only sporadically utilized by backing systems, and often cause complex problems when they are used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1735) Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1735?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1735: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1735 > URL: https://issues.redhat.com/browse/ELY-1735 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 1.13.0.CR1, 2.0.0.Alpha8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1737) Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1737?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1737: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1737 > URL: https://issues.redhat.com/browse/ELY-1737 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 1.13.0.CR1, 2.0.0.Alpha8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020