I have deployed my application on JBoss EAP 7 in SSL mode.
My application gets deployed and runs successfully but during start up,
I get following error on console every time when server starts up and WAR is simultaneously deployed, no exception is thrown.
11:28:11,402 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 92) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("https-listener" => "defaultssl")
]) - failure description: "WFLYCTL0216: Management resource '[(\"subsystem\" => \"undertow\")]' not found"
I have been searching Red Hat JBoss Knowledgebase, but have not found any solution to this issue.
This issue is not reproduced, if I deploy my WAR after the application server completely starts up and is initialised.
This issue does not affect my application though.
This issue is not reproduced on JBoss EAP 6.x, JBoss AS 7.1.x and Wildfly.
What can be the reason of such issue?
I observed the behavior of the JBoss EAP 7 application server. The undertow subsystem is not loaded during the server initialization. This issue occurs when application tries to access the details of the undertow subsystem during startup. When the application is deployed after server has started this issue does not occur.
Related
In Wildfly 22.0.0 or later, the following error occurs.
2022-08-24 15:59:43,380 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "shcm")]) - failure description: {
"WFLYCTL0412: Required services that are not installed:" => [
"org.wildfly.clustering.cache.group.web.default-server",
"org.wildfly.clustering.cache.registry.web.default-server"
],
"WFLYCTL0180: Services with missing/unavailable dependencies" =>
["org.wildfly.clustering.web.route-locator.\"shcmupdate.war\" is missing
[org.wildfly.clustering.cache.registry.web.default-server,
org.wildfly.clustering.cache.group.web.default-server]"]
}
I have clustering configuration in web.xml and jboss-web.xml in my application.
if use standalone-ha.xml, it works normally.
but subsystem error occurs when standalone.xml is used from Wildfly 22.0.0 or later.
What changes were made in Wildfly 22?
Seems like it was never supported to be enable for non-standalone.xml builds, so it was likely removed in this PR (distributable-web.xml includes an Infinispan cache that distributable-web-local.xml does not).
The WildFly HA docs should be able to help you migrate to WF 22.
This was really unfortunate decision. It is killing EAP v. 7.4.5 (7.4.6) deployments.
I had replication-config as a part of jboss-web.xml file, that causes this issue. The application runs in ha mode in production, so the configuration is needed, but for the development there is no reason to maintain the whole cluster so I was happy the setting was ignored.
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
version="10.0">
<context-root>my-application</context-root>
<!--
<replication-config>
<replication-granularity>ATTRIBUTE</replication-granularity>
</replication-config> -->
</jboss-web>
Commented out configuration is the part, that was causing the issue.
A colleague of mine wants to automate their JBoss (JBoss EAP v7.4.0) deployments.
So far the process they followed manually was:
Shutdown Jboss entirely
Copy the new .war file under /jboss-eap-7.4.0/standalone/deployments directory
Restart the server by executing standalone.sh
This process, although a bit 'dump', manages to deploy the application with no issues.
I on the other hand, tried to make use of JBoss's auto-redeployment feature, so I simply pasted the new .war file under the /jboss-eap-7.4.0/standalone/deployments directory.
JBoss indeed picks up the new .war and automatically starts the redeployment process.
From the server.log file, it seems at first that the application deploys successfully.
However when I try to access it from my browser, it crashes and gives a code 500 response (See error logs at the end of the post). The expected behavior would be to redeploy me to keycloak in order to login.
The exact same error occurs if I try to manually undeploy and deploy the .war from the jboss.cli.
Any hints on the issue?
I can't figure out if the error is on the server or the application side.
It seems a bit odd that it should require a full JBoss server restart in order for the application to be properly deployed.
Thank you in advance.
Server logs:
2022-06-14 17:22:25,850 WARN [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) The input bytes to the digest operation are null. This may be due to a problem with the Reference URI or its Transforms.
2022-06-14 17:22:25,879 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /myapplication: java.lang.RuntimeException: Could not create authentication request.
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:64)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.ElytronHttpFacade.noAuthenticationInProgress(ElytronHttpFacade.java:123)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.KeycloakHttpServerAuthenticationMechanism.evaluateRequest(KeycloakHttpServerAuthenticationMechanism.java:125)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:119)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SocketAddressCallbackServerMechanismFactory$1.evaluateRequest(SocketAddressCallbackServerMechanismFactory.java:82)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:85)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:326)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$800(HttpAuthenticator.java:301)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:94)
at org.wildfly.security.elytron-web.undertow-server#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl.authenticate(ServletSecurityContextImpl.java:115)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.jboss.xnio#3.8.4.Final-redhat-00001//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.xml.serializer.utils.WrappedRuntimeException: class org.apache.xml.serializer.ToXMLSAXHandler cannot be cast to class org.apache.xml.serializer.SerializationHandler (org.apache.xml.serializer.ToXMLSAXHandler is in unnamed module of loader 'deployment.myapplication.war' #15a25903; org.apache.xml.serializer.SerializationHandler is in unnamed module of loader 'deployment.myapplication.war' #68ae4310)
at deployment.myapplication.war//org.apache.xml.serializer.SerializerFactory.getSerializer(SerializerFactory.java:179)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:261)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:330)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getNodeAsString(DocumentUtil.java:228)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getDocumentAsString(DocumentUtil.java:207)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.getSAMLResponse(BaseSAML2BindingBuilder.java:311)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.buildHtmlPostResponse(BaseSAML2BindingBuilder.java:307)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.getHtmlRequest(BaseSAML2BindingBuilder.java:172)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.SamlUtil.sendSaml(SamlUtil.java:45)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.profile.AbstractSamlAuthenticationHandler$3.sendAuthnRequest(AbstractSamlAuthenticationHandler.java:622)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:61)
I'm running an application on WildFly server version 19.0.0.Final on CentOS 7. This application was working fine, but I run this almost 2 months later, and I'm getting this error where I didn't find any duplicate data sources in standalone.xml
14:21:06,641 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "application.war")]) - failure description: "WFLYCTL0212: Duplicate resource [("deployment" => "application.war")]"
14:21:06,647 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
From the stack trace which you have provided, it seems the issue is related to the deployment and not related to the data source.
if multiple deployment-scanner are defined then make sure that they are pointing to different locations
If Multiple deployment-scanner would be defined pointing to the same path or parent directory's path, which results in multiple deployment attempts of the same war file causing the exception.
I am trying to deploy an ear file in Jboss server configured to eclipse, but when i try to deploy it always ends up in time out exception. I tried to increase my server time out but it doesn't seems to be helping.
But the same ear when I try to deploy in same server outside of eclipse it is deployed successfully unable to find out the root case even after going through several relevant issues over google.
As per my observation the issue doesn't seems to be due to jboss config as the same ear and server seems to be up and running when deployed directly.
Following is the server stack-trace:
2019-05-23 12:08:35,858 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0190: Step handler org.jboss.as.domain.management.security.SecurityRealmAddHandler$ServiceInstallStepHandler#708d860b for operation {"address" => [("core-service" => "management"),("security-realm" => "HTTPSRealm")],"operation" => "add","map-groups-to-roles" => undefined} at address [
("core-service" => "management"),
("security-realm" => "HTTPSRealm")
] failed handling operation rollback -- java.util.concurrent.TimeoutException: java.util.concurrent.TimeoutException
at org.jboss.as.controller.OperationContextImpl.waitForRemovals(OperationContextImpl.java:511)
at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1369)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:644)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1349)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:389)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:351)
at org.jboss.as.server.ServerService.boot(ServerService.java:402)
at org.jboss.as.server.ServerService.boot(ServerService.java:371)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:301)
at java.lang.Thread.run(Thread.java:748)
2019-05-23 12:08:35,859 ERROR [org.jboss.as.controller.client] (Controller Boot Thread) WFLYCTL0190: Step handler org.jboss.as.domain.management.security.SecurityRealmAddHandler$ServiceInstallStepHandler#708d860b for operation {"address" => [("core-service" => "management"),("security-realm" => "HTTPSRealm")],"operation" => "add","map-groups-to-roles" => undefined} at address [
("core-service" => "management"),
("security-realm" => "HTTPSRealm")
] failed handling operation rollback -- java.util.concurrent.TimeoutException
2019-05-23 12:08:39,648 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 70) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'poject-1.ear/poject-2.jar#PlatformModel'
2019-05-23 12:08:39,655 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 70) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'poject-1.ear/poject-2.jar#PlatformModel'
2019-05-23 12:08:40,860 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0190: Step handler org.jboss.as.domain.management.security.SecurityRealmAddHandler$ServiceInstallStepHandler#708d860b for operation {"address" => [("core-service" => "management"),("security-realm" => "ApplicationRealm")],"operation" => "add","map-groups-to-roles" => undefined} at address [
("core-service" => "management"),
("security-realm" => "ApplicationRealm")
] failed handling operation rollback -- java.util.concurrent.TimeoutException: java.util.concurrent.TimeoutException
at org.jboss.as.controller.OperationContextImpl.waitForRemovals(OperationContextImpl.java:511)
at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1369)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:644)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1349)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:389)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:351)
at org.jboss.as.server.ServerService.boot(ServerService.java:402)
at org.jboss.as.server.ServerService.boot(ServerService.java:371)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:301)
at java.lang.Thread.run(Thread.java:748)
Following are few handy details:
Eclipse version : photon
Jboss : 7.0 eap
Jdk : 1.8
Kindly help me out if any additional information is required.
Thanks in advance.
After too many trails I found out the actual reason for the issue the issue is due to memory where in eclipse integrated Jboss server the Vm arguments for launch configuration has xms and xmx as 256 and 512 mb respectively.
After increasing min and max value was successfully able to deploy application even through eclipse
I have a new instance of Wildfly 11, where I am trying to setup Properties File Based Authentication within Elytron. I'm using the Standalone-full.xml and manually deploying the application outside of an IDE.
https://docs.jboss.org/author/display/WFLY/Properties+File+Based+Authentication+Migration
I created the myApp-user and myApp-roles properties files with name valued pairs and included #$REALM_NAME=myAppPropRealm$
I ran the following CLI commands to create the
Create Prop Realm
/subsystem=elytron/properties-realm=myAppPropRealm:add(groups-attribute=groups,groups-properties={path=myApp-roles.properties,relative-to=jboss.server.config.dir},users-properties={path=myApp-users.properties,relative-to=jboss.server.config.dir,plain-text=true})
Configure Security-Domain
/subsystem=elytron/security-domain=myAppSecurityDomain:add(realms=[{realm=myAppPropRealm,role-decoder=groups-to-roles}],default-realm=myAppPropRealm,permission-mapper=default-permission-mapper)
Configure http-authentication-factory
/subsystem=elytron/http-authentication-factory=myApp-http-auth:add(http-server-mechanism-factory=global,security-domain=myAppSecurityDomain,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=myApp_ApplicationDomain}]}])
Configure application-security-domain in Undertow
/subsystem=undertow/application-security-domain=myApp_ApplicationDomain:add(http-authentication-factory=myApp-http-auth)
JBoss-web.xml
</jboss-web>
<security-domain>myApp_ApplicationDomain</security-domain>
</jboss-web>
I get the following error when my app tries to deploy
2018-11-29 09:06:55,695 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "MyApplication-ws.war")]) - failure description: {
"WFLYCTL0412: Required services that are not installed:" => ["jboss.security.security-domain.myApp_ApplicationDomain"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => [
I suspect it is because I have not defined 'myApp_ApplicationDomain' but this is where I'm stuck. What commands do I run to add/reference
the myApp_ApplicationDomain?
Wildfly is looging for legacy security domain jboss.security.security-domain.myApp_ApplicationDomain for some reason. But seems you have correctly declared myApp_ApplicationDomain in undertow. Most probably you are using myApp_ApplicationDomain somewhere outside of undertow subsystem.