November 2019 - jboss-jira - Jboss List Archives

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

by Anna Dupliak (Jira)

[ https://issues.jboss.org/browse/DROOLS-4507?page=com.atlassian.jira.plugi... ] Anna Dupliak commented on DROOLS-4507: -------------------------------------- I got several questions on that task: Should the response be the same if kie server is not available or in case if some exception did appeared (container id was not found) What should response kie-server in case if container was corrupted Should job be restarted if the job at container was not successfully executed? What roles should the tech user has to complete the execution Is that API should be public in the meaning that we do want to provide it for anyone who has the link, or we could allow the execution for person who sends certain header information? Shouldn't we save somewhere the userId who launched the scesim? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Rhuan Rocha (Jira)

[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ] Rhuan Rocha commented on WFLY-12733: ------------------------------------ [~cfang] thank you for clarifying. About the second option exposed by you, I agree, but I think it should be configured and user should be able to enable and disable this behavior. > EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment > -------------------------------------------------------------------------------------- > > Key: WFLY-12733 > URL: https://issues.jboss.org/browse/WFLY-12733 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Rhuan Rocha > Assignee: Cheng Fang > Priority: Major > > The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. > > {code:java} > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> > </data-stores> > {code} > The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3580) [DMN Designer] Decision Table: Add support for merged view

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3580?page=com.atlassian.jira.plugi... ] Elizabeth Clayton commented on DROOLS-3580: ------------------------------------------- [~manstis] is there any UX work with this? > [DMN Designer] Decision Table: Add support for merged view > ---------------------------------------------------------- > > Key: DROOLS-3580 > URL: https://issues.jboss.org/browse/DROOLS-3580 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Edson Tirelli > Assignee: Michael Anstis > Priority: Minor > Labels: drools-tools > > Add support for viewing the {{DecisionTableGrid}} in _merged_ mode. > The underlying widget supports merging however I need to check about model synchronisation and where how we'd add a button to toggle merged/unmerged.. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on WFLY-12718: --------------------------------------- We could set this to something clearly sufficient like 15 seconds; just to make sure. > Clustering: replicated-cache sampling errors > -------------------------------------------- > > Key: WFLY-12718 > URL: https://issues.jboss.org/browse/WFLY-12718 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.0.Final > Reporter: Tommasso Borgato > Assignee: Paul Ferraro > Priority: Blocker > > The issue is about replicated-cache in fail-over tests. > WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script: > {noformat} > embed-server --server-config=standalone-ha.xml > /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add() > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add() > /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl) > {noformat} > The test is run with wildfly-18.0.0.Final.zip; > The same tests run with version wildfly-17.0.1.Final.zip do not have any problem; > hence this looks like a regression; > As usual, we test that the serial value stored in the replicated cache is incremented at every call: when this is not true, we say we have a sampling error; > Here are the runs that exhibit this issue: > - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...] > - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...] > We also repeated the tests to make sure it can be reproduced: > - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...] > - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2392) Make Java 11 the base line

by Bela Ban (Jira)

Bela Ban created JGRP-2392: ------------------------------ Summary: Make Java 11 the base line Key: JGRP-2392 URL: https://issues.jboss.org/browse/JGRP-2392 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 * Possibly make smaller changes to align with Java 11 * Module support (list exports?) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ] Cheng Fang edited comment on WFLY-12733 at 11/1/19 9:23 AM: ------------------------------------------------------------ [~rhn-support-rhsilva] I think TimerServiceImpl class is an internal implementation class and is not supposed to be directly accessed by applications. Although users can cast the standard javax.ejb.TimerService to the internal TimerServiceImpl, this type of usage is not supported and may change in the future. In this sense, adding methods to ejb timer internal classes to force refresh is not a viable option, IMHO. The other option is to have getTimers() method always refresh internally before returning results. was (Author: cfang): @reporter I think TimerServiceImpl class is an internal implementation class and is not supposed to be directly accessed by applications. Although users can cast the standard javax.ejb.TimerService to the internal TimerServiceImpl, this type of usage is not supported and may change in the future. In this sense, adding methods to ejb timer internal classes to force refresh is not a viable option, IMHO. The other option is to have getTimers() method always refresh internally before returning results. > EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment > -------------------------------------------------------------------------------------- > > Key: WFLY-12733 > URL: https://issues.jboss.org/browse/WFLY-12733 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Rhuan Rocha > Assignee: Cheng Fang > Priority: Major > > The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. > > {code:java} > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> > </data-stores> > {code} > The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12733: ----------------------------------- @reporter I think TimerServiceImpl class is an internal implementation class and is not supposed to be directly accessed by applications. Although users can cast the standard javax.ejb.TimerService to the internal TimerServiceImpl, this type of usage is not supported and may change in the future. In this sense, adding methods to ejb timer internal classes to force refresh is not a viable option, IMHO. The other option is to have getTimers() method always refresh internally before returning results. > EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment > -------------------------------------------------------------------------------------- > > Key: WFLY-12733 > URL: https://issues.jboss.org/browse/WFLY-12733 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Rhuan Rocha > Assignee: Cheng Fang > Priority: Major > > The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. > > {code:java} > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> > </data-stores> > {code} > The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12745) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Cheng Fang (Jira)

Cheng Fang created WFLY-12745: --------------------------------- Summary: EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment Key: WFLY-12745 URL: https://issues.jboss.org/browse/WFLY-12745 Project: WildFly Issue Type: Feature Request Components: EJB Reporter: Cheng Fang Assignee: Cheng Fang The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. {code:java} <data-stores> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> </data-stores> {code} The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4648) Define and Implement a DataModel to hold Background Table Data

by Anna Dupliak (Jira)

[ https://issues.jboss.org/browse/DROOLS-4648?page=com.atlassian.jira.plugi... ] Anna Dupliak updated DROOLS-4648: --------------------------------- Attachment: Dmn Change.mov > Define and Implement a DataModel to hold Background Table Data > -------------------------------------------------------------- > > Key: DROOLS-4648 > URL: https://issues.jboss.org/browse/DROOLS-4648 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Gabriele Cardosi > Priority: Major > Attachments: Dmn Change.mov, a.dmn, a.scesim.csv, admn.scesim, background-prova, bind.webm > > > This Feature is needed because currently after reopening the test scenario file, the background tab is populated with data from the model tab. For more details see the [comment|https://github.com/kiegroup/drools-wb/pull/1239#issuecomment-5436...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12744) Elytron as MPs config source

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12744?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-12744: ------------------------------------ Component/s: Security > Elytron as MPs config source > ---------------------------- > > Key: WFLY-12744 > URL: https://issues.jboss.org/browse/WFLY-12744 > Project: WildFly > Issue Type: Feature Request > Components: MP Config, Security > Reporter: Tobias Stadler > Assignee: Jeff Mesnil > Priority: Major > > I would like to be able to use credentials managed by the elytron subsytem in my application by using the microprofile config api. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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