August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2100: ------------------------------------- Fix Version/s: 3.0.0.CR1 (was: 3.0.0.Beta31) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3170) Upgrade Elytron Web to 1.1.0.CR2

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3170?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3170: ------------------------------------- Fix Version/s: 3.0.0.CR1 (was: 3.0.0.Beta31) > Upgrade Elytron Web to 1.1.0.CR2 > -------------------------------- > > Key: WFCORE-3170 > URL: https://issues.jboss.org/browse/WFCORE-3170 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3120) Tests broken as part of WildFly Core 3.0.0.Beta16

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3120?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3120: ------------------------------------- Fix Version/s: 3.0.0.CR1 (was: 3.0.0.Beta31) > Tests broken as part of WildFly Core 3.0.0.Beta16 > ------------------------------------------------- > > Key: WFCORE-3120 > URL: https://issues.jboss.org/browse/WFCORE-3120 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 3.0.0.CR1 > > > These tests were moved to wildfly-core previously. > Tests shown here are going to be ignored or otherwise modified in order to get the core 3.0.0.Beta16 release integrated. > org.jboss.as.test.integration.domain.elytron.SlaveHostControllerElytronAuthenticationTestCase.testSlaveRegistration > org.jboss.as.test.integration.security.perimeter.CLISecurityTestCase.testConnect -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1328) Unable to use GS2-KRB5-PLUS SASL mechanism - AP_REQ token id does not match

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1328?page=com.atlassian.jira.plugin.s... ] Farah Juma reassigned ELY-1328: ------------------------------- Assignee: Farah Juma (was: Darran Lofthouse) > Unable to use GS2-KRB5-PLUS SASL mechanism - AP_REQ token id does not match > --------------------------------------------------------------------------- > > Key: ELY-1328 > URL: https://issues.jboss.org/browse/ELY-1328 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Farah Juma > Priority: Blocker > > Invalid initial token is used on server for *GS2-KRB5-PLUS* SASL mechanism. The {{Gs2SaslServer}} uses a GSSContext to accept the token. It expects AP_REQ is comming (*{{AP_REQ_ID=256}}*), but the incomming tokenId has value *{{669}}* (value of first 2 bytes of token body). > Setting blocker as this mechanism is required by EAP7-530 and EAP7-142. > Following exception is thrown: > {noformat} > GSSException: Defective token detected (Mechanism level: AP_REQ token id does not match!) > at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:96) > at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829) > at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342) > at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) > at org.wildfly.security.sasl.gs2.Gs2SaslServer.evaluateMessage(Gs2SaslServer.java:212) > at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180) > at org.wildfly.security.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:52) > at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58) > at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106) > at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898) > 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:748) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1331) Elytron GS2-KRB5 SASL mechanism implementation throws NullPointerException on IBM JDK

by Josef Cacek (JIRA)

Josef Cacek created ELY-1331: -------------------------------- Summary: Elytron GS2-KRB5 SASL mechanism implementation throws NullPointerException on IBM JDK Key: ELY-1331 URL: https://issues.jboss.org/browse/ELY-1331 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker The Elytron GS2-KRB5 SASL mechanism doesn't work on IBM JDK. When GSSAPI is used the call works. If a user tries to use the GS2-KRB5, then the connection hangs until it times out. Following NPE comes on the client: {noformat} java.lang.NullPointerException at com.ibm.security.krb5.internal.HostAddress.<init>(HostAddress.java:62) at com.ibm.security.jgss.mech.krb5.Z.<init>(Z.java:71) at com.ibm.security.jgss.mech.krb5.g.setChannelBinding(g.java:1108) at com.ibm.security.jgss.GSSContextImpl.setChannelBinding(GSSContextImpl.java:287) at org.wildfly.security.sasl.gs2.Gs2SaslClient.<init>(Gs2SaslClient.java:120) at org.wildfly.security.sasl.gs2.Gs2SaslClientFactory.createSaslClient(Gs2SaslClientFactory.java:116) at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:110) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.PropertiesSaslClientFactory.createSaslClient(PropertiesSaslClientFactory.java:54) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:74) at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64) at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory$$Lambda$77.00000000FC19A650.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:686) at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64) at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1237) at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:347) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:418) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) at org.xnio.nio.WorkerThread.run(WorkerThread.java:571) {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8548) Annotations on overloaded methods are sometimes mixed up

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8548?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8548: ----------------------------------- Fix Version/s: 10.2.0.Final > Annotations on overloaded methods are sometimes mixed up > -------------------------------------------------------- > > Key: WFLY-8548 > URL: https://issues.jboss.org/browse/WFLY-8548 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final, 11.0.0.Beta1 > Reporter: Olaf Fricke > Assignee: Olaf Fricke > Priority: Critical > Fix For: 11.0.0.CR1, 10.2.0.Final > > Attachments: ApplicableMethodInformationTest.java > > > If a stateless session bean contains overloaded methods the annotations on these methods are sometimes mixed up. This happens for example, if two methods with the same name, the same return type and the same number of arguments exists. If both methods have different annotations or annotation values the values of the 'first' method are used. > To make things more complicated, the 'first' method depends on the JVM in use. > The bug lives in the class org.jboss.as.ejb3.deployment.ApplicableMethodInformation. I have already create a pull request to fix the issue: https://github.com/wildfly/wildfly/pull/9922 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-167) Enable fallback on thread context ClassLoader for log context scanning

