apache/hadoop · error · IOException

Can not read resource file '{}' because class loader of the

Error message

Can not read resource file '{}' because class loader of the current thread is null

What it means

ThreadUtil.getResourceAsStream(String) loads a classpath resource through Thread.currentThread().getContextClassLoader(). If the current thread's context classloader is null — which happens when a thread was created without inheriting a TCCL or when something explicitly called setContextClassLoader(null) — the method throws this IOException before even attempting the lookup. The null check exists because delegating to the two-arg overload with a null loader would NPE inside the ClassLoader machinery.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/ThreadUtil.java:95

    }
  }

  /**
   * Convenience method that returns a resource as inputstream from the
   * classpath.
   * <p>
   * Uses the Thread's context classloader to load resource.
   *
   * @param resourceName resource to retrieve.
   *
   * @throws IOException thrown if resource cannot be loaded
   * @return inputstream with the resource.
   */
  public static InputStream getResourceAsStream(String resourceName)
      throws IOException {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    if (cl == null) {
      throw new IOException("Can not read resource file '" + resourceName +
          "' because class loader of the current thread is null");
    }
    return getResourceAsStream(cl, resourceName);
  }

  /**
   * Convenience method that returns a resource as inputstream from the
   * classpath using given classloader.
   * <p>
   *
   * @param cl ClassLoader to be used to retrieve resource.
   * @param resourceName resource to retrieve.
   *
   * @throws IOException thrown if resource cannot be loaded
   * @return inputstream with the resource.
   */
  public static InputStream getResourceAsStream(ClassLoader cl,
        String resourceName)

View on GitHub (pinned to 2add963021)

Solutions

  1. Use the two-arg overload with an explicit loader: ThreadUtil.getResourceAsStream(MyClass.class.getClassLoader(), resourceName).
  2. Set the TCCL before running the code: thread.setContextClassLoader(appClassLoader) or restore it inside the task.
  3. Catch IOException and retry with an explicit classloader as a defensive path.
  4. In thread factories, propagate the creating thread's TCCL to new threads.

Example fix

// before
InputStream is = ThreadUtil.getResourceAsStream("core-default.xml");
// throws: class loader of the current thread is null

// after
InputStream is = ThreadUtil.getResourceAsStream(
    MyApp.class.getClassLoader(), "core-default.xml");
Defensive patterns

Strategy: validation

Validate before calling

ClassLoader tccl = Thread.currentThread().getContextClassLoader();
if (tccl == null) {
  tccl = MyApp.class.getClassLoader(); // explicit fallback loader
}
InputStream is = ThreadUtil.getResourceAsStream(tccl, resourceName);

Try / catch

try {
  is = ThreadUtil.getResourceAsStream(resourceName);
} catch (IOException e) {
  // fall back to an explicit loader (null TCCL or missing resource)
  is = MyApp.class.getClassLoader().getResourceAsStream(resourceName);
  if (is == null) throw e;
}

Prevention

When it happens

Trigger: Threads created by raw constructors or thread pools in containers/applications where setContextClassLoader was never called; frameworks that clear the TCCL for classloading isolation; calling this helper from a shutdown hook or JNI-attached thread where TCCL is unset.

Common situations: Library code executed inside custom executor services; embedded Hadoop clients in application servers or OSGi environments that manipulate the TCCL; tests spawning worker threads that then try to read Hadoop configuration XML resources.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/ead7a7e69d22746f. Report an issue: GitHub.