[JBoss JIRA] (ELY-1556) [GSS](7.1.z) NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1556?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev moved JBEAP-14539 to ELY-1556:
--------------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1556 (was: JBEAP-14539)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: Security)
Affects Version/s: 1.1.9.Final
(was: 7.1.1.GA)
Fix Version/s: (was: 7.1.3.GA)
> [GSS](7.1.z) NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1556
> URL: https://issues.jboss.org/browse/ELY-1556
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.9.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> After enabling elytron, the security subsystem was removed. The war using jboss-web.xml security-domain looks like it is not used when the picketbox security subsystem is removed.
> {code}
> java.lang.NullPointerException
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> 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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 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.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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 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:330)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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}
> The war has jboss-web.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>other</security-domain>
> </jboss-web>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:undertow:4.0">
> ...
> <application-security-domains>
> <application-security-domain name="other" http-authentication-factory="application-http-authentication"/>
> </application-security-domains>
> </subsystem>
> <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
> ...
> <http>
> <http-authentication-factory name="application-http-authentication" http-server-mechanism-factory="global" security-domain="ApplicationDomain">
> <mechanism-configuration>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="Application Realm"/>
> </mechanism>
> <mechanism mechanism-name="FORM"/>
> </mechanism-configuration>
> </http-authentication-factory>
> <provider-http-server-mechanism-factory name="global"/>
> </http>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1556) NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1556?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev updated ELY-1556:
-------------------------------
Summary: NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed (was: [GSS](7.1.z) NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed)
> NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
> -----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1556
> URL: https://issues.jboss.org/browse/ELY-1556
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.9.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> After enabling elytron, the security subsystem was removed. The war using jboss-web.xml security-domain looks like it is not used when the picketbox security subsystem is removed.
> {code}
> java.lang.NullPointerException
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> 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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 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.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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 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:330)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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}
> The war has jboss-web.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>other</security-domain>
> </jboss-web>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:undertow:4.0">
> ...
> <application-security-domains>
> <application-security-domain name="other" http-authentication-factory="application-http-authentication"/>
> </application-security-domains>
> </subsystem>
> <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
> ...
> <http>
> <http-authentication-factory name="application-http-authentication" http-server-mechanism-factory="global" security-domain="ApplicationDomain">
> <mechanism-configuration>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="Application Realm"/>
> </mechanism>
> <mechanism mechanism-name="FORM"/>
> </mechanism-configuration>
> </http-authentication-factory>
> <provider-http-server-mechanism-factory name="global"/>
> </http>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1556) NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1556?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1556:
----------------------------------
Assignee: Darran Lofthouse (was: Ilia Vassilev)
> NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
> -----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1556
> URL: https://issues.jboss.org/browse/ELY-1556
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.9.Final
> Reporter: Ilia Vassilev
> Assignee: Darran Lofthouse
>
> After enabling elytron, the security subsystem was removed. The war using jboss-web.xml security-domain looks like it is not used when the picketbox security subsystem is removed.
> {code}
> java.lang.NullPointerException
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> 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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 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.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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 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:330)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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}
> The war has jboss-web.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>other</security-domain>
> </jboss-web>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:undertow:4.0">
> ...
> <application-security-domains>
> <application-security-domain name="other" http-authentication-factory="application-http-authentication"/>
> </application-security-domains>
> </subsystem>
> <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
> ...
> <http>
> <http-authentication-factory name="application-http-authentication" http-server-mechanism-factory="global" security-domain="ApplicationDomain">
> <mechanism-configuration>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="Application Realm"/>
> </mechanism>
> <mechanism mechanism-name="FORM"/>
> </mechanism-configuration>
> </http-authentication-factory>
> <provider-http-server-mechanism-factory name="global"/>
> </http>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1555) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1555?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev updated ELY-1555:
-------------------------------
Summary: DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem (was: [GSS](7.1.z) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem)
> DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem
> -------------------------------------------------------------------------------------------------
>
> Key: ELY-1555
> URL: https://issues.jboss.org/browse/ELY-1555
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.9.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> After running the enable-elytron.cli and removing the old
> picketbox security subsystem, the deployment fails as
> it cannot find java:jboss/DefaultJMSConnectionFactory.
> java:jboss/DefaultJMSConnectionFactory is defined in the messaging
> subsystem and the ee default-bindings.
> Removing it from the ee default-bindings lets the app deploy, but it looks like there is some
> issue as it should be bound and no errors/warnings being logged.
> {code}
> 2018-04-02 12:15:36,593 ERROR
> [org.jboss.as.controller.management-operation] (Controller Boot Thread)
> WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" =>
> "ejb-security.jar")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" =>
> ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" =>
> ["jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory
> is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> }
> 2018-04-02 12:15:36,603 INFO [org.jboss.as.server] (ServerService
> Thread Pool -- 42) WFLYSRV0010: Deployed "ejb-security.jar"
> (runtime-name : "ejb-security.jar")
> 2018-04-02 12:15:36,607 INFO [org.jboss.as.controller] (Controller Boot
> Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service
> jboss.naming.context.java.jboss.DefaultJMSConnectionFactory (missing)
> dependents: [service
> jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1555) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1555?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1555:
----------------------------------
Assignee: Darran Lofthouse (was: Ilia Vassilev)
> DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem
> -------------------------------------------------------------------------------------------------
>
> Key: ELY-1555
> URL: https://issues.jboss.org/browse/ELY-1555
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.9.Final
> Reporter: Ilia Vassilev
> Assignee: Darran Lofthouse
>
> After running the enable-elytron.cli and removing the old
> picketbox security subsystem, the deployment fails as
> it cannot find java:jboss/DefaultJMSConnectionFactory.
> java:jboss/DefaultJMSConnectionFactory is defined in the messaging
> subsystem and the ee default-bindings.
> Removing it from the ee default-bindings lets the app deploy, but it looks like there is some
> issue as it should be bound and no errors/warnings being logged.
> {code}
> 2018-04-02 12:15:36,593 ERROR
> [org.jboss.as.controller.management-operation] (Controller Boot Thread)
> WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" =>
> "ejb-security.jar")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" =>
> ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" =>
> ["jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory
> is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> }
> 2018-04-02 12:15:36,603 INFO [org.jboss.as.server] (ServerService
> Thread Pool -- 42) WFLYSRV0010: Deployed "ejb-security.jar"
> (runtime-name : "ejb-security.jar")
> 2018-04-02 12:15:36,607 INFO [org.jboss.as.controller] (Controller Boot
> Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service
> jboss.naming.context.java.jboss.DefaultJMSConnectionFactory (missing)
> dependents: [service
> jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1555) [GSS](7.1.z) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1555?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev moved JBEAP-14537 to ELY-1555:
--------------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1555 (was: JBEAP-14537)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: Security)
Affects Version/s: 1.1.9.Final
(was: 7.1.1.GA)
Fix Version/s: (was: 7.1.3.GA)
> [GSS](7.1.z) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem
> --------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1555
> URL: https://issues.jboss.org/browse/ELY-1555
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.9.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> After running the enable-elytron.cli and removing the old
> picketbox security subsystem, the deployment fails as
> it cannot find java:jboss/DefaultJMSConnectionFactory.
> java:jboss/DefaultJMSConnectionFactory is defined in the messaging
> subsystem and the ee default-bindings.
> Removing it from the ee default-bindings lets the app deploy, but it looks like there is some
> issue as it should be bound and no errors/warnings being logged.
> {code}
> 2018-04-02 12:15:36,593 ERROR
> [org.jboss.as.controller.management-operation] (Controller Boot Thread)
> WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" =>
> "ejb-security.jar")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" =>
> ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" =>
> ["jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory
> is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"]
> }
> 2018-04-02 12:15:36,603 INFO [org.jboss.as.server] (ServerService
> Thread Pool -- 42) WFLYSRV0010: Deployed "ejb-security.jar"
> (runtime-name : "ejb-security.jar")
> 2018-04-02 12:15:36,607 INFO [org.jboss.as.controller] (Controller Boot
> Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service
> jboss.naming.context.java.jboss.DefaultJMSConnectionFactory (missing)
> dependents: [service
> jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-10067) [Artemis 2.x Upgrade] Failover does not work with HTTP conncetors/acceptors
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10067?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10067:
------------------------------------
[~eduda] I am not sure that the handshake failure are the cause of the issue.
The handshake fails because the server is responding with a "200 OK" (corresponding to the home page) instead of "101 Switching protocols".
This might be normal for example when the live server is booting. However at some point, the server should be ready and returns 101 instead of 200.
I am still processing the logs to understand the issue.
Note that the code related to the HTTP upgrade has not changed in the integration layer for the integration of Artemis 2.x.
If there is a regression, it might be in the Artemis code or in Netty (that has been upgraded from 4.1.9.Final to 4.1.22.Final)
> [Artemis 2.x Upgrade] Failover does not work with HTTP conncetors/acceptors
> ---------------------------------------------------------------------------
>
> Key: WFLY-10067
> URL: https://issues.jboss.org/browse/WFLY-10067
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: clients.log, server1.log, server2.log, test.log
>
>
> Failover does not work with HTTP connectors/acceptors.
> *Scenario:*
> # There are two Wildfly servers configured as Live-Backup pair
> # There is one JMS producer and one JMS receiver which sends/receives messages
> # Live server is several times killed and restarted.
> *Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
> *Reality*: Sometimes happens that clients don't do failover.
> *Users impact:* One of basics feature of HA, failover, does not work properly.
> *Blocker* priority was set because this is regression against previous releases of Wildfly.
> *Detail description of issue*
> In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
> {code:title=Backup log}
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
> 07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
> 07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
> {code}
> {code:title=Clients log}
> 07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
> 07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1554) Upgrade Apache DS in Elytron tests
by Jan Kalina (JIRA)
Jan Kalina created ELY-1554:
-------------------------------
Summary: Upgrade Apache DS in Elytron tests
Key: ELY-1554
URL: https://issues.jboss.org/browse/ELY-1554
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Affects Versions: 1.2.4.Final
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Minor
In WFLY-10163 was Apache Directory upgraded for wildfly to 2.0.0-M24.
To be consistent, DS should be upgraded in elytron too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (SWSQE-110) Update OC on Ansible Image
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-110?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-110.
---------------------------------
Resolution: Done
+ which oc
/usr/bin/oc
+ oc version
oc v3.9.0-alpha.4+aea595c-474
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO
> Update OC on Ansible Image
> --------------------------
>
> Key: SWSQE-110
> URL: https://issues.jboss.org/browse/SWSQE-110
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Guilherme Baufaker Rêgo
> Assignee: Filip Brychta
>
> Started by user Guilherme Baufaker Rêgo
> Running in Durability level: MAX_SURVIVABILITY
> [Pipeline] node
> Still waiting to schedule task
> jenkins-slave-ansible-os-client-tools-kxpss is offline
> Running on jenkins-slave-ansible-os-client-tools-kxpss in /home/jenkins/workspace/Istio+Mesh+Ansible Pipeline
> [Pipeline] {
> [Pipeline] stage
> [Pipeline] { (Clone Istio Repository)
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository https://github.com/gbaufake/istio.git
> > git init /home/jenkins/workspace/Istio+Mesh+Ansible Pipeline/istio # timeout=10
> Fetching upstream changes from https://github.com/gbaufake/istio.git
> > git --version # timeout=10
> > git fetch --tags --progress https://github.com/gbaufake/istio.git +refs/heads/*:refs/remotes/origin/*
> > git config remote.origin.url https://github.com/gbaufake/istio.git # timeout=10
> > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
> > git config remote.origin.url https://github.com/gbaufake/istio.git # timeout=10
> Fetching upstream changes from https://github.com/gbaufake/istio.git
> > git fetch --tags --progress https://github.com/gbaufake/istio.git +refs/heads/*:refs/remotes/origin/*
> > git rev-parse refs/remotes/origin/kiali-addon^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/kiali-addon^{commit} # timeout=10
> Checking out Revision e5be3cd1b2acc60e3ce4ed798f91366947367e17 (refs/remotes/origin/kiali-addon)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f e5be3cd1b2acc60e3ce4ed798f91366947367e17
> Commit message: "Kiali as Istio Addon"
> > git rev-list --no-walk e5be3cd1b2acc60e3ce4ed798f91366947367e17 # timeout=10
> [Pipeline] }
> [Pipeline] // stage
> [Pipeline] stage
> [Pipeline] { (Ansible Playbook)
> [Pipeline] dir
> Running in /home/jenkins/workspace/Istio+Mesh+Ansible Pipeline/istio/install/ansible
> [Pipeline] {
> [Pipeline] sh
> [ansible] Running shell script
> + oc login https://osemaster.os37-gbaufake.osepool.centralci.eng.rdu2.redhat.com:8443 --token=cXd1vapqDSQbW3kWxg7qvuuGgKglMlxvQUaGzH4Mf5s --insecure-skip-tls-verify
> Logged into "https://osemaster.os37-gbaufake.osepool.centralci.eng.rdu2.redhat.com:8443" as "user1" using the token provided.
> You have access to the following projects and can switch between them with 'oc project <projectname>':
> bookinfo
> * default
> istio-system
> kiali-test-box
> kiali-test-breadth-sink
> kiali-test-breath
> kiali-test-circle
> kiali-test-circle-callback
> kiali-test-depth
> kiali-test-depth-sink
> kiali-test-hourglass
> kube-public
> kube-system
> logging
> management-infra
> openshift
> openshift-infra
> openshift-node
> samples
> Using project "default".
> Welcome! See 'oc help' to get started.
> [Pipeline] sh
> [ansible] Running shell script
> + oc version
> oc v1.5.0+031cbe4
> kubernetes v1.5.2+43a9be4
> features: Basic-Auth GSSAPI Kerberos SPNEGO
> [~fbrychta] can you update oc to 3.7?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months