Include it as part of your project.
Stick it in your(/a) src directory, and eclipse should then include it in your deployment.
Then refer to it based on its location in that directory.
Printable View
Include it as part of your project.
Stick it in your(/a) src directory, and eclipse should then include it in your deployment.
Then refer to it based on its location in that directory.
Here is my Eclipse directory structure: Attachment 3861
The XML is loaded in helper.BeanManager, but with "src/xml/data.xml" it can't be loaded. In a normal desktop Java application, "src/xml/data.xml" works, but here it doesn't.
Because it is deployed on the server, and you need to tell Eclipse to include that directory when it deploys.
When you run a "normal app" through Eclipse, it runs based on the project home directory.
Personally I would cheat and stick it in your WEB-INF, possibly even straight into the classes sub-directory.
When the files are created, they are at first in the Eclipse project folder. Later, when the application is started, the files are copied to the server folders, but I haven't yet understood quite well how the Eclipse projekt structure is mapped to the deployment structure on the server.
My path is "/data.xml". I copied the XML-file to WEB-INF, to ROOT and to WEB-INF/classes, but the file couldn't be found.
I would get hold of Tomcat or some other external server.
Then run it up on that./
I found a solution:
This works for all kind of resources.Code:ServletContext context = getServletContext();
InputStream input = getServletContext().getResourceAsStream(
"/xml/data.xml");
Normally shared data is stored in the application object. Why did you recommend to use a singleton object here? Is a custom-made singleton maybe more lightweight?
What do you mean by "application object"?
I suggested a singleton as you had a requirement to load static data into a bunch of objects that you would then access during the run of the application.
That static data was to be loaded by the time the first thing needing it tried to access it.
It's more standard than the technique you were attempting.
I thought of saving the object in application scope by using).Code:application.setAttribute(String objName, Object object
BTW, is there any possibility to test locally if one's application is threadsafe?
The application scope is rarely used directly.
You'll see application properties, but they're rarely added to and removed from that scope by you.
Testing thread safety of an app is difficult to do.
It's more about simply not doing certain things in the first place (like giving Servlets attributes).
If you're concerned about a particular thing you could make it synchronised, I suppose.