从NetBeans

时间：2016-12-08 07:04:28

标签： netbeans port wildfly offset

我面对来自WildFly服务器的一些非常奇怪的行为，在检查了所有内容之后我不确定是否我做错了什么或者这是Wildfly或NetBeans中的错误。

我正在开发一个应用程序，它使用两个WildFly服务器来完成不同的任务，因为我在我的开发计算机上运行，​​它们必须在不同的端口上运行。到目前为止，系统已在JBoss 7，Java 1.7和NetBeans 8.0.2上正常运行。 现在我们决定切换到WildFly 10，Java 1.8和NetBeans 8.2。

以前的端口配置如下：

服务器1：
-In Netbeans：HTTP端口：8080，JMX端口：9999
- 在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"/>

服务器2：
-In Netbeans：HTTP端口：8580，JMX端口：10499
- 在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"/>

正如您所料，这导致服务器1在端口8080上运行应用程序，端口9990上的管理控制台和端口8580上的管理控制台运行，管理控制台在端口10490上运行。

现在为新系统。我让应用程序1在默认端口上正常运行没有太多麻烦，但我遇到了应用程序2的问题。

我的第一直觉当然是以与旧服务器类似的方式配置它，因此在NetBeans中我设置了端口8580和管理10490，在standalone.xml中我设置了500的偏移量。

令我惊讶的是，这导致应用程序在端口9080上运行，管理控制台在10990上运行。 我猜这是因为NetBeans 8.2将这些启动参数提供给WildFly服务器：

-Djboss.management.http.port=10490 -Djboss.http.port=8580

然后，尽管在standalone.xml中写了什么，运行应用程序的端口是8580 + 500 = 9080，而不是旧服务器上的8080 + 500。

所以我的第一个问题是如何阻止NetBeans将这些参数发送到WildFly？我想要使​​用standalone.xml中的任何内容。

所以接下来尝试的是从standalone.xml中删除端口偏移量，而不是设置

<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:10490}"/>
<socket-binding name="http" port="${jboss.http.port:8580}"/>

当我启动服务器时，管理控制台正确地在端口10490上，当我检查部署时，我看到我的web服务已部署并在端口8580上运行。但是当我点击链接到WSDL时，我得到了这个日志中的错误：

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)

是否有人解释为什么会出现此错误？你能建议一些解决方法吗？

除了上述内容之外，我还尝试了其他一些配置，其中没有一个配置导致在端口8580上运行有效的Web服务：

配置：Netbeans端口8580/10490，独立：偏移0，端口8580/10490
结果：管理控制台在10490上运行，Web服务部署到8580，但出现错误JBWS024029

配置：NB端口8580/10490，独立：偏移500，端口8080/9990
结果：控制台在10990上，WS在9080上并且正常工作

配置：NB端口8080/9990，独立：偏移0，端口8080/9990
结果：控制台在9990，WS在8080上并且正常工作（但这不是解决方案，因为那时我无法运行两台服务器）

配置：NB端口8580/10490，独立：偏移0，端口8080/9990
结果：控制台在10490，WS在8580，但给出错误JBWS024029

我的想法是，我可以将Netbeans端口设置为8330，并将独立的偏移设置为250，这应该会导致正常工作的应用程序在端口8580上运行。但对我而言，这感觉就像某种黑客攻击试图重新使用我的配置的同事会非常困惑。所以我只会用它作为最后的手段。我还认为在开始生产之前我需要找出JBWS024029的错误。

哦，我只想起别的东西。如果我只是使用端口8580/10490启动服务器，然后从管理控制台部署应用程序，一切正常。如果我通过单击NetBeans中的war项目上的“运行”来部署应用程序，那么我只获得JBWS024029。但在开发环境中，这是我99％的时间都在做的事情。

请忽略上述文本的最后一部分，经过一些进一步的实验后，我发现JBWS024029错误完全随机出现，无论设置如何，都可以通过反复杀死并重新启动服务器来解决，直到最终决定工作。 / p>

1 个答案:

答案 0 :(得分：1)

如果从NetBeans启动WildFly服务器，NetBeans将仅使用这些参数。手动启动它，然后NetBeans将使用配置的端口连接到它。

另一个解决方案是从standalone.xml中删除表达式，这样就不会从参数计算端口，如下所示：

<socket-binding name="http" port="8580"/>
相关问题
最新问题