Getresourceasstream Returns Null When Reading Properties File

getResourceAsStream returns null when reading properties file

You're trying to read a classpath resource relative to the Configuration class.

  • If you want to do this, the resource must be on the same relative path, i.e. your property file must be in src/main/resources/org/elasticsearch/utils.
  • Or you can instead use absolute path: /application.properties.

getResourceAsStream() returning null for properties file

The problem wasn't with the getResourceAsStream("config/config.properties"), but with the way I read the properties. Property FPS is written as a String, to make this in an int I had to use Integer.parseInt(), instead of Integer.getInteger().

getResourceAsStream() is returning null. Properties file is not loading

Oh oh ... There are several problems here:

1) In your first provided code snippet, you are using a ClassLoader for loading a resource file. This is indeed a good decision. But the getResourceAsStream method needs a "class-path relative" name. You are providing an absolute path.

2) Your second code snippet (after edit) results in not being able to find the file "D:...\LS360BatchImportIntegration\test.properties". According to your screenshot, the file should be "D:...\LS360AutomatedRegulatorsReportingService\test.properties". This is another directory.

I fear, that your descriptions are not up to date with the findings on your machine.

But let's just move to a reasonable solution:

1) In your Eclipse project (the screenshot tells us, that you are using Eclipse), create a new directory named "resources" in the same depth as your "src" directory. Copy - or better move - the properties file into it.

2) This new directory must be put into the "build path". Right-click the directory in the Package Explorer or Project Explorer view, select "Build Path", then "Use as Source Folder". Note: This build path will be the class path for the project, when you run it.

3) As the resources directory now is part of your class path and contains your properties file, you can simply load it with getResourceAsStream("test.properties").

EDIT

I just see, that you also use Maven (the pom.xml file). In Maven, such a resources directory exists by default and is part of the build path. It is "src/main/resources". If so, just use this.

Why would ClassLoader.getResourceAsStream() return null?

I solved the mystery.

The key to solving was embedding some diagnostic logging when propertiesStream is null:

String classpath = System.getProperty("java.class.path");
LOG.info("CLASSPATH: " + classpath);
ClassLoader loader = MyClientMain.class.getClassLoader();
System.out.println("ClassLoader resource path: " + loader.getResource("resource.properties"));

So when I run with the original

contextClassLoader.getResourceAsStream("resource.properties")

I receive the null pointer condition, printing:

  INFO: CLASSPATH: myproj.one-jar.jar
ClassLoader resource path: null

.

I then started suspecting something related to the "jar within a jar" as this is what the com.simontuffs.onejar essentially does (i.e. wrapping my project's jar inside a jar that contains all other library jars), so I opened myproj.one-jar.jar with 7-Zip and noted the full (absolute) path of "resource.properties":

myproj.one-jar.jar\main\myproj.jar\webapp\WEB-INF\classes\resource.properties

.

So I modified getResource("resource.properties") to:

 getResource("/main/myproj.jar/webapp/WEB-INF/classes/resource.properties")

which didn't fix the problem but printed the following upon the null pointer condition:

INFO: CLASSPATH: myproj.one-jar.jar
ClassLoader resource path: jar:file:/myproj.one-jar.jar!/main/myproj.jar!//main/myproj.jar/webapp/WEB-INF/classes/resource.properties

.

Then... divine intervention fell upon me and I had the insight (not reading any documentation that could even hint this, I swear!) that I should be using this path instead:

 getResource("/webapp/WEB-INF/classes/resource.properties")

And Voila! It works.

Whew.

class.getResourceAsStream returns null when looking for a properties file in same package

This says that if the .class file is in package "foo.bar.baz.props.properties", then that's the path you ought to give to the classloader:

l_IS = this.getClass().getResourceAsStream("foo/bar/baz/props.properties");

Your way will work only if it's at the root of the CLASSPATH.

Why does getResourceAsStream() return null when File does not exist before start of Test method?

The getResourceAsStream() method returns a stream for a resource on the classpath, using directory / index information that is cached by the classloader. If you add a resource to some directory tree or archive on the classpath after the classpath has been cached, the classloader is likely to not "see" it1.

That is most likely is what has happened in your test code.

A Java application should not be trying to treat classloader resources like a general purpose file system. Instead, use File or Path to denote files, and FileInputStream or similar to open them.


1 - The actual behavior does not appear to be specified in the javadocs for ClassLoader, etcetera. My description is based on the observed / reported behavior of some Java implementations.

getResourceAsStream returns null

Lifepaths.class.getClass().getResourceAsStream(...) loads resources using system class loader, it obviously fails because it does not see your JARs

Lifepaths.class.getResourceAsStream(...) loads resources using the same class loader that loaded Lifepaths class and it should have access to resources in your JARs

getResourceAsStream returning null in Java 10

I found a solution although I don't entirely understand why this works an the problematic line doesn't, but this works:

Application.class.getResourceAsStream("/application.properties")

where Application is just a class in my app.

Maybe this is related to the answer pointed to by ochi, and Application.class is using my class loader and appProperties.getClass() is using the system class loader. But why does it behave differently on differently on Java 8 vs 10 is not something that is apparent.



Related Topics



Leave a reply



Submit