March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-110) Support non-standard transaction isolation levels

by Rich DiCroce (Jira)

Rich DiCroce created AG-110: ------------------------------- Summary: Support non-standard transaction isolation levels Key: AG-110 URL: https://issues.jboss.org/browse/AG-110 Project: Agroal Issue Type: Enhancement Reporter: Rich DiCroce Assignee: Luis Barreiro Some databases support non-standard transaction isolation levels. For example, MS SQL Server has a SNAPSHOT isolation level. Agroal currently can't support this via the transaction isolation level config option because TransactionIsolation is an enum, so it can't have custom values. It would be nice if this were supported. WildFly's "old" datasources subsystem already supports non-standard isolation levels, so it would be nice if the Agroal subsystem had parity. There is a workaround, at least on MS SQL Server. initialSql (new-connection-sql in WildFly) can be used to execute "SET TRANSACTION ISOLATION LEVEL SNAPSHOT" when the connection is created. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1766) Review relevence of webauth with Elytron authentication

by Issa Gueye (Jira)

[ https://issues.jboss.org/browse/ELY-1766?page=com.atlassian.jira.plugin.s... ] Issa Gueye edited comment on ELY-1766 at 3/13/19 3:23 PM: ---------------------------------------------------------- Keycloak is also investigating this, mainly for multi factor (2+) authentication and FIDO support. There is epic for this KEYCLOAK-7159, as well as RFEs KEYCLOAK-4182, KEYCLOAK-9365 ... https://github.com/keycloak/keycloak-community/blob/master/design/web-aut... was (Author: rhn-support-igueye): Keycloak is also investigating this, mainly for multi factor (2+) authentication and FIDO support. There is epic for this KEYCLOAK-7159, as well as RFEs KEYCLOAK-4182, KEYCLOAK-9365 ... > Review relevence of webauth with Elytron authentication > ------------------------------------------------------- > > Key: ELY-1766 > URL: https://issues.jboss.org/browse/ELY-1766 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR1 > > > Does this just make sense in IDM / SSO environments or does it make sense for direct authentication to a server. > https://www.w3.org/TR/webauthn/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1766) Review relevence of webauth with Elytron authentication

by Issa Gueye (Jira)

[ https://issues.jboss.org/browse/ELY-1766?page=com.atlassian.jira.plugin.s... ] Issa Gueye commented on ELY-1766: --------------------------------- Keycloak is also investigating this, mainly for multi factor (2+) authentication and FIDO support. There is epic for this KEYCLOAK-7159, as well as RFEs KEYCLOAK-4182, KEYCLOAK-9365 ... > Review relevence of webauth with Elytron authentication > ------------------------------------------------------- > > Key: ELY-1766 > URL: https://issues.jboss.org/browse/ELY-1766 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR1 > > > Does this just make sense in IDM / SSO environments or does it make sense for direct authentication to a server. > https://www.w3.org/TR/webauthn/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4372) Upgrade CLI to use aesh 2.0

by Jean-Francois Denise (Jira)

Jean-Francois Denise created WFCORE-4372: -------------------------------------------- Summary: Upgrade CLI to use aesh 2.0 Key: WFCORE-4372 URL: https://issues.jboss.org/browse/WFCORE-4372 Project: WildFly Core Issue Type: Component Upgrade Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4370) Add maven.repo.local property to the surefire settings for standalone tests

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-4370?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-4370: ---------------------------------- Component/s: Test Suite > Add maven.repo.local property to the surefire settings for standalone tests > --------------------------------------------------------------------------- > > Key: WFCORE-4370 > URL: https://issues.jboss.org/browse/WFCORE-4370 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > Currently any time the {{org.jboss.logmanager:jboss-logmanager}} is upgraded the {{ModuleInfoTestCase}} fails on CI as it can't find the new dependency as the cache has not been synched. The issue is that JBoss Modules uses the {{maven.local.repo}} repository to resolve the dependency, however we need to pass this parameter to surefire so that the test can see it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4371) Add maven.repo.local property to the surefire settings for standalone tests

by James Perkins (Jira)

James Perkins created WFCORE-4371: ------------------------------------- Summary: Add maven.repo.local property to the surefire settings for standalone tests Key: WFCORE-4371 URL: https://issues.jboss.org/browse/WFCORE-4371 Project: WildFly Core Issue Type: Task Reporter: James Perkins Assignee: James Perkins Currently any time the {{org.jboss.logmanager:jboss-logmanager}} is upgraded the {{ModuleInfoTestCase}} fails on CI as it can't find the new dependency as the cache has not been synched. The issue is that JBoss Modules uses the {{maven.local.repo}} repository to resolve the dependency, however we need to pass this parameter to surefire so that the test can see it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4370) Add maven.repo.local property to the surefire settings for standalone tests

by James Perkins (Jira)

James Perkins created WFCORE-4370: ------------------------------------- Summary: Add maven.repo.local property to the surefire settings for standalone tests Key: WFCORE-4370 URL: https://issues.jboss.org/browse/WFCORE-4370 Project: WildFly Core Issue Type: Task Reporter: James Perkins Assignee: James Perkins Currently any time the {{org.jboss.logmanager:jboss-logmanager}} is upgraded the {{ModuleInfoTestCase}} fails on CI as it can't find the new dependency as the cache has not been synched. The issue is that JBoss Modules uses the {{maven.local.repo}} repository to resolve the dependency, however we need to pass this parameter to surefire so that the test can see it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-638) UI Tests - Make sure incognito window is opened

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-638: ------------------------------------ Summary: UI Tests - Make sure incognito window is opened Key: SWSQE-638 URL: https://issues.jboss.org/browse/SWSQE-638 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11426) EJB call via twice remote-outbound-connection was authentication failed

by Bartosz Spyrko-Śmietanko (Jira)

[ https://issues.jboss.org/browse/WFLY-11426?page=com.atlassian.jira.plugin... ] Bartosz Spyrko-Śmietanko updated WFLY-11426: -------------------------------------------- Attachment: reproducer.zip > EJB call via twice remote-outbound-connection was authentication failed > ----------------------------------------------------------------------- > > Key: WFLY-11426 > URL: https://issues.jboss.org/browse/WFLY-11426 > Project: WildFly > Issue Type: Bug > Components: EJB, Remoting > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Priority: Major > Attachments: reproducer.zip > > > In the following environment, SaslException was thrown during calling EJB_B from EJB_A via Servlet.[1] > But EJB_A called from standalone client instad of servlet, EJB_B was finished to call successfully.[2] > Environment : > {code} > EAP1 > - Servlet > - EJB_A (inside separate ear) > EAP2 > - EJB_B > [1] Servlet -> EJB_A -> EJB_B > [2] Standalone client -> EJB_A -> EJB_B > {code} > Exception: > {code} > javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported > {code} > StackTrace: > {code} > ERROR [stderr] (default task-1) javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/server-side-ejb/ServerEJBBean", view is interface com.sample.ServerEJB, affinity is None > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:592) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528) > ERROR [stderr] (default task-1) at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:114) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:938) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:177) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112) > ERROR [stderr] (default task-1) at com.sun.proxy.$Proxy54.test(Unknown Source) > ERROR [stderr] (default task-1) Suppressed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported > ERROR [stderr] (default task-1) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:444) > ERROR [stderr] (default task-1) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > ERROR [stderr] (default task-1) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > ERROR [stderr] (default task-1) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > ERROR [stderr] (default task-1) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > ERROR [stderr] (default task-1) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > ERROR [stderr] (default task-1) at ...asynchronous invocation...(Unknown Source) > ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:571) > ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:537) > ERROR [stderr] (default task-1) at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:82) > ERROR [stderr] (default task-1) at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:55) > ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:488) > ERROR [stderr] (default task-1) at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:434) > ERROR [stderr] (default task-1) at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.getConnectedIdentityUsingClusterEffective(RemotingEJBDiscoveryProvider.java:311) > ERROR [stderr] (default task-1) at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider$DiscoveryAttempt.lambda$connectAndDiscover$0(RemotingEJBDiscoveryProvider.java:384) > ERROR [stderr] (default task-1) at java.security.AccessController.doPrivileged(Native Method) > ERROR [stderr] (default task-1) at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider$DiscoveryAttempt.connectAndDiscover(RemotingEJBDiscoveryProvider.java:384) > ERROR [stderr] (default task-1) at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.discover(RemotingEJBDiscoveryProvider.java:151) > ERROR [stderr] (default task-1) at org.jboss.ejb.protocol.remote.RemoteEJBDiscoveryConfigurator.lambda$configure$0(RemoteEJBDiscoveryConfigurator.java:42) > ERROR [stderr] (default task-1) at org.wildfly.discovery.impl.AggregateDiscoveryProvider.discover(AggregateDiscoveryProvider.java:58) > ERROR [stderr] (default task-1) at org.wildfly.discovery.Discovery.discover(Discovery.java:100) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.discover(DiscoveryEJBClientInterceptor.java:241) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.doAnyDiscovery(DiscoveryEJBClientInterceptor.java:370) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.executeDiscovery(DiscoveryEJBClientInterceptor.java:304) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:94) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:63) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491) > ERROR [stderr] (default task-1) at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:327) > ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:173) > ERROR [stderr] (default task-1) ... 122 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Richard Achmatowicz commented on WFLY-11682: -------------------------------------------- I have had a look at the crash scenario. When a discovery call is made, it consists of two parts: refreshing the discovered node registry (DNR) before carrying out the search, then carrying out the search in the DNR. The refresh of the DNR is done by attempting to create an authenticated connection followed by a client channel to the set of configured connections (those listed in the client context configuration file) as well as any known URIs received as topology updates. When the connections/channels are attempted, the discovery provider keeps track of exceptions encountered during connection establishment and also during channel establishment. We would be interested in java.net.ConnectException raised during connection establishment. If we can keep track of those during the refresh of the DNR, they could be used to remove any cluster nodes which were the only node in the cluster and which raised a connect exception before the search starts. > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: node1.txt, node12.txt, node2.txt, node3.txt, playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 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 March 2019