December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-855) Add ability to merge AuthenticationConfigurations

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-855?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-855 at 12/14/17 5:16 AM: ---------------------------------------------------------- This is already implemented: https://github.com/wildfly-security/wildfly-elytron/commit/2c30498801dd2a... was (Author: honza889): This is already implemented: https://github.com/wildfly-security/wildfly-elytron/blame/master/src/main... > Add ability to merge AuthenticationConfigurations > ------------------------------------------------- > > Key: ELY-855 > URL: https://issues.jboss.org/browse/ELY-855 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta29 > > > We need a "with" method on AuthenticationConfiguration which appends one configuration to another. This allows for fallback defaults. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2177) [DMN Editor] EditableHeaderMetaData should destroy resources

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-2177: -------------------------------------- Summary: [DMN Editor] EditableHeaderMetaData should destroy resources Key: DROOLS-2177 URL: https://issues.jboss.org/browse/DROOLS-2177 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Michael Anstis Assignee: Michael Anstis {{EditableHeaderMetaData}} Uses {{DOMElementFactory}} for {{DOMElement}} used to edit the header's content. If the User starts editing a column header and then performs some action (such as resizing a column, panning, etc) the {{DOMElement}} is not destroyed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-855) Add ability to merge AuthenticationConfigurations

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-855?page=com.atlassian.jira.plugin.sy... ] Jan Kalina closed ELY-855. -------------------------- > Add ability to merge AuthenticationConfigurations > ------------------------------------------------- > > Key: ELY-855 > URL: https://issues.jboss.org/browse/ELY-855 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta29 > > > We need a "with" method on AuthenticationConfiguration which appends one configuration to another. This allows for fallback defaults. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1119) Setting sasl-mechanism-selector with some name value in Elytron client configuration file causes NPE during parsing

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1119?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1119. --------------------------- > Setting sasl-mechanism-selector with some name value in Elytron client configuration file causes NPE during parsing > ------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1119 > URL: https://issues.jboss.org/browse/ELY-1119 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.1.0.Beta39 > Reporter: Ondrej Lukas > Priority: Critical > Fix For: 1.1.0.Beta41 > > > In case when sasl-mechanism-selector is set in Elytron client configuration file then parsing of configuration file throws NPE. For following element (since there is no documentation then I tried to use values "someName", "NONE", "PLAIN" instead of someName): > {code} > <sasl-mechanism-selector selector="someName"/> > {code} > is following NPE thrown: > {code} > ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /dep/authenticationContext: java.lang.NullPointerException > at org.wildfly.security.sasl.SaslMechanismSelector$AddSelector.addHashCode(SaslMechanismSelector.java:768) > at org.wildfly.security.sasl.SaslMechanismSelector.hashCode(SaslMechanismSelector.java:177) > at org.wildfly.security.sasl.SaslMechanismSelector.equals(SaslMechanismSelector.java:188) > at org.wildfly.security.sasl.SaslMechanismSelector.equals(SaslMechanismSelector.java:184) > at java.util.Objects.equals(Objects.java:59) > at org.wildfly.security.auth.client.AuthenticationConfiguration.setSaslMechanismSelector(AuthenticationConfiguration.java:1037) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$18(ElytronXmlParser.java:640) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:704) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$7(ElytronXmlParser.java:513) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:537) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:308) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141) > at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:116) > at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.doGet(WildflyConfigXmlServlet.java:91) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1064) Deprecate "purpose" match criteria and parameter

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1064?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1064. --------------------------- > Deprecate "purpose" match criteria and parameter > ------------------------------------------------ > > Key: ELY-1064 > URL: https://issues.jboss.org/browse/ELY-1064 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Fix For: 1.1.0.Beta51 > > > The "purpose" property was a mistake; it will not be used by any of the Elytron-aware client libraries. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1213) Remove match-purpose from Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1213?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1213. --------------------------- > Remove match-purpose from Elytron > --------------------------------- > > Key: ELY-1213 > URL: https://issues.jboss.org/browse/ELY-1213 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta47 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta51 > > > Match purpose should be entirely removed, see [1]. It means it should be removed from API, Elytron subsystem and Elytron client configuration file. > We request blocker flag to avoid situation where match-purpose occurs in GA. > [1] https://issues.jboss.org/browse/JBEAP-11144?focusedCommentId=13413867&pag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2237: --------------------------- Attachment: bla3.java > The single node in the cluster not become a coordinator after coordinator leave. > -------------------------------------------------------------------------------- > > Key: JGRP-2237 > URL: https://issues.jboss.org/browse/JGRP-2237 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.2, 4.0.8 > Reporter: kfir avraham > Assignee: Bela Ban > Priority: Minor > Attachments: Server_A.txt, Server_A_Trace_mode.rtf, Server_B.txt, Server_B_Trace_mode.rtf, bla3.java, conf.txt, test.xml > > > I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator. > When the first one is rejoin, he could not determine coordinator and select new one from the nodes list. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2237: -------------------------------- I wrote a simple program which continually disconnects and then reconnects the coordinator (bla3, attached). I ran it for over a 1000 disconnect/reconnect sequences and it never failed. Run it yourself (change the path to the properties), to see if it fails. {noformat} ------------------------------------------------------------------- GMS: address=A, cluster=demo, physical address=127.0.0.1:7800 ------------------------------------------------------------------- -- view: [B|1071] (2) [B, A] -- view: [A|1072] (1) [A] -- view: [A|1073] (2) [A, B] {noformat} > The single node in the cluster not become a coordinator after coordinator leave. > -------------------------------------------------------------------------------- > > Key: JGRP-2237 > URL: https://issues.jboss.org/browse/JGRP-2237 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.2, 4.0.8 > Reporter: kfir avraham > Assignee: Bela Ban > Priority: Minor > Attachments: Server_A.txt, Server_A_Trace_mode.rtf, Server_B.txt, Server_B_Trace_mode.rtf, conf.txt, test.xml > > > I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator. > When the first one is rejoin, he could not determine coordinator and select new one from the nodes list. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

by Scott Van Wart (JIRA)

[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ] Scott Van Wart commented on WFLY-9529: -------------------------------------- [~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry. Sometimes it works and sometimes it doesn't--and if it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)? Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans? For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour. Thanks so much for the information. > Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9529 > URL: https://issues.jboss.org/browse/WFLY-9529 > Project: WildFly > Issue Type: Bug > Components: JMS, Naming > Affects Versions: 10.1.0.Final, 11.0.0.Final > Environment: Running on Windows 10, Java 64-bit 1.8.0_131 > Reporter: Scott Van Wart > Assignee: Eduardo Martins > Labels: ActiveMQ, jms, transaction > Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt > > > If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread. > My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions. > I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

by Scott Van Wart (JIRA)

[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ] Scott Van Wart edited comment on WFLY-9529 at 12/13/17 7:50 PM: ---------------------------------------------------------------- [~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry. Sometimes it works and sometimes it doesn't. If it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)? Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans? For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour. Thanks so much for the information. was (Author: silvaran): [~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry. Sometimes it works and sometimes it doesn't--and if it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)? Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans? For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour. Thanks so much for the information. > Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9529 > URL: https://issues.jboss.org/browse/WFLY-9529 > Project: WildFly > Issue Type: Bug > Components: JMS, Naming > Affects Versions: 10.1.0.Final, 11.0.0.Final > Environment: Running on Windows 10, Java 64-bit 1.8.0_131 > Reporter: Scott Van Wart > Assignee: Eduardo Martins > Labels: ActiveMQ, jms, transaction > Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt > > > If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread. > My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions. > I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 December 2017