December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7762) Upgrade to Hibernate Validator 5.3.4

by Gunnar Morling (JIRA)

Gunnar Morling created WFLY-7762: ------------------------------------ Summary: Upgrade to Hibernate Validator 5.3.4 Key: WFLY-7762 URL: https://issues.jboss.org/browse/WFLY-7762 Project: WildFly Issue Type: Component Upgrade Reporter: Gunnar Morling Assignee: Gunnar Morling -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2095) Add AuthenticationContext references to RemoteOutboundConnectionResourceDefinition

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2095: ---------------------------------------- Summary: Add AuthenticationContext references to RemoteOutboundConnectionResourceDefinition Key: WFCORE-2095 URL: https://issues.jboss.org/browse/WFCORE-2095 Project: WildFly Core Issue Type: Feature Request Components: Remoting, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha15 The authentication-context reference will be to obtain an AuthenticationContext for the outbound connection. The following attributes should be deprecated and made mutually exclusive with the new authentication-context-attribute: - * username * security-realm * protocol -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7761) System properties for configuring global client thread pool max size on server side are ignored

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7761?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-7755 to WFLY-7761: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7761 (was: JBEAP-7755) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: (was: 7.1.0.DR9) > System properties for configuring global client thread pool max size on server side are ignored > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7761 > URL: https://issues.jboss.org/browse/WFLY-7761 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > > In EAP 7.0 you can configure global client thread pool size by system properties. This thread pool is also used by server when Artemis connects to another server. With EAP 7.0, system properties were only possibility to configure global client thread pool size on server. > This changes with EAP7-619. New model attributes are introduced as a part of this RFE. > In current implementation, values specified in model overwrite values set by system properties. In case no value is specified in EAP configuration, default values are used and system properties are overridden. > If customer used system properties to configure client thread pool size in EAP 7.0, this system property based configuration is not taken into account with EAP 7.1. > Shouldn't the system properties have higher priority than model setting? If not, this should be well documented. It would be nice to have a warning message stating that system property configured by you is not taken into account, specify value in model. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7538) WebSocketTestCase fails with security manager - Reenable the test

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7538?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7538: ---------------------------------------- The time to add a doPrivileged call to a class is when (and only when) that class is taking full responsibility for it's actions. That means it must have validated any input that it has received, especially input that will be passed on using the PrivilegedAction, it must also have verified the caller is allowed to make the call. I am going to write a blog post about this topic, we are a little too caught up on adding a doProvileged every time we see a permissions check when the permissions check taking into account a larger portion of the stack may be a more appropriate check. > WebSocketTestCase fails with security manager - Reenable the test > ----------------------------------------------------------------- > > Key: WFLY-7538 > URL: https://issues.jboss.org/browse/WFLY-7538 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Priority: Blocker > > Reenable WebSocketsTestCase. See WFLY-7539 for more details -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7295) Wrong HTTP error code for Elytron authentication when LDAP server is unreachable

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7295: -------------------------------- Assignee: Zach Rhoads (was: Jan Kalina) > Wrong HTTP error code for Elytron authentication when LDAP server is unreachable > -------------------------------------------------------------------------------- > > Key: WFLY-7295 > URL: https://issues.jboss.org/browse/WFLY-7295 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Zach Rhoads > Priority: Critical > > In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client. > Exception in server log: > {code} > ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634) > at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69) > at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 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:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 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) > Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] > at com.sun.jndi.ldap.Connection.<init>(Connection.java:216) > at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137) > at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:99) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89) > at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > at javax.naming.InitialContext.init(InitialContext.java:244) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222) > at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148) > at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562) > ... 45 more > Caused by: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350) > at com.sun.jndi.ldap.Connection.<init>(Connection.java:203) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-806) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-806?page=com.atlassian.jira.plugin.sy... ] Jan Kalina closed ELY-806. -------------------------- Resolution: Rejected Rejecting reasons can be discussed in WFLY-7219 > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-806 > URL: https://issues.jboss.org/browse/ELY-806 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: user_experience > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7219) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7219?page=com.atlassian.jira.plugin.... ] Jan Kalina closed WFLY-7219. ---------------------------- Resolution: Rejected > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: WFLY-7219 > URL: https://issues.jboss.org/browse/WFLY-7219 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Labels: user_experience > Fix For: 11.0.0.Alpha1 > > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7760) mod_cluster XML parsers are loaded eagerly

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7760: ------------------------------------ Summary: mod_cluster XML parsers are loaded eagerly Key: WFLY-7760 URL: https://issues.jboss.org/browse/WFLY-7760 Project: WildFly Issue Type: Bug Components: mod_cluster Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar We need to make use of the new API method: org.jboss.as.controller.parsing.ExtensionParsingContext#setSubsystemXmlMapping(java.lang.String, java.lang.String, java.util.function.Supplier<org.jboss.staxmapper.XMLElementReader<java.util.List<org.jboss.dmr.ModelNode>>>) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2142) RequestCorrelator broadcasts message instead of sending an unicast

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2142?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2142: -------------------------------- No, the code is correct: first copy is assigned, either to msg or msg.copy() and only *then* dest() is called on the result! > RequestCorrelator broadcasts message instead of sending an unicast > ------------------------------------------------------------------ > > Key: JGRP-2142 > URL: https://issues.jboss.org/browse/JGRP-2142 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0 > Reporter: Pedro Ruivo > Assignee: Bela Ban > Fix For: 4.0 > > > The first message sent has the destination field initialized with null. In result, the first message is broadcasted. The destination must be set. > In here: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/Req... > Code: > {{Message copy=(first? msg : msg.copy(true)).dest(mbr);}} > Possible fix: > {{Message copy=(first? msg.dest(mbr) : msg.copy(true)).dest(mbr);}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7538) WebSocketTestCase fails with security manager - Reenable the test

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7538?page=com.atlassian.jira.plugin.... ] Ingo Weiss commented on WFLY-7538: ---------------------------------- Can't this be resolved on Undertow using doPrivileged? > WebSocketTestCase fails with security manager - Reenable the test > ----------------------------------------------------------------- > > Key: WFLY-7538 > URL: https://issues.jboss.org/browse/WFLY-7538 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Priority: Blocker > > Reenable WebSocketsTestCase. See WFLY-7539 for more details -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 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 2016