Develop Reference

Finding XML file path in hibernate project

I am working on an hibernate project in which I need to read an xml. I placed those xmls in the same folder as the servlet from which I am trying to access those xmls. Now I don't know what is the correct path to access those xmls. Here is my project file structure. As can see, xmls are placed in com.strategycreator folder.
I can't place the xmls in a public directory as they need to be in a secure location.

If you need these files to be inaccessible to web page requests, you need to put them in your classpath and use them as resources.
The easiest way to find out the path to use for a classpath resource, is to generate the WAR, look inside the WAR in the appropriate JAR and see what path it ended up having and use that. If the file is "next to" a the class that needs to load it, you can use a relative path, otherwise you need to use the full "/com/strategycreator/groups.xml" path.

Java resources - Use file far off in directory tree

I have a newbie Java question.
I had to make suite of J/DBUnit tests for some stored procedures we use in SQL Server. These tests use some XML files in a couple of sub-directories that I originally had placed in the same directory as my Java project.
Anyway, upon checking these tests in, our SVN manager wanted to keep the .java files in one part of the tree, and resources (like the XML files and required JARs) in another part of the tree.
So, my tests had originally referenced the XML files with a relative path which doesn't work now.
My question is:
Can I make the directories with my XML files available with the CLASSPATH (I hope so).
Assuming that works, how do I reference a file in my code that was included this way?
If I shouldn't be using the CLASSPATH for this, I'm open to other solutions.

Forget calsspath. Provide your tests with a parameter/configuration which defines the root dir for the relative paths of the XML files.

Using the classpath is no problem, the standard maven project layout looks like the following:
src
main
java
resources
test
java
resources
target
classes
test-classes
The compiler compiles src/main/java to target/classes, the resources of src/main/resources are copied to the target/classes folder, similar for the tests. If the tests have a classpath containing classes and test-classes, all works fine.
How is your project layout is, how is it build?

No, you should not use CLASSPATH in this instance since it is used by Java. However, you can use a similar approach by loading a value from an environment variable or configuration file which indicates the directory where the XML files are stored.

You can do this without making any changes to your classpath. The idea is to store the resource files in a separate directory, but have them copied to a directory in your classpath when you run your build process.
Here is an example configuration:
source Directory is ${basedir}/src/main/java
resource directory is ${basedir}/src/main/resources
In your build script, copy both the .java files and the resource files (.xml) to a directory in your classpath, say:
${basedir}/target/classes
Your test code runs against the target dir. The target directory is not checked in to SVN, keeping your SVN admin happy, and you don't have to make changes to your code.

Why some resource files are put under META-INF directory

I am wondering why some resources files are put under the META-INF directory in the JAR? I am always put the resources like test.properties under the root diretcory. Any advantage to put them in the META-INF?

Lot of Java (EE) APIs have a contract that when you put a specific configuration/metadata file in the META-INF folder of your (or a 3rd party) JAR, then the API will automatically do the API-specific job, such as scanning classes, preloading specific classes and/or executing specific code based on the meta information.
An example provided by the standard Java SE API is the ServiceLoader. Among others, the JDBC 4.0 compatible drivers implement this. This way just dropping the JDBC driver JAR file folder will automatically load the driver class during Java application's startup/initialization without the need for any manual Class.forName("com.example.Driver") line in your code.
Further there is also the Java EE 6 provided JSF 2.0 API which scans during application's startup all JAR files for a faces-config.xml file in the META-INF folder. If present, it then will then take it as a hint to scan the entire JAR file for classes implementing the JSF specific annotations like #ManagedBean so that they get auto-instantiated and auto-configured. This saves time in potentially expensive job of scanning thousands of classes in all JARs in the entire classpath. In older versions of those API's the configuration was usually done by (verbose) XML files.
All with all, the major goal is to save the developer from code and/or configuration boilerplate. The JAR's META-INF folder is used for configuration files/hints. Some API's indeed also put static files/resources in there for own use. The META-INF folder is also part of the classpath, so the loading of those files by the classloader is easy done.

In servlet 3.0, certain static resources are available through the web context, such as .css, java script, and .png files, so you no longer need to use ServletContext getResource() and getResourceAsStream(). For more information, check out web-fragment.xml (https://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment) which is one resource that covers this subject.
Personally, I prefer to structure my projects the way Maven likes them, with a src/main/resources directory which is part of the application's classpath.

It's just a convention that some (most?) third party jars use to look for files that you provide. For your own classes and files, you can choose to put them where you like.

Java EE Directory Structure

I have a problem with following tutorial:
http://www.mkyong.com/jsf2/jsf-2-internationalization-example/
In faces-context file you have to declare the place where all the language properties-files are (<base-name>HERE</base-name>). But in that example they use apparently maven2 and so they have a resource folder.
I am using eclipse and dynamic web project, that's why there is no resource folder. I tried a few possibilities like adding a new folder to the build path but I don't get it work.
Can you tell me please where to place those files to let my app find it. thank you so much
In addition I add a picture of my directory-structure:

They need to end up in the runtime classpath. The WebContent isn't part of the runtime classpath.
In your case, just drop them in the Java Resources folder. Imagine that they are placed in a package com.example.i18n, then you can specify as basename com.example.i18n.locale (although I would prefer text or messages over locale since they are actually no locale files).
Related:
How to internationalize a JSF 2.0 webapplication with UTF-8 properties files without native2ascii?

What is the most common standard in a Java web app for including resources on the classpath?

I'm using internationalization with Spring, and the properties file needs to be on the classpath. I also have some XML files that will need to be on the classpath. Is it acceptable to just include those resources inside the "src" in a sub-directory, and then let them build to the classpath, or is it better to add a different folder to the classpath during startup? I'm using Ant, but from the looks of it this was the approach Maven took (everything under src or test). I'm looking for the most widely accepted industry standards or better alternatives. Thanks!

Is it acceptable to just include those resources inside the "src" in a sub-directory, and then let them build to the classpath
Depends on the sole purpose of the resource in question. With this approach, any minor edit in such a resource file would thus require a full rebuild, redeploy and restart.
This may not necessarily harm for one-time-read startup and applicationwide configuration files like web.xml and application.xml and consorts since that would usually affect (or be affected by) changes in Java source code which require a full rebuild/redeploy/etc anyway.
But in case of runtime files like i18n properties files and environment-specific configuration files (which would/could be managed by a non-developer like a serveradmin or a customer), it is not useful to package it inside the webapplication. This requires knowledge how to rebuild the webapp after edits. You would rather like to externalize it so that only a webapp restart is required to reflect the changes in the configuration, or maybe even not at all, like for ResourceBundle which will just reload automagically.
I myself usually put such files in a fixed path along the servletcontainer and add that path to the servletcontainer's runtime classpath. In case of for example Tomcat, it's configureable as shared.loader property in /conf/catalina.properties. E.g.
shared.loader=/var/webapp
Anything in this folder is then taken in the servletcontainer's (and webapp's) runtime classpath.

Anything you put in your WEB-INF/classes directory is automatically in the CLASSPATH.
I usually put only .java files under /src and /test directories. Any resources that I put elsewhere have to end up in WEB-INF/classes. It's either my IDE (IntelliJ) or Ant that put them there when the WAR file is created.
I would recommend following the Spring examples and put resources where they do.
For example, if you use Velocity as your templating engine, you'll see that Spring configuration allows you to put them under /WEB-INF/vm_views.
Properties are put in WEB-INF/classes.
Check the Spring docs for examples.