Wildfly 9部署后无法加载Jar包资源目录中的DLL文件

Hey there, let's walk through why your DLL files aren't appearing alongside your executable in the deployment directory when deploying to WildFly 9. Here are the key areas to investigate:

1. Verify Your Jar Package Structure #

• First, confirm your DLLs are actually included in the Jar and placed in the correct resource path. It's easy to accidentally exclude them during packaging. Run this command to inspect your Jar's internal structure:

  jar tf your-application.jar
  

  Check that the DLLs sit in the same directory as your executable inside the Jar. If they're tucked away in a subfolder like META-INF/lib or an unrecognized path, WildFly might not extract them to the root deployment directory.

2. Check WildFly's Deployment Filter Rules #

• WildFly 9 has built-in deployment scanning rules that might filter out certain file types. Open your standalone.xml (or domain.xml for domain mode) and look for the deployment scanner subsystem:

  <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
      <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
  </subsystem>
  

  See if there's a filter attribute that excludes *.dll files. If such a filter exists, remove it to allow DLLs to be extracted.
• Also, if you're using a custom jboss-deployment-structure.xml to define your deployment layout, double-check that it isn't excluding the resource path where your DLLs are stored.

3. Validate Your Packaging Tool Configuration #

• If you're using Maven, Gradle, or another build tool, ensure your configuration includes DLL files in the final Jar. For example, in Maven's pom.xml, verify your resource inclusion rules:

  <build>
      <resources>
          <resource>
              <directory>src/main/resources</directory>
              <includes>
                  <include>*.exe</include>
                  <include>*.dll</include>
              </includes>
          </resource>
      </resources>
  </build>
  

• Make sure your DLLs aren't marked as test resources or excluded by any build profiles—this would prevent them from being packaged into the production Jar.

4. Check WildFly's Temporary Deployment Directory #

• WildFly doesn't extract Jar contents directly to the deployments folder where you upload your Jar. Instead, it unpacks the Jar to a temporary directory under standalone/tmp/vfs/ (or domain/tmp/vfs/ for domain mode).
• Navigate to this temporary folder and look for your deployment's unpacked files—your DLLs might be there even if they're not visible in the deployments directory. Don't confuse the original Jar's location with the actual unpacked deployment files.

5. Rule Out Permission or System-Level Issues #

• Ensure the user running WildFly has read permissions for the DLL files inside the Jar. On Windows, file locks or restrictive security settings might also interfere with extraction, though this is less common.
• While extraction doesn't depend on architecture, double-check that your DLLs match the bitness (32/64-bit) of your JVM and WildFly instance—this won't affect deployment extraction, but it will matter when you try to run the executable later.

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