We Keep Coding

How the external xml configuration files can be made available for war/ear file during run time or in class path in Websphere?

We are using Websphere 9 application server. We want some of the configuration files such as xml and properties files in a separate directory of Websphere server and want them too see accessible by ear/war file during the run time. I heard about shared libraries approach, but it apppears that only class and jar files can be used as shared libraries, but not xml and other files. Can anyone tell me an alternative solution where the external xml configuration files be made available for war/ear file during run time or in class path?

If you add a directory as a shared library path, the directory itself will be added as a class path entry to any class loader referencing the shared library (along with any jar/zip files within it), so you'll have access to loose files such as XML files through the getResource() API.
Note that the argument to getResource() needs to be relative to the location within the directory. For example, if you have the file test.xml, you could add it to the directory /sharedlib, created a shared library named "library1", and associate it with your EAR or WAR, and then your application could use use this to get at the file:
this.class.getResource("test.xml");
That would return you a URL pointing at /sharedlib/test.xml.

Whats the best way to specify a path to read from class-path even if project was a jar

I am trying to read a Properties file in a maven nature project using the Properties.load(); I am specifying a path as a string ex. "./someFolder/file.properties",
but when I try to use my project as dependency in other projects I am forced to copy those files to the other project , simply because the "." means current directory.
Is there a way to specify a path so it will always be valid despite where I am calling it from ? ,
I have tried using the MyClass.class.getClassLoader().getResourceAsStream() but I am having trouble using it , it worked sometimes and failed other times.

There are lots of misconceptions in your question.
"." means classPath
No. When used inside a filesystem path (i.e. a path passed to the constructor of a File, or FileReader, or FileInputStream), "." means the current directory.
When used in a resource path (i.e. passed to Class[Loader].getResource[AsStream]()), it's invalid.
The trick is to carefully read the documentation.
getResourceAsStream() expects a /-separated path.
When using ClassLoader.getResource[AsStream](), this path always starts from the root of the classpath. So you would pass a path looking exactly like a fully qualified class name, except the dots would be replaced by slashes. So, com/foo/bar.properties looks for a resource named bar.properties, in the package com.foo.
When using SomeClass.class.getResource[AsStream](), either the path starts with a /, and the path starts from the root of the classpath, or it doesn't, and it starts from the package of SomeClass. So, if SomeClass is in the package com.foo, using /com/foo/bar.properties is equivalent to using bar.properties.
It's hard to tell what you're doing wrong, since you're not providing any detail. But you really need to understand the difference between opening a file on the file system, and reading a resource loaded by the class loader. Sometimes, the resources just happen to be loaded by the class loader from the filesystem, because the classpath happens to contain directories, and not just jar files.

I noticed that my problem was that I had my properties files in the project path itself, and that the ClassLoader.getResource[AsStream](); looks is the target/classes folder, and that I didn't have the resources folder in my project.
I solved it my adding the resources folder to my build path and adding my files in the src/main/resources as the following src/main/resources/foo/bar.properties and loading it by SomeClass.class.getClassLoader().loadResourceAsStream("foo/bar.properties");.

Load resource from class's own JAR file

When using Class.getResource() and supplying a rather common resource name, like "license.html", Java may load a "license.html" resource from another JAR file which is listed earlier in the CLASSPATH, but may be completely unrelated to my application. Is there a way to force the ClassLoader to first try to load the resource from the same JAR file which my class is in and only if not found, look in other JARs on the CLASSPATH?

Alternatively you could use the JarURLConnection if you know the exact jar in which your file resides:
jar:<url>!/{entry}

..common resource name, like "license.html"'
A good reason to give it an uncommon path, for instance according to the package name.
E.G. "/com/our/app/license.html" is unlikely to collide with any other license.html

Absolute Path of Project's folder in Java

