4:15 p.m.
[
https://issues.jboss.org/browse/WFWIP-92?page=com.atlassian.jira.plugin.s...
]
Jan Stourac updated WFWIP-92:
-----------------------------
Steps to Reproduce:
Note: {{application.keystore}} has to be present in standalone/configuration server
directory
{code}
/subsystem=elytron/key-store=ks:add(credential-reference={clear-text=password},type=JKS,relative-to=jboss.server.config.dir,path=application.keystore)
/subsystem=elytron/key-manager=km:add(credential-reference={clear-text=password},key-store=ks)
/subsystem=elytron/server-ssl-context=srvSslCtx:add(key-manager=km)
/subsystem=elytron/server-ssl-sni-context=srvSniSslCtx:add(default-ssl-context=srvSslCtx)
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=srvSniSslCtx)
run-batch
reload
/subsystem=elytron/server-ssl-sni-context=srvSniSslCtx/sni-mapping=server:add(ssl-context=srvSniSslCtx)
reload
{code}
was:
{code}
/subsystem=elytron/key-store=ks:add(credential-reference={clear-text=password},type=JKS,relative-to=jboss.server.config.dir,path=application.keystore)
/subsystem=elytron/key-manager=km:add(credential-reference={clear-text=password},key-store=ks)
/subsystem=elytron/server-ssl-context=srvSslCtx:add(key-manager=km)
/subsystem=elytron/server-ssl-sni-context=srvSniSslCtx:add(default-ssl-context=srvSslCtx)
/subsystem=elytron/server-ssl-sni-context=srvSniSslCtx/sni-mapping=server:add(ssl-context=srvSniSslCtx)
{code}
SNI - circular dependency causes server to crash
------------------------------------------------
Key: WFWIP-92
URL: https://issues.jboss.org/browse/WFWIP-92
Project: WildFly WIP
Issue Type: Bug
Environment: Wildfly build with undertow and wildfly-core modules build from
following sources:
* https://github.com/stuartwdouglas/undertow/tree/sni
* https://github.com/stuartwdouglas/wildfly-core/tree/sni
Reporter: Jan Stourac
Assignee: Stuart Douglas
Labels: SNI
When I try to utilize recently added {{server-ssl-sni-context}} and put its reference
again in the {{sni-mapping}}, after a server reload the server completely crash and one
has to restore configuration manually:
{code:title=command example}
/subsystem=elytron/server-ssl-sni-context=srvSniSslCtx/sni-mapping=server:add(ssl-context=srvSniSslCtx)
{code}
{code:title=server.log output}
22:58:51,998 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread
Pool -- 44) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("server-ssl-sni-context" => "srvSniSslCtx")
]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular
dependency: [service org.wildfly.security.ssl-context.srvSniSslCtx]
at
org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:803)
at
org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:784)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:761)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:260)
at
org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2056)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:260)
at
org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2056)
at
org.jboss.msc.service.ObsoleteServiceBuilderImpl.install(ObsoleteServiceBuilderImpl.java:293)
at
org.jboss.as.controller.OperationContextImpl.installService(OperationContextImpl.java:2034)
at
org.jboss.as.controller.OperationContextImpl.access$600(OperationContextImpl.java:132)
at
org.jboss.as.controller.OperationContextImpl$2$1.installService(OperationContextImpl.java:761)
at
org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2165)
at
org.jboss.msc.service.DelegatingServiceBuilder.install(DelegatingServiceBuilder.java:104)
at
org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:72)
at
org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at
org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at
org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at
org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
at
org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{code}
I understand that such configuration does not make sense, although it would be nice if we
could detect this problem ahead to avoid server crush. Is it possible?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
2899
days inactive
2899
days old
0 comments
1 participants
participants (1)
-
Jan Stourac (JIRA)