[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3944?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3944:
--------------------------------------
Sprint: 2019 Week 23-25
> DMN Editor: Data type usability study
> -------------------------------------
>
> Key: DROOLS-3944
> URL: https://issues.jboss.org/browse/DROOLS-3944
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Sarahjane Clark
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
> GOALS: Access the Data Type editor in terms of productivity and usability.
> * Ease of use when creating a complex type (concern: minimizing the mouse usage.)
> * Ease of use when saving a basic data type (e.g. age: number)
> * Discoverability of actions in the kebab menu, especially, insert nested, delete.
> * Ease of use/accuracy: Type-ahead of the data type selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
3 months, 1 week
[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension
by Florian Sailer (Jira)
Florian Sailer created WFLY-12461:
-------------------------------------
Summary: Can't use smallrye-health without weld extension
Key: WFLY-12461
URL: https://issues.jboss.org/browse/WFLY-12461
Project: WildFly
Issue Type: Bug
Components: MP Health
Affects Versions: 17.0.1.Final
Reporter: Florian Sailer
Assignee: Jeff Mesnil
Since this commit in the smallrye implementation it was possible to use smallrye without CDI.
https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29...
I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld.
I am getting the following exception while starting:
14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available:
org.wildfly.weld; There are no known registration points which can provide this capability.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
1 year, 9 months
[JBoss JIRA] (WFLY-12744) Elytron as MPs config source
by Tobias Stadler (Jira)
Tobias Stadler created WFLY-12744:
-------------------------------------
Summary: 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
Reporter: Tobias Stadler
Assignee: Jeff Mesnil
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)
5 years, 1 month
[JBoss JIRA] (ELY-1897) HashiCorp Vault as credential source
by Tobias Stadler (Jira)
Tobias Stadler created ELY-1897:
-----------------------------------
Summary: HashiCorp Vault as credential source
Key: ELY-1897
URL: https://issues.jboss.org/browse/ELY-1897
Project: WildFly Elytron
Issue Type: Feature Request
Reporter: Tobias Stadler
Assignee: Darran Lofthouse
I would like to be able to use HashiCorp Vault as source for my datasource credentials
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-12718:
-------------------------------------
[~tommaso-borgato] If you bump the suspend timeout to 5 seconds, do the sampling errors go down to zero (or close to it)?
> 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)
5 years, 1 month
[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12733:
-----------------------------------------
Hi [~rhn-support-rhsilva]! I have the same question about that class/method.
> 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)
5 years, 1 month
[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:
------------------------------------
[~brian.stansberry] I sent a pull request. I have created a method in TimerServiceImpl to call refresh the DatabaseTimerPersistence
> 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)
5 years, 1 month
[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12733:
-----------------------------------------
DatabaseTimerPersistence is an internal class so adding API to it has no effect. Are you also looking for the addition of management operation to call this?
[~cfang] This would need to go through the WildFly RFE process.
> 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)
5 years, 1 month
[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-12733:
---------------------------------------
Component/s: EJB
Assignee: Cheng Fang (was: Brian Stansberry)
> 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)
5 years, 1 month