Lots of confusion in this topic. Several Questions have been asked. Things still seem unclear.
ClassLoader, Absolute File Paths etc etc
Suppose I have a project directory structure as,
MyProject--
--dist
--lib
--src
--test
I have a resource say "txtfile.txt" in "lib/txt" directory. I want to access it in a system independent way. I need the absolute path of the project.
So I can code the path as abspath+"/lib/Dictionary/txtfile.txt"
Suppose I do this
java.io.File file = new java.io.File(""); //Dummy file
String abspath=file.getAbsolutePath();
I get the current working directory which is not necessarily project root.
Suppose I execute the final 'prj.jar' from the 'dist' folder which also contains "lib/txt/txtfile.txt" directory structure and resource,It should work here too. I should absolute path of dist folder.
Hope the problem is clear.

You should really be using getResource() or getResourceAsStream() using your class loader for this sort of thing. In particular, these methods use your ClassLoader to determine the search context for resources within your project.
Specify something like getClass().getResource("lib/txtfile.txt") in order to pick up the text file.
To clarify: instead of thinking about how to get the path of the resource you ought to be thinking about getting the resource -- in this case a file in a directory somewhere (possibly inside your JAR). It's not necessary to know some absolute path in this case, only some URL to get at the file, and the ClassLoader will return this URL for you. If you want to open a stream to the file you can do this directly without messing around with a URL using getResourceAsStream.
The resources you're trying to access through the ClassLoader need to be on the Class-Path (configured in the Manifest of your JAR file). This is critical! The ClassLoader uses the Class-Path to find the resources, so if you don't provide enough context in the Class-Path it won't be able to find anything. If you add . the ClassLoader should resolve anything inside or outside of the JAR depending on how you refer to the resource, though you can certainly be more specific.
Referring to the resource prefixed with a . will cause the ClassLoader to also look for files outside of the JAR, while not prefixing the resource path with a period will direct the ClassLoader to look only inside the JAR file.
That means if you have some file inside the JAR in a directory lib with name foo.txt and you want to get the resource then you'd run getResource("lib/foo.txt");
If the same resource were outside the JAR you'd run getResource("./lib/foo.txt");

First, make sure the lib directory is in your classpath. You can do this by adding the command line parameter in your startup script:
$JAVA_HOME/bin/java -classpath .:lib com.example.MyMainClass
save this as MyProject/start.sh or any os dependent script.
Then you can access the textfile.txt (as rightly mentioned by Mark) as:
// if you want this as a File
URL res = getClass().getClassLoader().getResource("text/textfile.txt");
File f = new File(res.getFile());
// As InputStream
InputStream in = getClass().getClassLoader()
.getResourceAsStream("text/textfile.txt");

#Mark is correct. That is by far the simplest and most robust approach.
However, if you really have to have a File, then your best bet is to try the following:
turn the contents of the System property "java.class.path" into a list of pathnames,
identify the JAR pathname in the list based on its filename,
figure out what "../.." is relative to the JAR pathname to give you the "project" directory, and
build your target path relative to the project directory.
Another alternative is to embed the project directory name in a wrapper script and set it as a system property using a -D option. It is also possible to have a wrapper script figure out its own absolute pathname; e.g. using whence.

Java WebApp: Loading resource from .jar located in WEB-INF

There are a lot of similar questions, but, probably, mine is a little bit different:
What is the right way to load resource from inside of .jar file located in WEB-INF/lib folder (if I know the jar file name and the name of the class it resource belongs to), while Web Application is running? Should I use getServletContext().getResourceAsStream(?) for this purpose or the <name-of-known-class>.getResourseAsStream(?), and what path do I need to specify there?
So, the structure is:
/WEB-INF
/classes
/some/package/name
?.class #some Java code or Servlet that tries to read 'required-file.xml'
/lib
/<jar-with-known-name>.jar
/another/package/with/known/name
SomeKnownClass.class
required-file.xml

You should use <name-of-known-class>.getResourseAsStream(?), which loads resources using the "local" classloader. In the case of a webapp, this will use the webapp's classloader.
The getServletContext().getResourceAsStream(?) method will return webapp resources relative to the webapp root, and cannot look inside JAR files.
The javadoc for this method describes the path you need to specify, but essentially you can use paths relative to the known class, e.g.
SomeKnownClass.class.getResourceAsStream("required-file.xml");