Changing Wildfly 10 ports when starting from NetBeans - netbeans

Question

I am facing some very strange behaviour from my WildFly server and after checking everything i'm not sure anymore if i did something wrong or if this is a bug in Wildfly or NetBeans.
I am developing an application which uses two WildFly servers for different tasks, and because i am running both on my development computer, they have to be running on different ports. Until now the system has been running properly on JBoss 7, Java 1.7 and NetBeans 8.0.2.
Now we have decided to switch to WildFly 10, Java 1.8 and NetBeans 8.2.
The previous port configuration was as follows:
Server 1:
-In Netbeans: HTTP Port: 8080, JMX port: 9999
-In standalone.xml:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="http" port="8080"/>
Server 2:
-In Netbeans: HTTP Port: 8580, JMX port: 10499
-In standalone.xml:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:500}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="http" port="8080"/>
As you can expect this resulted in Server 1 running with the application on port 8080 and with the management console on port 9990 and Server 2 running on port 8580 with the management console on port 10490.
Now for the new system. I got Application 1 to run properly on the default ports without much trouble, but i am having problems with application 2.
My first instinct was of course to configure it in a similar way to the old server, so in NetBeans i set Port 8580 and Management 10490, and in standalone.xml i set an offset of 500.
To my surprise this resulted in the application running on port 9080 and the management console running on 10990.
I am guessing that the reason for this is that NetBeans 8.2 supplies these startup parameters to the WildFly server:
-Djboss.management.http.port=10490 -Djboss.http.port=8580
Then despite what is written in standalone.xml the port where the application runs is 8580+500=9080, and not 8080+500 like it was on the old server.
So my first question is how can i stop NetBeans from sending these parameters to WildFly? I want whatever is written in standalone.xml to be used.
So what i tried next was to remove the port offset from standalone.xml and instead to set
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:10490}"/>
<socket-binding name="http" port="${jboss.http.port:8580}"/>
When i started the server the management console was correctly on port 10490, and when i checked the deployments, i saw that my webservice was deployed and running on port 8580. But when i clicked the link to the WSDL, i got this error in the log:
07:19:07,907 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /mferac/IxDokService: javax.servlet.ServletException: JBWS024029: Cannot obtain destination for /xyz/XyzService
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.findDestination(RequestHandlerImpl.java:173)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
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.jrHandle(ServletInitialHandler.java)
at org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:98)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Does anybody have an explanation for why this error should occur? Could you suggest some steps to resolve it?
In addition to the above, i also tried some other configurations, none of which resulted in a working webservice running on port 8580:
Config: Netbeans ports 8580/10490, standalone: offset 0, ports 8580/10490
Result: Management console running on 10490, webservice deployed to 8580, but giving error JBWS024029
Config: NB ports 8580/10490, standalone: offset 500, ports 8080/9990
Result: console on 10990, WS on 9080 and works properly
Config: NB ports 8080/9990, standalone: offset 0, ports 8080/9990
Result: Console on 9990, WS on 8080 and works properly (However this is not a solution because then i can't be running two servers)
Config: NB ports 8580/10490, standalone: offset 0, ports 8080/9990
Result: console on 10490, WS on 8580, but giving error JBWS024029
An idea that i have is that i could set the Netbeans port to 8330 and the offset in standalone to 250, which should cause a working application to be running on port 8580. But to me this feels like some kind of hack and will be very confusing for coworkers trying to re-use my configuration. So i will only use this as a last resort. I also think that i need to find out what error JBWS024029 means before we go into production.
Oh and i just remembered something else. If i just start the server with ports 8580/10490 and then deploy the application from the management console everything works correctly. I only get JBWS024029 if i deploy the application by clicking "Run" on the war project in NetBeans. But in a development environment this is what i will be doing 99% of the time.
Please ignore the last part of the above text, after some further experiments i found out that the JBWS024029 error appears completely randomly regardless of the settings and can be resolved by repeatedly killing and restarting the server until it eventually decides to work.

Answer 1

NetBeans will only use those paramters if your WildFly server is started from NetBeans. Start it manually and then NetBeans will connect to it using the configured port.
Another solution is to remove the expression from the standalone.xml, this way the ports won't be computed from parameters, like this:
<socket-binding name="http" port="8580"/>