Hello,

I'm having an issue when configuring a HTTPS listener for Undertow via the JBOSS standalone.xml method.

(Wildfly 8.0.0.CR1).

I get the following ecception on startup:
2014-01-16 16:00:34,521 ERROR [org.jboss.msc.service.fail](MSC service thread 1-9) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
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:724)
Caused by: java.lang.ClassCastException: Not a sequence
at org.xnio.SequenceOption.cast(SequenceOption.java:57)
at org.xnio.SequenceOption.cast(SequenceOption.java:31)
at org.xnio.OptionMap.get(OptionMap.java:64)
at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)
at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)
at org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)
at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more

My JBOSS Undertow configuration looks like this:
<subsystem xmlns="urn:jboss:domain:undertow:1.0">
        <!-- SAA: for reference, there is not currently a default web xml in which we can globally disable unwanted HTTP methods.
We have to expect the reverse proxy web server to restrict them.
Nevertheless, Any Web Application can specifically disable them until JBoss start to provide a mechanism in here
-->        
            <buffer-caches>
                <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
            </buffer-caches>
            <server name="default-server">
            <!-- SAA: for reference, in ajp the Servlet/JSP Request URL is formed from the host and port of the client; browser or proxy.
Web applications trying to use these values expecting them to be the local server and port would then be mistaken.
As a workaround, we expect the reverse proxy web server to modify the Host Request Header to be equal to ths server's fully qualified host name and respective port, this will then mimmick the 
incoming requests to the http and https connectors.
One example where this is crucial is REIMS Central Authentication Server as these details must match up against the domain advertised cas server url with highest priority 
-->
                <ajp-listener name="ajp" socket-binding="ajp"/>
                <http-listener name="http" socket-binding="http"/>
                <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV" />
                <host name="default-host" alias="localhost">
                    <location name="/" handler="welcome-content"/>
                    <access-log directory="${jboss.server.base.dir}/log" prefix="localhost_access_log."/>
                </host>
            </server>
            <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
                <jsp-config x-powered-by="false"/>
                <persistent-sessions/>
            </servlet-container>
            <handlers>
                <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
            </handlers>
        </subsystem>

By process of elimination, I've found that removing the "enabled-cipher-suites" attribute makes the problem go away, so obviously this is the culprit.

The value I'm using for this attribute has simply been copied from our jboss-web configuration, previously "cipher-suite".

Am I using the attribute wrong, or is this a bug?

Any help greatly appreciated.

Cheers, Andy.