0

I have a properties file called app.properties that is correctly put in src/main/resources/app.properties.

In the WAR file it is correctly located in \WEB-INF\classes.

In Standalone mode in my local environment (windows) and standalone mode on a linux test server, the WAR file starts up correctly reading my properties file.

In Jboss Domain mode on another linux server, using the exact same WAR file, I get error file not found app.properties. It is indeed there.

Other than domain mode being the difference between the two servers, the first test server jboss is installed under root and running as root. The other server is running as a user that has read and execute access.

I've thoroughly debugged the code with print statements and im 99% sure it is not a code issue, any ideas what in jboss domain mode may be causing the problem of not being able to read the properties file on the classpath?

Thanks in advance.

Relevant parts of code 

MutablePropertySources sources = new MutablePropertySources();
sources.addLast(getEncryptablePropertiesSource(new ClassPathResource("app.properties")));

partial method

private EncryptablePropertiesPropertySource getEncryptablePropertiesSource(Resource propsResource) throws IOException{
    //don't use file system resource because property files may be in a jar
    System.out.println(">>>> in getEncryptablePropertiesSource filename is :");
    System.out.println(propsResource.getFilename());
    System.out.print(">>>> URL is: ");      
    System.out.println(propsResource.getURL());

The last System out print statement throws the error in the 2nd test environment, does not cause problems in any other environment.

Stefan
  • 352
  • 3
  • 15

1 Answers1

0

If your ClassPathResource is the class from Spring:

public class ClassPathResource extends AbstractFileResolvingResource

Resource implementation for class path resources. Uses either a given ClassLoader or a given Class for loading resources.

Supports resolution as java.io.File if the class path resource resides in the file system, but not for resources in a JAR. Always supports resolution as URL.

Therefore I don't think you can use it in your case. Have you tried using one of the following methods?

Maaaatt
  • 429
  • 4
  • 14
  • What i have does work, here is the print statements working on 2/3 of the environments i have tried on. Your suggestion would be taking a slightly different approach, which i may end up doing, but id rather solve the root of the problem 2017-08-03 06:45:27,507 INFO [stdout] (MSC service thread 1-3) >>>> in getEncryptablePropertiesSource filename is : 2017-08-03 06:45:27,508 INFO [stdout] (MSC service thread 1-3) app.properties 2017-08-03 06:45:27,508 INFO [stdout] (MSC service thread 1-3) >>>> URL is: vfs:/content/mfds.war/WEB-INF/classes/app.properties – Stefan Aug 03 '17 at 15:53
  • Your choice! Could be the kind of situation where it works in 2/3 of the environments when it should never work at all. If you continue to use the ClassPathResource, you need to find what is different between your env to see if there is a solution. However, I wouldn't follow this path if the doc doesn't recommend it. – Maaaatt Aug 03 '17 at 16:07
  • See the highest upvoted answer, it is what im doing essentially. https://stackoverflow.com/questions/1771166/access-properties-file-programmatically-with-spring – Stefan Aug 03 '17 at 18:37
  • I understand but nothing says that the file is part of a jar in his question. By the way, could you try the ClassPathResource with a full path to your file just to see. – Maaaatt Aug 03 '17 at 18:49
  • So it gets stranger. i used the getResourceAsStream, and still only works in 2/3 environments... thanks for your help so far. – Stefan Aug 04 '17 at 15:09
  • This ultimately worked around the issue i was experiencing, i had to try different variations of getResourceAsStream to get one that worked. This was my final solution. Thanks for the help. this.getClass().getClassLoader().getResourceAsStream("/"+resourceName) – Stefan Aug 08 '17 at 14:10
  • Did you manage to come to a conclusion to why it was bugging in your last environment? – Maaaatt Aug 09 '17 at 08:02
  • yes figured it out. It was a conflict with the jpa subsystem in domain.xml and with the jpa jars being included in my WAR file. This was the true root cause of the issue i was experiencing and using getResourceAsStream is no longer necessary. – Stefan Aug 09 '17 at 14:27