October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-240) Galleon MAVEN_ARGS should also contain default values

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-240: ------------------------------------------ Summary: Galleon MAVEN_ARGS should also contain default values Key: WFWIP-240 URL: https://issues.jboss.org/browse/WFWIP-240 Project: WildFly WIP Issue Type: Bug Reporter: Jean Francois Denise Assignee: Jean Francois Denise -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-239) Galleon layers provisioning should be in offline mode

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-239: ------------------------------------------ Summary: Galleon layers provisioning should be in offline mode Key: WFWIP-239 URL: https://issues.jboss.org/browse/WFWIP-239 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Jean Francois Denise Assignee: Jean Francois Denise The set of galleon layers one can provision using GALLEON_PROVISION_LAYERS is limited to the one contained in the eap-cd-s2i feature-pack. No need to resolve remote artifacts. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-238) SSO support should have dual security

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-238: ------------------------------------------ Summary: SSO support should have dual security Key: WFWIP-238 URL: https://issues.jboss.org/browse/WFWIP-238 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Jean Francois Denise Assignee: Jean Francois Denise Currently SSO configuration uses elytron, it is a change with prior configuration. SSO support should detect if security subsystem is present and use it. Elytron being used only if legacy security subsystem is not there. This offers a backward compatible configuration. Obviously this should be tuned in order to "modernize" the configuration by using elytron in all cases. That is made possible using the SSO_FORCE_ELYTRON_SECURITY=true. That is what WildFly s2i is using by default. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4629) DMN heuristic for invocation name

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4629: -------------------------------------- Summary: DMN heuristic for invocation name Key: DROOLS-4629 URL: https://issues.jboss.org/browse/DROOLS-4629 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Ref https://issues.jboss.org/browse/RHDM-980?focusedCommentId=13796841&page=c... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4628) Fix PodAsALeaderSnapshotTest random failure

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-4628: ------------------------------------------ Summary: Fix PodAsALeaderSnapshotTest random failure Key: DROOLS-4628 URL: https://issues.jboss.org/browse/DROOLS-4628 Project: Drools Issue Type: Bug Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4507) Ability to externally execute project defined tests.

by Toni Rikkola (Jira)

[ https://issues.jboss.org/browse/DROOLS-4507?page=com.atlassian.jira.plugi... ] Toni Rikkola commented on DROOLS-4507: -------------------------------------- [~danielezonca] [This one|https://github.com/kiegroup/appformer/blob/17bb30f36f8a12a55471fb4bbc...] But I don't think this matches the requirement of running against a kjar. > Ability to externally execute project defined tests. > ---------------------------------------------------- > > Key: DROOLS-4507 > URL: https://issues.jboss.org/browse/DROOLS-4507 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Paul Brown > Assignee: Daniele Zonca > Priority: Major > > Provide the ability to externally invoke project define tests scenario i.e via a rest api. > This is required in order for project defined tests to be reused and executed as part of a delivery pipeline and not from within business central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3957) Make verifier panel use docks

by Toni Rikkola (Jira)

[ https://issues.jboss.org/browse/DROOLS-3957?page=com.atlassian.jira.plugi... ] Toni Rikkola updated DROOLS-3957: --------------------------------- Sprint: (was: 2019 Week 41-43 (from Okt 7)) > Make verifier panel use docks > ----------------------------- > > Key: DROOLS-3957 > URL: https://issues.jboss.org/browse/DROOLS-3957 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > Attachments: v&v.webm > > > Pretty sure we had a ticket for this, but could not find it. Here it is. > h3. Acceptance test > On both Firefox and Chrome (x) > - Opening multiple decision tables, switching between them > - Repeated reopening of guided decision table > - Opening other asset that uses docks - scenario, data object -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4627) DMN DS invocation message for parameter name coercion

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4627: -------------------------------------- Summary: DMN DS invocation message for parameter name coercion Key: DROOLS-4627 URL: https://issues.jboss.org/browse/DROOLS-4627 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Wrong parameter name reported in message (type of message is correct) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4626) Inserting already expired events are not taken into account in the collect operation in the first fireAllRules

by Oscar Molina (Jira)

Oscar Molina created DROOLS-4626: ------------------------------------ Summary: Inserting already expired events are not taken into account in the collect operation in the first fireAllRules Key: DROOLS-4626 URL: https://issues.jboss.org/browse/DROOLS-4626 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.27.0.Final Reporter: Oscar Molina Assignee: Mario Fusco Migrating a project from Drools 6.5.x to 7.x, if we insert already expired events, they are not taken into account in the collect operation in the first fireAllRules. Expired event in STREAM mode are not taken into account when using collect operation. it seems not to be aligned with drools design requirement: "Expired events does not cancel rule activations". This was not the case with the last 6.5 version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1888) Review Context Association

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1888: ------------------------------------- Summary: Review Context Association Key: ELY-1888 URL: https://issues.jboss.org/browse/ELY-1888 Project: WildFly Elytron Issue Type: Task Components: API / SPI, MicroProfile Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha5 Our APIs are very much written for objects to be associated with the current Thread and to remain associated either until they are replaced or the call stack returns to the point where association occurs and the association is automatically removed. Concurrent APIs are always a problem in this area as a "request" can now traverse multiple Threads, issues arise in relation to propagation to worker threads but also potentially in the association for any resulting callbacks / resumption of work across different threads. We should double check our relationship with Jakarta Concurrency: - https://projects.eclipse.org/projects/ee4j.cu The following specification within MicroProfile is looking into some mechanisms for this association: - https://github.com/eclipse/microprofile-context-propagation It may be preferable for our APIs to remain unchanged but instead we provide sufficient integration to capture our current context specific instances and propagate them. As we have more than one item that can be associated we may want to review if we want to use a single context internally that associates multiple items so we only have one item to propagate. Generally the items we associate are immutable so cross Thread modifications are not likely to be an issue. Alternatively we may choose to revisit our association APIs. Overall creating this issue for now as it is an area we will need to investigate further and plan for - tentatively scheduled against 2.0 although I suspect we will need to handle this within a 1.x release. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 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 October 2019