• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

I have a properties file, I have no idea where it goes in Tomcat so that tomcat can see it

 
Ranch Hand
Posts: 635
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There doesnt seem to any real documentation. I have tried to use classLoader. but that only works in testing.
 
Saloon Keeper
Posts: 6522
160
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What kind of properties? What is Tomcat supposed to do with it? Or do you mean a web app of yours that runs inside of Tomcat? If so, what is it supposed to do with that file, meaning, how does it use it?
 
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It doesn't "go in Tomcat". It goes in the web application (WAR).

The best place to put a properties file would be in the webapp's WEB-INF/classes directory, which is part of the application classpath.
 
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note that if you're using Maven, you can put your properties file in a subfolder relative to src/main/resources/ and then Maven will automatically put it in the WEB-INF/classes directory of your WAR. It's a good idea to put resources in the same package as the class that uses the resource.

For instance, if you have a class com.example.myapp.ApplicationConfig that uses a properties file 'app.properties', you can put the properties file in the src/main/resources/com/example/myapp/ folder. You can then refer to the file from ApplicationConfig using ApplicationConfig.class.getResourceAsStream("app.properties").
 
Tim Holloway
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, the preferred place to put resources in a Maven WAR project is in /src/main/webapp. Using /src/main/resource works, but there is a subtle difference, if I remember.

Also, to locate a webapp resource such as WEB-INF/classes/app.properties, the best way is to use the ApplicationContext getResource() or getResourceAsStream() method, like so:



This is approximate code, since generally you'd want to do things like store "props" as an ApplicationScope bean and I think you have to close propStream also.

Use the class introspection methods as a last resource. Class paths are pretty convoluted in web applications. Plus the logic is simpler if you use the JEE API instead of the base JVM methods.

And NEVER assume that the properties file in a WAR is an actual FILE. It might be just an entry in a ZIP (WAR) archive!
 
Stephan van Hulst
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Actually, the preferred place to put resources in a Maven WAR project is in /src/main/webapp. Using /src/main/resource works, but there is a subtle difference, if I remember.


Files and folders directly under src/main/webapp/ will be put in the root of the WAR. They are treated as static resources that will be served by the web application container. They are not on the class path so they can not be loaded from the WAR by the class loader. These files are intended to be downloaded by the browser, such as images, client-side scripts and style sheets.

The application container will not serve files that are located in META-INF or WEB-INF. These are private files and are also not on the class path, so they can not be loaded from the WAR by the class loader.

The application container will also not serve files that are located in WEB-INF/classes, but the difference is that these files are on the class path. This is where you want compiled code to be, as well as static resources that are accessed by server-side code. Maven will put the (compiled/filtered) contents of all source and resource folders here, including src/main/resources.

Of course, it's possible to put server-side resources directly in src/main/webapp/WEB-INF/classes/ to achieve the same effect as putting them in src/main/resources/, but then you're really ignoring that Maven includes src/main/resources/ for a purpose.

Also, to locate a webapp resource such as WEB-INF/classes/app.properties, the best way is to use the ApplicationContext getResource() or getResourceAsStream() method, like so:



Seeing as the root folder of the WAR is not on the class path, but the WEB-INF/classes folder is, you would just access the app.properties file like this:
 
Tim Holloway
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had really hoped that anyone who looked at the use for Maven's /src/main/webapp would have understood that that was a source relative to the root of the webapp without having to say so explicitly.

The getResource methods do not reference the webapp classpath. The name even says so. They look for resources, using the resource path. The Resource Path is the location within a WAR relative to the root of the WAR (just like /src/main/webapp in Maven, which is not a co-incidence). So if you put a properties file in /WEB-INF/classes/app.properties and try to use /app.properties as its resource path, it will fail.  The Resource Path is the internal resource path, not the external URL resource path, and it can look inside /WEB-INF with impunity and will not resolve to JSP/servlet calls etc.
 
Stephan van Hulst
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:The Resource Path is the location within a WAR relative to the root of the WAR


Do you have any official documentation to support this, or an SSCCE? I'm absolutely certain that this statement is wrong.

So if you put a properties file in /WEB-INF/classes/app.properties and try to use /app.properties as its resource path, it will fail.


It worked absolutely fine for me.

The Resource Path is the internal resource path, not the external URL resource path


Agreed. And resource paths are resolved against your class path. Which for WAR files is the WEB-INF/classes folder.
 
Stephan van Hulst
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I only now see that you're talking about ServletContext.getResourceAsStream(), not Class.getResourceAsStream().

The documentation even says:

This method is different from java.lang.Class.getResourceAsStream, which uses a class loader. This method allows servlet containers to make a resource available to a servlet from any location, without using a class loader.



I suppose that seeing as the Servlet API provided a dedicated method to handle this scenario, it's preferable to using the Class.getResourceStream() variant.
 
Tim Moores
Saloon Keeper
Posts: 6522
160
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The Resource Path is the location within a WAR relative to the root of the WAR


Do you have any official documentation to support this, or an SSCCE? I'm absolutely certain that this statement is wrong.


The javadocs of ServletContext.getResourceAsStream are silent on this, but the one for ServletContext.getResource says


The path must begin with a / and is interpreted as relative to the current context root, or relative to the /META-INF/resources directory of a JAR file inside the web application's /WEB-INF/lib directory. This method will first search the document root of the web application for the requested resource, before searching any of the JAR files inside /WEB-INF/lib. The order in which the JAR files inside /WEB-INF/lib are searched is undefined.


So that's a bit different from what ClassLoader.getResourceAsStream does.

Update: Too late
 
Tim Holloway
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, when designing for JEE, it's preferable to use the JEE functions over the general Java functions. They're more in tune with the environment and, of course, more likely to support changes to that environment. Case in point: The JEE getResource methods looking in the WAR's /META-INF/resources is a later addition, I think. And probably in large part added to support the JavaServer Faces (V2) resource model.

While I said that the resource path was relative to "the root of the WAR", as you can see, it's actually more complex than that, since each jar in /WEB-INF/lib is also considered to serve from the context root as well, and, of course the /META-INF/resources additionally. In my defense, my own practice has been generally as direct WAR files, although if I'd been doing drop-in libraries for webapps, then I would have been more familiar with that option.

Likewise, when I recommend Maven use /src/main/webapp over /src/main/resources, it's because /src/main/resources is provided by the base JAR-building mechanism upon which the Maven webapp mojo is built. There is, as I said, a difference, although I cannot remember what it is. For the most part, using /src/main/resources is equivalent, but as with the core Class getResource versus JEE getResource, I recommend using the one specifically designed for the task at hand.
    Bookmark Topic Watch Topic
  • New Topic