[jboss-jira] [JBoss JIRA] (WFLY-4245) https socket-binding still a dependency of http

[Giuseppe Mazzotta (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Giuseppe Mazzotta updated WFLY-4245:
------------------------------------
    Description: 
Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:

{noformat}
--- standalone.xml.orig	2015-01-13 11:33:57.956000250 +0100
+++ standalone.xml	2015-01-13 11:34:04.456000250 +0100
@@ -375,11 +375,10 @@
         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
         <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
         <socket-binding name="http" port="${jboss.http.port:8080}"/>
-        <socket-binding name="https" port="${jboss.https.port:8443}"/>
         <socket-binding name="txn-recovery-environment" port="4712"/>
         <socket-binding name="txn-status-manager" port="4713"/>
         <outbound-socket-binding name="mail-smtp">
             <remote-destination host="localhost" port="25"/>
         </outbound-socket-binding>
     </socket-binding-group>
-</server>
\ No newline at end of file
+</server>
{noformat}

Failure I receive is:
{noformat}

{noformat}

Is this expected behavior?

  was:
Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:

{noformat}
--- standalone.xml.orig	2015-01-13 11:33:57.956000250 +0100
+++ standalone.xml	2015-01-13 11:34:04.456000250 +0100
@@ -375,11 +375,10 @@
         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
         <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
         <socket-binding name="http" port="${jboss.http.port:8080}"/>
-        <socket-binding name="https" port="${jboss.https.port:8443}"/>
         <socket-binding name="txn-recovery-environment" port="4712"/>
         <socket-binding name="txn-status-manager" port="4713"/>
         <outbound-socket-binding name="mail-smtp">
             <remote-destination host="localhost" port="25"/>
         </outbound-socket-binding>
     </socket-binding-group>
-</server>
\ No newline at end of file
+</server>
{noformat}

Is this expected behavior?



> https socket-binding still a dependency of http
> -----------------------------------------------
>
>                 Key: WFLY-4245
>                 URL: https://issues.jboss.org/browse/WFLY-4245
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>         Environment: Linux 64bit
>            Reporter: Giuseppe Mazzotta
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:
> {noformat}
> --- standalone.xml.orig	2015-01-13 11:33:57.956000250 +0100
> +++ standalone.xml	2015-01-13 11:34:04.456000250 +0100
> @@ -375,11 +375,10 @@
>          <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>          <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
>          <socket-binding name="http" port="${jboss.http.port:8080}"/>
> -        <socket-binding name="https" port="${jboss.https.port:8443}"/>
>          <socket-binding name="txn-recovery-environment" port="4712"/>
>          <socket-binding name="txn-status-manager" port="4713"/>
>          <outbound-socket-binding name="mail-smtp">
>              <remote-destination host="localhost" port="25"/>
>          </outbound-socket-binding>
>      </socket-binding-group>
> -</server>
> \ No newline at end of file
> +</server>
> {noformat}
> Failure I receive is:
> {noformat}
> {noformat}
> Is this expected behavior?



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)