[JBoss JIRA] (WFLY-13802) The undertow layer can not deploy deployments without the ee layer
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13802?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13802:
-----------------------------------------
I mentioned it in chat but I think we should really look into the concept of abstract layers, we have a few cases now where a layer may exist so it can be depended on by another layer but not used directly. Other than that layers like this likely should not be listed in any documentation / output that shows available layers.
> The undertow layer can not deploy deployments without the ee layer
> ------------------------------------------------------------------
>
> Key: WFLY-13802
> URL: https://issues.redhat.com/browse/WFLY-13802
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> {code:java}
> 16:35:06,234 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
> at org.jboss.as.ee.component.ComponentRegistry.createInstanceFactory(ComponentRegistry.java:76)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:709)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:276)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13802) The undertow layer can not deploy deployments without the ee layer
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13802?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana commented on WFLY-13802:
---------------------------------------------
Currently, web-server is the required Galleon layer for EE deployments
> The undertow layer can not deploy deployments without the ee layer
> ------------------------------------------------------------------
>
> Key: WFLY-13802
> URL: https://issues.redhat.com/browse/WFLY-13802
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> {code:java}
> 16:35:06,234 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
> at org.jboss.as.ee.component.ComponentRegistry.createInstanceFactory(ComponentRegistry.java:76)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:709)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:276)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13792) JSF deployment failure due to UnsupportedOperationException when javax.faces.FACELETS_VIEW_MAPPINGS is defined
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-13792?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty edited comment on WFLY-13792 at 9/11/20 10:38 AM:
----------------------------------------------------------------------
Upstream Issue created [https://github.com/eclipse-ee4j/mojarra/issues/4735]
and the related PR [https://github.com/eclipse-ee4j/mojarra/pull/4736]
was (Author: rchakrab):
Upstream Issue created [https://github.com/eclipse-ee4j/mojarra/issues/4735]
> JSF deployment failure due to UnsupportedOperationException when javax.faces.FACELETS_VIEW_MAPPINGS is defined
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13792
> URL: https://issues.redhat.com/browse/WFLY-13792
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 20.0.1.Final
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> When the following setting is defined in web.xml for JSF application:
> {code:java}
> <context-param>
> <param-name>javax.faces.FACELETS_VIEW_MAPPINGS</param-name>
> <param-value>*.jsp</param-value>
> </context-param>
> {code}
> JSF deployment fails with "UnsupportedOperationException: UT010042: This method cannot be called from a servlet context listener that has been added programmatically"
> {code:java}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 84) Critical error during deployment: : java.lang.UnsupportedOperationException: UT010042: This method cannot be called from a servlet context listener that has been added programatically
> at io.undertow.servlet.spec.ServletContextImpl.ensureNotProgramaticListener(ServletContextImpl.java:976)
> at io.undertow.servlet.spec.ServletContextImpl.getServletRegistrations(ServletContextImpl.java:584)
> at com.sun.faces.util.Util.getExistingFacesServletRegistration(Util.java:160)
> at com.sun.faces.util.Util.getFacesServletMappings(Util.java:150)
> at com.sun.faces.util.Util.isResourceExactMappedToFacesServlet(Util.java:1158)
> at com.sun.faces.util.Util.isViewIdExactMappedToFacesServlet(Util.java:1139)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.handlesViewId(FaceletViewHandlingStrategy.java:946)
> at com.sun.faces.application.view.ViewHandlingStrategyManager.getStrategy(ViewHandlingStrategyManager.java:76)
> at com.sun.faces.application.view.ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(ViewDeclarationLanguageFactoryImpl.java:47)
> at com.sun.faces.application.view.MultiViewHandler.getViewDeclarationLanguage(MultiViewHandler.java:446)
> at javax.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:346)
> at javax.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:346)
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:324)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:123)
> at com.sun.faces.application.applicationimpl.Events.processListeners(Events.java:253)
> at com.sun.faces.application.applicationimpl.Events.invokeListenersFor(Events.java:231)
> at com.sun.faces.application.applicationimpl.Events.publishEvent(Events.java:112)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:127)
> at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:788)
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:553)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:264)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:217)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:491)
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.deployment.unit."tasks-jsf.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."tasks-jsf.war".undertow-deployment: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.UnsupportedOperationException: UT010042: This method cannot be called from a servlet context listener that has been added programatically
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:491)
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.UnsupportedOperationException: UT010042: This method cannot be called from a servlet context listener that has been added programatically
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.UnsupportedOperationException: UT010042: This method cannot be called from a servlet context listener that has been added programatically
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:283)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:217)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> ... 10 more
> Caused by: java.lang.UnsupportedOperationException: UT010042: This method cannot be called from a servlet context listener that has been added programatically
> at io.undertow.servlet.spec.ServletContextImpl.ensureNotProgramaticListener(ServletContextImpl.java:976)
> at io.undertow.servlet.spec.ServletContextImpl.getServletRegistrations(ServletContextImpl.java:584)
> at com.sun.faces.util.Util.getExistingFacesServletRegistration(Util.java:160)
> at com.sun.faces.util.Util.getFacesServletMappings(Util.java:150)
> at com.sun.faces.util.Util.isResourceExactMappedToFacesServlet(Util.java:1158)
> at com.sun.faces.util.Util.isViewIdExactMappedToFacesServlet(Util.java:1139)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.handlesViewId(FaceletViewHandlingStrategy.java:946)
> at com.sun.faces.application.view.ViewHandlingStrategyManager.getStrategy(ViewHandlingStrategyManager.java:76)
> at com.sun.faces.application.view.ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(ViewDeclarationLanguageFactoryImpl.java:47)
> at com.sun.faces.application.view.MultiViewHandler.getViewDeclarationLanguage(MultiViewHandler.java:446)
> at javax.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:346)
> at javax.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:346)
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:324)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:123)
> at com.sun.faces.application.applicationimpl.Events.processListeners(Events.java:253)
> at com.sun.faces.application.applicationimpl.Events.invokeListenersFor(Events.java:231)
> at com.sun.faces.application.applicationimpl.Events.publishEvent(Events.java:112)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:127)
> at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:788)
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:553)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:264)
> ... 22 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ELY-1700) Intermittently failing AttributeMappingSuiteChild
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1700?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1700:
----------------------------
Fix Version/s: 1.14.0.CR1
(was: 1.13.0.Final)
> Intermittently failing AttributeMappingSuiteChild
> -------------------------------------------------
>
> Key: ELY-1700
> URL: https://issues.redhat.com/browse/ELY-1700
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.7.0.CR2
> Reporter: Martin Choma
> Priority: Minor
> Fix For: 1.14.0.CR1
>
>
> With ration 1:1000 we see ELY01125: Ldap-backed realm failed to obtain context.
> {noformat}
> org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:215)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77)
> at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms.
> at com.sun.jndi.ldap.Connection.readReply(Connection.java:507)
> at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365)
> at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791)
> 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 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:436)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355)
> at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203)
> ... 7 more
> {noformat}
> {noformat}
> 00:29:39,451 TRACE (main) [org.wildfly.security] <SecurityDomain.java:1036> Building security domain with defaultRealmName default.
> 00:29:39,452 TRACE (main) [org.wildfly.security] <SecurityDomain.java:708> Role mapping: principal [anonymous] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
> 00:29:39,452 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1163> Principal assigning: [userWithAttributes], pre-realm rewritten: [userWithAttributes], realm name: [default], post-realm rewritten: [userWithAttributes], realm rewritten: [userWithAttributes]
> 00:29:39,453 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [userWithAttributes]...
> 00:29:39,454 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [userWithAttributes].
> 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment:
> 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******]
> 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory]
> 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org]
> 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore]
> 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
> 00:29:44,528 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:438> Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms.
> at com.sun.jndi.ldap.Connection.readReply(Connection.java:507)
> at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365)
> at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791)
> 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 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:436)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355)
> at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77)
> at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33)
> 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:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> 00:29:44,529 INFO (pool-3-thread-2) [org.apache.directory.server.ldap.handlers.LdapRequestHandler] <LdapRequestHandler.java:131> ignoring the message Abandon Request :
> Message Id : 1org.apache.directory.api.ldap.model.message.AbandonRequestImpl@8444b052 received from null session
> {noformat}
> Maybe just to try prolong SimpleDirContextFactoryBuilder#DEFAULT_CONNECT_TIMEOUT [1]
> This issue occurs also with ELY-1699. It is very probable machine was slow. But it would be fine if testsuite could cope with this situation as well.
>
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/38e1e01972414ad7...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1440:
----------------------------
Fix Version/s: 1.14.0.CR1
(was: 1.13.0.Final)
> FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
> ----------------------------------------------------------------------------------------------
>
> Key: ELY-1440
> URL: https://issues.redhat.com/browse/ELY-1440
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
> Priority: Major
> Fix For: 1.14.0.CR1
>
>
> This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event.
> Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance.
> At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1682:
----------------------------
Fix Version/s: 1.14.0.CR1
(was: 1.13.0.Final)
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.redhat.com/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.14.0.CR1
>
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months