[JBoss JIRA] (WFCORE-4950) Regression: Legacy Ldap Realm securing EJB with JDK8 not working
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-4950?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero commented on WFCORE-4950:
-------------------------------------------------
The other option I see is always setting the TCCL in the [LdapConnectionManagerService.java|https://github.com/wildfly/wildfly-core...]. Right now it's only set if a SSLContext is defined.
> Regression: Legacy Ldap Realm securing EJB with JDK8 not working
> ----------------------------------------------------------------
>
> Key: WFCORE-4950
> URL: https://issues.redhat.com/browse/WFCORE-4950
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Critical
>
> WFCORE issue related to JBEAP-19195. The root exception is the following:
> {noformat}
> javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> 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.InitialContext.<init>(InitialContext.java:216)
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:272)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:184)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:180)
> at org.jboss.as.domain.management.security.LdapConnectionHandler.getConnection(LdapConnectionHandler.java:78)
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:232)
> at org.jboss.as.domain.management.security.UserLdapCallbackHandler$SecurityRealmImpl.getRealmIdentity(UserLdapCallbackHandler.java:339)
> at org.jboss.as.domain.management.security.SecurityRealmService$SharedStateSecurityRealm.getRealmIdentity(SecurityRealmService.java:776)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.assignName(ServerAuthenticationContext.java:1197)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$UnassignedState.setPrincipal(ServerAuthenticationContext.java:1726)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationPrincipal(ServerAuthenticationContext.java:410)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:384)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:368)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:912)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:853)
> at org.wildfly.security.auth.callback.SocketAddressQueryCallbackHandler.handle(SocketAddressQueryCallbackHandler.java:57)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:105)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:118)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:110)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> 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:484)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> 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:1348)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
> ... 40 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-313) [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
by Petr Kremensky (Jira)
[ https://issues.redhat.com/browse/WFWIP-313?page=com.atlassian.jira.plugin... ]
Petr Kremensky resolved WFWIP-313.
----------------------------------
Resolution: Done
[~ron_sigal] Thanks a lot for extensive test coverage.
I can verify that issue is fixed in:
{code}
3.12_2406 99fa4d16b [ronsigal/3.12_2406] [RESTEASY-2406] Updated RESTEasy User Guide
{code}
> [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
> ----------------------------------------------------------------------------------------------
>
> Key: WFWIP-313
> URL: https://issues.redhat.com/browse/WFWIP-313
> Project: WildFly WIP
> Issue Type: Quality Risk
> Reporter: Petr Kremensky
> Assignee: Ronald Sigal
> Priority: Major
>
> This one is probably caused by a fact that https://github.com/resteasy/Resteasy/pull/2250 was submitted a long time before the "MicroProfile Config will be available to EAP only when installing the MicroProfile expansion pack" was introduces. I just want to be sure that we're on a same page here and my understanding that this is a valid use case for EAP7-1386 is correct. If so, we might include similar use case into test plan to cover this.
> *Reproduce*
> Update the standalone.xml configuration file inside the WildFly server - remove all microprofile extensions/subsystems from it, and deploy a simple Jax-rs application - e.g. https://github.com/wildfly/quickstart/tree/master/helloworld-rs
> * WildFly 19.0.0.Final with default RESTEasy (3.11.0.Final)
> No issues with deployment.
> * WildFly 19.0.0.Final with RESTEasy 3.10.0-SNAPSHOT from https://github.com/resteasy/Resteasy/pull/2250 (7f10848)
> {noformat}
> 07:55:08,542 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> 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:485)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.loadSpi(ConfigProviderResolver.java:125)
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:110)
> at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:105)
> at org.jboss.resteasy.microprofile.config.ResteasyConfigProvider.getConfig(ResteasyConfigProvider.java:11)
> at org.jboss.resteasy.plugins.server.servlet.ConfigurationBootstrap.getParameter(ConfigurationBootstrap.java:353)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:136)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
> 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 io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> 07:55:08,546 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "helloworld-rs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 07:55:08,547 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "helloworld-rs.war" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> {noformat}
> Please let me know in case that my expectations about this use case are wrong.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5291) Import of empty scesim file leads to Unexpected error
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5291?page=com.atlassian.jira.plug... ]
Anna Dupliak edited comment on DROOLS-5291 at 5/4/20 6:12 AM:
--------------------------------------------------------------
[~yamer]
Indeed the error appears independently on where the file have been created. This seems like a bug in Business central. If you import an empty scesim then it throws unexpected error.
was (Author: adupliak):
[~yamer]
Indeed the error appears independently on where the file have been created. This seems like a bug in Business central. If you import an empty scesim then it will throw unexpected error.
> Import of empty scesim file leads to Unexpected error
> -----------------------------------------------------
>
> Key: DROOLS-5291
> URL: https://issues.redhat.com/browse/DROOLS-5291
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools, kogito-tooling
> Attachments: Traffic.zip, errorlog.txt, image-2020-04-17-16-47-29-261.png, image-2020-04-17-16-47-32-047.png
>
>
> If user generate a scesim file using vs code extention it is not comparable with BC.
> Use Vscode generated files [^Traffic.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5291) Import of empty scesim file leads to Unexpected error
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5291?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-5291:
---------------------------------
Steps to Reproduce:
# Import empty file with scesim extention
# Expected test scenario editor is opened and ready to work
# Actual !image-2020-04-17-16-47-32-047.png|thumbnail!
# See the error [^errorlog.txt]
was:
# Import TraficViolation.dmn from the archive [^Traffic.zip] to BC
# Import TrafficViolationTest.scesim from the archive [^Traffic.zip] to BC
# Expected test scenario editor is opened and ready to work
# Actual !image-2020-04-17-16-47-32-047.png|thumbnail!
# See the error [^errorlog.txt]
> Import of empty scesim file leads to Unexpected error
> -----------------------------------------------------
>
> Key: DROOLS-5291
> URL: https://issues.redhat.com/browse/DROOLS-5291
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools, kogito-tooling
> Attachments: Traffic.zip, errorlog.txt, image-2020-04-17-16-47-29-261.png, image-2020-04-17-16-47-32-047.png
>
>
> If user generate a scesim file using vs code extention it is not comparable with BC.
> Use Vscode generated files [^Traffic.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5291) Import of empty scesim file leads to Unexpected error
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5291?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-5291:
---------------------------------
Summary: Import of empty scesim file leads to Unexpected error (was: Scesim file generated by VS code extention brings Unexpected error when user opens it in Business Central)
> Import of empty scesim file leads to Unexpected error
> -----------------------------------------------------
>
> Key: DROOLS-5291
> URL: https://issues.redhat.com/browse/DROOLS-5291
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools, kogito-tooling
> Attachments: Traffic.zip, errorlog.txt, image-2020-04-17-16-47-29-261.png, image-2020-04-17-16-47-32-047.png
>
>
> If user generate a scesim file using vs code extention it is not comparable with BC.
> Use Vscode generated files [^Traffic.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years