by James Netherton (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-167?page=com.atlassian.jira.plugin... ] James Netherton commented on LOGMGR-167: ---------------------------------------- Ah, good point. I'll have to ponder this some more. Thanks for the prompt and useful feedback thus far. > Enable fallback on thread context ClassLoader for log context scanning > ---------------------------------------------------------------------- > > Key: LOGMGR-167 > URL: https://issues.jboss.org/browse/LOGMGR-167 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Netherton > > {{ClassLoaderLogContextSelector}} searches the call stack for a {{ClassLoader}} that's used as a map key to discover the appropriate {{LogContext}}. > If the search fails, can we add an additional check that uses the ThreadContextClassLoader to lookup the {{LogContext}} from the {{contextMap}}? > My reasoning for requesting this is described in this issue: > https://github.com/wildfly-extras/wildfly-camel/issues/1919#issuecomment-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-167) Enable fallback on thread context ClassLoader for log context scanning

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-167?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-167: -------------------------------------- I should say static loggers or effectively static loggers. Meaning say a logger initialized in a singleton. > Enable fallback on thread context ClassLoader for log context scanning > ---------------------------------------------------------------------- > > Key: LOGMGR-167 > URL: https://issues.jboss.org/browse/LOGMGR-167 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Netherton > > {{ClassLoaderLogContextSelector}} searches the call stack for a {{ClassLoader}} that's used as a map key to discover the appropriate {{LogContext}}. > If the search fails, can we add an additional check that uses the ThreadContextClassLoader to lookup the {{LogContext}} from the {{contextMap}}? > My reasoning for requesting this is described in this issue: > https://github.com/wildfly-extras/wildfly-camel/issues/1919#issuecomment-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-167) Enable fallback on thread context ClassLoader for log context scanning

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-167?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-167: -------------------------------------- There would be an issue with any static loggers in a module. If you have more than one logging-profile and more than one deployment any static loggers would be configured on whichever deployment first accesses a class that uses the logger. That's the real problem with modules using a log context other than the system log context. > Enable fallback on thread context ClassLoader for log context scanning > ---------------------------------------------------------------------- > > Key: LOGMGR-167 > URL: https://issues.jboss.org/browse/LOGMGR-167 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Netherton > > {{ClassLoaderLogContextSelector}} searches the call stack for a {{ClassLoader}} that's used as a map key to discover the appropriate {{LogContext}}. > If the search fails, can we add an additional check that uses the ThreadContextClassLoader to lookup the {{LogContext}} from the {{contextMap}}? > My reasoning for requesting this is described in this issue: > https://github.com/wildfly-extras/wildfly-camel/issues/1919#issuecomment-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-167) Enable fallback on thread context ClassLoader for log context scanning

by James Netherton (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-167?page=com.atlassian.jira.plugin... ] James Netherton commented on LOGMGR-167: ---------------------------------------- Yes, understood. For my scenario, the requirement (See ENTESB-7117) is that Camel (loaded via its own module class loader) can utilize WildFly / EAP logging profiles. The fallback on the TCCL would enable this (for this use case at least). Is there any other way for a subsystem to influence the selected {{LogContext}} (or WildFly / EAP logging in general)? Perhaps via a {{DeploymentUnitProcessor}} or similar? > Enable fallback on thread context ClassLoader for log context scanning > ---------------------------------------------------------------------- > > Key: LOGMGR-167 > URL: https://issues.jboss.org/browse/LOGMGR-167 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Netherton > > {{ClassLoaderLogContextSelector}} searches the call stack for a {{ClassLoader}} that's used as a map key to discover the appropriate {{LogContext}}. > If the search fails, can we add an additional check that uses the ThreadContextClassLoader to lookup the {{LogContext}} from the {{contextMap}}? > My reasoning for requesting this is described in this issue: > https://github.com/wildfly-extras/wildfly-camel/issues/1919#issuecomment-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 August 2017