WildFly 10中JNDI查找报java.net.ConnectException连接拒绝错误及配置咨询

Let me break down additional checks and configurations you should verify to resolve this connection refused error when doing JNDI lookups with WildFly 10:

1. Confirm WildFly's Remoting Port Configuration #

First, double-check that WildFly is actually listening on the port you're targeting (4447):

• Open your WildFly's standalone.xml or domain.xml and navigate to the remoting subsystem section:

  <subsystem xmlns="urn:jboss:domain:remoting:3.0">
      <endpoint worker="default"/>
      <connector name="remoting-connector" socket-binding="remoting"/>
  </subsystem>
  

• Find the corresponding socket binding for remoting:

  <socket-binding name="remoting" port="${jboss.remoting.port:4447}"/>
  

• Verify the port isn't modified from the default. You can also check if the port is in listening state using:
  • Linux: netstat -an | grep 4447 or ss -tulpn | grep 4447
  • Windows: netstat -ano | findstr :4447

2. Ensure Correct EJB Client Dependencies #

Missing or mismatched dependencies are a common culprit here:

• If using Maven, include the WildFly EJB client BOM to pull in all required jars:

  <dependency>
      <groupId>org.wildfly</groupId>
      <artifactId>wildfly-ejb-client-bom</artifactId>
      <version>10.1.0.Final</version>
      <type>pom</type>
      <scope>runtime</scope>
  </dependency>
  

• For manual jar management, make sure you have these core jars (matching WildFly 10 versions):
  • wildfly-ejb-client.jar
  • jboss-remote-naming.jar
  • xnio-api.jar
  • xnio-nio.jar
  • jboss-logging.jar

3. Validate Server-Side Security Settings #

Even though you've disabled SASL_POLICY_NOANONYMOUS, confirm these points:

• The username/password you're using exists in WildFly's user store. Use the add-user.sh/add-user.bat script to create or verify the user, and ensure they're assigned to a role that has access to your EJB (like the ejb role, unless you've configured custom security roles).
• If your EJB uses @SecurityDomain or other security annotations, make sure the server's security domain is properly configured to authenticate your user.

4. Check Firewall and Network Restrictions #

• Local connections: Temporarily disable your OS firewall (Windows Firewall, Linux iptables) to rule out port blocking. If that fixes the issue, add an inbound rule for port 4447.
• Remote connections: Ensure the server's network firewall allows incoming traffic on 4447, and that there's no network routing issue preventing your client from reaching the server.

5. Verify JNDI Lookup Name Format #

With jboss.naming.client.ejb.context=true enabled, your JNDI lookup name needs to follow the correct format:

• For stateless EJBs: ejb:/<deployment-name>/<bean-class-name>!<fully-qualified-interface-name>
• Example:

  MyEjbRemote ejb = (MyEjbRemote) context.lookup("ejb:/my-ejb-app/MyEjbBean!com.example.MyEjbRemote");
  

• Note: <deployment-name> is the name of your deployed WAR/EAR (without the file extension, unless you specified a custom name in jboss-web.xml or jboss-app.xml).

6. Inspect WildFly Server Logs #

Check standalone/log/server.log for clues:

• Look for logs confirming your EJB was bound successfully, like:

  JBAS017100: Bound EJB [my-ejb-app/MyEjbBean!com.example.MyEjbRemote] into JNDI as ejb:/my-ejb-app/MyEjbBean!com.example.MyEjbRemote

• Search for any connection-related errors (e.g., SASL authentication failures, remoting startup issues) that could point to the root cause.

内容的提问来源于stack exchange，提问作者kim