[JBoss JIRA] (WFLY-10796) Warning about JSF version 'NONE' is shown in logs
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-10796?page=com.atlassian.jira.plugin... ]
Jan Kašík updated WFLY-10796:
-----------------------------
Description:
Following warning is shown in log upon server start:
{code}
2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead.
{code}
Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening.
was:
Following warning is shown in log upon server start:
{code}
2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead.
{code}
Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present.
> Warning about JSF version 'NONE' is shown in logs
> --------------------------------------------------
>
> Key: WFLY-10796
> URL: https://issues.jboss.org/browse/WFLY-10796
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Kašík
> Assignee: Dmitrii Tikhomirov
>
> Following warning is shown in log upon server start:
> {code}
> 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead.
> {code}
> Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
2 weeks, 5 days
[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)
5 months, 4 weeks
[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)
1 year, 1 month
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months