[JBoss JIRA] (WFLY-1049) Add equivalent @WebContext for JAX-RS?
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-1049?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-1049.
-----------------------------
Resolution: Rejected
> Add equivalent @WebContext for JAX-RS?
> --------------------------------------
>
> Key: WFLY-1049
> URL: https://issues.jboss.org/browse/WFLY-1049
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Fernando Rubbo
> Priority: Major
> Labels: BASIC_AUTH, FORM_AUTH, JAX-RS,
>
> Currently, in our application we use @WebContext to set a different contextRoot for JAX-WS. For example:
>
> {code:java}
> @Stateless
> @SecurityDomain("test2")
> @WebService(name = "HelloSoap", portName = "HelloSoapPort", serviceName = "HelloSoap", targetNamespace = "http://com.test")
> @WebContext(contextRoot = "/ws", urlPattern = "/HelloSoap", secureWSDLAccess = false, authMethod = "BASIC", transportGuarantee = "NONE")
> public class HelloSoap { ... }
> {code}
> We would like to have an equivalent annotation for JAX-RS? It is required whenever a web app uses FORM_AUTH and there exists web services (JAX-WS and JAX-RS), inside of the same package, using as BASIC_AUTH.
>
> Thankyou in advance,
> Fernando Rubbo
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-1049) Add equivalent @WebContext for JAX-RS?
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-1049?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-1049:
---------------------------------
[~mkopecky], there doesn't seem to be much interest, does there?
[~fernando.rubbo], I'm going to close this issue. If there is still some interest, you (or anyone) can re-open it.
-Ron
> Add equivalent @WebContext for JAX-RS?
> --------------------------------------
>
> Key: WFLY-1049
> URL: https://issues.jboss.org/browse/WFLY-1049
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Fernando Rubbo
> Priority: Major
> Labels: BASIC_AUTH, FORM_AUTH, JAX-RS,
>
> Currently, in our application we use @WebContext to set a different contextRoot for JAX-WS. For example:
>
> {code:java}
> @Stateless
> @SecurityDomain("test2")
> @WebService(name = "HelloSoap", portName = "HelloSoapPort", serviceName = "HelloSoap", targetNamespace = "http://com.test")
> @WebContext(contextRoot = "/ws", urlPattern = "/HelloSoap", secureWSDLAccess = false, authMethod = "BASIC", transportGuarantee = "NONE")
> public class HelloSoap { ... }
> {code}
> We would like to have an equivalent annotation for JAX-RS? It is required whenever a web app uses FORM_AUTH and there exists web services (JAX-WS and JAX-RS), inside of the same package, using as BASIC_AUTH.
>
> Thankyou in advance,
> Fernando Rubbo
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-11259.
-------------------------------
Resolution: Done
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11259:
--------------------------------
Fix Version/s: 17.0.0.Beta1
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-11259:
-------------------------------------
[~abialas] I think the jboss-deployment-structure is a good workaround. I think it is similar to the recent Hibernate [https://github.com/hibernate/hibernate-orm/commit/4580039fe226722e6ee1410...] change for Hibernate 5.3.9, in the sense that both changes ensure that the application packaged dom4j classes are ignored.
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (DROOLS-3674) UX proposal for error reporting after test run
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3674?page=com.atlassian.jira.plugi... ]
Klara Kufova resolved DROOLS-3674.
----------------------------------
Resolution: Done
> UX proposal for error reporting after test run
> ----------------------------------------------
>
> Key: DROOLS-3674
> URL: https://issues.jboss.org/browse/DROOLS-3674
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: tao zhu
> Priority: Major
> Labels: ScenarioSimulation, UXTeam
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-11603) Intermittent NPE from MP config SubsystemDeploymentProcessor
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-11603?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-11603:
------------------------------------
Just for the reference - there is a followup issue WFCORE-4375 that should solve necessity to use deprecated API.
> Intermittent NPE from MP config SubsystemDeploymentProcessor
> ------------------------------------------------------------
>
> Key: WFLY-11603
> URL: https://issues.jboss.org/browse/WFLY-11603
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 15.0.1.Final
> Environment: Windows
> JDK-11
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 16.0.0.Beta1, 16.0.0.Final
>
>
> In our automation tests, we can see intermittent NPE with following stack trace:
> {code}
> 20:01:38,985 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@54fd99c3 unexpectedly threw an exception during undeploy phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war": java.lang.NullPointerException
> at org.wildfly.extension.microprofile.config-smallrye@7.2.0.GA-redhat-00004//org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:149)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 20:01:38,986 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war"
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.api@1.3.0.redhat-00001//org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:122)
> at org.wildfly.extension.microprofile.config-smallrye@7.2.0.GA-redhat-00004//org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.deploy(SubsystemDeploymentProcessor.java:67)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> ... 8 more
> {code}
> further on, there is also following error in the server.log (it has been dealt in WFWIP-64, although in different circumstances, I guess):
> {code}
> 20:01:39,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"org.jboss.qa.management.ws.WebservicesWsdlHostIT.war\".POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"org.jboss.qa.management.ws.WebservicesWsdlHostIT.war\"
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 20:01:39,169 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war" (runtime-name : "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war")
> 20:01:39,171 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war"
> {code}
> The NPE itself goes from the 'undeploy' method in SubsystemDeploymentProcessor. Although, according to the surrounding log messages (longer test log is attached [^NPE-server.log]), the server is still in the boot process by that time.
> This NPE happens quite rarely so it looks like some kind of a race-condition is in place. So far we have seen this only on Windows with JDK-11 combination but cannot say it does not affect other platforms for sure.
> Also, we have not seen it with latest WildFly nightly builds too (WildFly revision 353b95ef201c18dbd465087f520392c8525a2213) (yet?).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-11781) Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-11781?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFLY-11781:
---------------------------------------
Assignee: (was: Darran Lofthouse)
> Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11781
> URL: https://issues.jboss.org/browse/WFLY-11781
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 15.0.1.Final
> Reporter: indrajit ingawale
> Priority: Major
>
> It is requirement to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm .
> --------------------------------------
> <security-domain name="TestDomain" default-realm="TestAggRealm" permission-mapper="default-permission-mapper" pre-realm-principal-transformer="test-transformer" security-event-listener="local-audit">
> <realm name="TestAggRealm" role-decoder="from-roles-attribute"/>
> </security-domain>
> .
> .
> <aggregate-realm name="TestAggRealm" authentication-realm="TestLdapRealm" authorization-realm="Test_Auth_LdapRealm"/>
> --------------------------------------
> I think to achieve this there need to be something like "mid-realm-principal-transformer" in <aggregate-realm> only .
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (WFLY-6371) LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-6371?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-6371:
--------------------------------------
Assignee: (was: Darran Lofthouse)
> LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-6371
> URL: https://issues.jboss.org/browse/WFLY-6371
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Bartosz Baranowski
> Priority: Major
>
> In case when LdapExtLoginModule is correctly configured for authentication, but its attributes rolesCtxDN and roleFilter are not set, then authentication with correct username and password leads to FailedLoginException.
> Expected behavior is that user should be authenticated but no roles should be assigned to them.
> Possible EAP configuration:
> <security-domain name="ldap">
> <authentication>
> <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
> <module-option name="baseFilter" value="(uid=
> {0})"/>
> <module-option name="bindDN" value="uid=admin,ou=system"/>
> <module-option name="baseCtxDN" value="ou=People,o=MyOrg,o=primary,dc=jboss,dc=org"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
> <module-option name="bindCredential" value="secret"/>
> </login-module>
> </authentication>
> </security-domain>
> In case when these attributes are added
> <module-option name="rolesCtxDN" value="ou=Roles,o=MyOrg,o=primary,dc=jboss,dc=org"/>
> <module-option name="roleFilter" value="(member={0}
> )"/>
> then user is correctly authenticated (even in case when no role is assigned to them).
> It is caused by internal NPE thrown from method rolesSearch in LdapExtLoginModule class on line:
> results = ldapCtx.search(rolesCtxDN, roleFilter, filterArgs, constraints);
> DEBUG [org.jboss.security] (default task-2) PBOX000206: Login failure: javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:350)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:338)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:148)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:82)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106)
> 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:51)
> 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:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months