July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13648) Make PicketBox PolicyContextHandlers discoverable using ServiceLoader<>

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13648?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13648: ------------------------------------ Description: By making them available using ServlceLoader discovery it will mean the Elytron subsystem will not need mandatory dependencies on PicketBox or the legacy security subsystem to co-exist with the legacy implementations. was: Where components in WildFly Core depend on PicketBox we should make sure this is via a module which they can optional depend upon so avoid components in WildFly Core having hard dependencies on PicketBox APIs. Initially this will hold the PicketBox JACC PolicyContextHandler integrations exposed for ServiceLoader discovery so they can be removed from WildFly. > Make PicketBox PolicyContextHandlers discoverable using ServiceLoader<> > ----------------------------------------------------------------------- > > Key: WFLY-13648 > URL: https://issues.redhat.com/browse/WFLY-13648 > Project: WildFly > Issue Type: Task > Components: Build System, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > By making them available using ServlceLoader discovery it will mean the Elytron subsystem will not need mandatory dependencies on PicketBox or the legacy security subsystem to co-exist with the legacy implementations. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13648) Make PicketBox PolicyContextHandlers discoverable using ServiceLoader<>

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13648?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13648: ------------------------------------ Summary: Make PicketBox PolicyContextHandlers discoverable using ServiceLoader<> (was: Add a new legacy-security artefact / module) > Make PicketBox PolicyContextHandlers discoverable using ServiceLoader<> > ----------------------------------------------------------------------- > > Key: WFLY-13648 > URL: https://issues.redhat.com/browse/WFLY-13648 > Project: WildFly > Issue Type: Task > Components: Build System, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > Where components in WildFly Core depend on PicketBox we should make sure this is via a module which they can optional depend upon so avoid components in WildFly Core having hard dependencies on PicketBox APIs. > > Initially this will hold the PicketBox JACC PolicyContextHandler integrations exposed for ServiceLoader discovery so they can be removed from WildFly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5491) Integrate PMML with Kogito

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5491: ---------------------------------------- Summary: Integrate PMML with Kogito Key: DROOLS-5491 URL: https://issues.redhat.com/browse/DROOLS-5491 Project: Drools Issue Type: Feature Request Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Integrate new PMML implementation (trusty) with Kogito -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Avoid needs of kmodule.xml during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Description: Current code is written with the assumption that model name is provided by all model definitions. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. kmodule.xml has to be code-generated, and not provided by user was: Current code is written with the assumption that model name is provided by all model definitions. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. Code-generate kmodule.xml > Avoid needs of kmodule.xml during kiepmmlmodel generation/instantiation > ----------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. > kmodule.xml has to be code-generated, and not provided by user > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Avoid needs of kmodule.xml during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Summary: Avoid needs of kmodule.xml during kiepmmlmodel generation/instantiation (was: Avoid usage of kmodule.xml during kiepmmlmodel generation/instantiation) > Avoid needs of kmodule.xml during kiepmmlmodel generation/instantiation > ----------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. > Code-generate kmodule.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Avoid usage of kmodule.xml during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Summary: Avoid usage of kmodule.xml during kiepmmlmodel generation/instantiation (was: Fixing model name/package name management during kiepmmlmodel generation/instantiation) > Avoid usage of kmodule.xml during kiepmmlmodel generation/instantiation > ----------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. > Code-generate kmodule.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Fixing model name/package name management during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Description: Current code is written with the assumption that model name is provided by all model definitions. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. Code-generate kmodule.xml was: Current code is written with the assumption that model name is provided by all model definitions. That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. Code-generate kmodule.xml > Fixing model name/package name management during kiepmmlmodel generation/instantiation > -------------------------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. > Code-generate kmodule.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5490) Implement built-in functions scheleton management

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5490?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5490: ------------------------------------- Parent: (was: DROOLS-5247) Issue Type: Feature Request (was: Sub-task) > Implement built-in functions scheleton management > ------------------------------------------------- > > Key: DROOLS-5490 > URL: https://issues.redhat.com/browse/DROOLS-5490 > Project: Drools > Issue Type: Feature Request > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Implement common flow for [built-inf functions|http://dmg.org/pmml/v4-4-1/BuiltinFunctions.html]. > Implement > * [if|http://dmg.org/pmml/v4-4-1/BuiltinFunctions.html#boolean6] > * [uppercase|http://dmg.org/pmml/v4-4-1/BuiltinFunctions.html#uppercase] > * [lowercase|http://dmg.org/pmml/v4-4-1/BuiltinFunctions.html#lowercase] > as example -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13633: ----------------------------------------- This is just a thought, I have not tested or thought the proposal through fully but it might help in conjunction with [~brian.stansberry]'s synchonization suggestion in https://issues.redhat.com/browse/WFLY-13633 To not break backwards compatibility in Narayana, perhaps a new operation could be added to the bean that directly manipulate https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... Something like: {code} public void removeCommitMarkableResourceJNDIName(String name) { synchronized (this) { // not using commitMarkableResourceJNDINames because it could be changed commitMarkableResourceJNDINames.remove(name); } } {code} We might need to protect / synchronize other parts of the code that manipulate commitMarkableResourceJNDINames and callers that interact with it such as the area that Brian mentioned but it might get over the initial issue. > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13632: ----------------------------------------- Thanks [~brian.stansberry]. If we were to want to synchronize here, we would need to make sure effectively that the whole method was synchronized on the bean. That is because pairs like https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... and https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... need to be locked, the same for the similar interactions on the jtaEnvironmentBean maps. That said, synchronization could fix this issue but we would still have https://issues.redhat.com/browse/WFLY-13633 /cc [~mmusgrov] [~ochaloup] > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020