I have some questions about Wildfly deployment
1.An ear, when deployed in wildfly, is extracted within standalone/tmp/vfs/deployment/ directory. Can I place a file there manually and still access it from web. (I can check it, but as of now I do not have any machine to test it).
Can I create a file and place it there via some program. The reason I am asking this question is that I need to generate some files based on user input and provide the user with a link to that file. One way to do this is to statically link a directory in JBOSS and create the file there(access it using file handlers see this). I just want to know if it can be done at all using something like VFS.
If you need to persist to a file you'd want to create a new file handler, like the link you provided describes, and write the file to that folder. You don't want to try to use that temporary deployment directory. The content is not exploded by default so writing to it would likely fail.
If you don't need to persist to a file you can just use an output stream of some sort and the user will be able to download the file.
Related
I've looked at a number of related cases here on stackoverflow related to this, but mostly deal with the situation of deciding where to put external files and access them, which is quite clear.
In my situation, I have a Java EE application that needs to use a third party library that reads an external config file to determine the location of another file. I am using Eclipse and Tomcat.
The external config file has a line that reads like: FILENAME=[path], where path is expected to be the full path name to the file.
I have no way of knowing how they access the file, save to say that specifying /WEB-INF/classes/file or just file does not work, the library can't find it. However when I put the full name /Users/.../file on my local machine, it can find it.
As this is intended to be deployed on production server in the cloud, is my only solution to put the needed file in cloud storage, then set the config file to point to this absolute location ?
So I have a web app (using apache tomcat server,servlets,eclipse IDE). I wrote code to allow user to edit the XML file via UI. So I used the following code to access the XML through java
String fileName = "/MyXML.xml";
String path = this.getClass().getResource(fileName).toString();
This works fine. I am able to edit the file through UI.
Now I want to let the client download the file. But I am not able to access the file while I am trying to download.
However, if I keep the file inside webapps folder, then I can access the file using the following
ServletContext ctx = getServletContext();
InputStream is = ctx.getResourceAsStream("/MyXML.xml");
(Thanku Mr.MK Yong- http://www.mkyong.com/servlet/servlet-code-to-download-text-file-from-website-java/)
But then If i keep it inside webapp folder, how do I access the file for editing the XML ?
So basically I am either able to edit the file, or I am able to download the file(from webapp folder), or I am able to do both on two different copies of the file. I want to edit the XMl file and be able to download the same. So where do I keep the file and how do I access it?
You should store it in the local resource folder as it is essentially a dynamic resource.
The other thing i recommend is if you know the parameters that will be changed then have a template in resource folder and store the changes in database.
Personally i have it the second way.
e.g.
/yourapp/resource/config_file/xmltemplate.xml
Parameters that can change:
userLocation
folderLocation
colorBase
Stored them in the table:
Table: UserCongifStorage
Columns: userLocation, folderLocation, colorBase
So when i need to use the data from row 1 the logic is:
read in the xml file into a string, replace the variables with data retrieved from database, output it as xml to resource folder.
Then you read for usage.
Hope that helps
If the file is in your 'webapp' folder (I think you mean your application root), then it is already accessiable to everyone by calling hxxp://domainname/appname/MyXML.xml. I would suggest you not to store files that can be edited, inside your app folders, since they will be overwritten if you redeploy your application.
Put them in an external directory and load the contents like you would do with all other files. Doing this you can take control over file permissions easily, too.
Alright heres the scenario. I'm creating a dynamic website with Java\JSP\JS. I'm using the Java to access a database and query a table to get information. Instead of passing that query to the JSP, I decided to create a JS file with a class in it with all of that information. (I'm basically building a store locator that will update itself with new stores\locations whenever the user presses a button. Obviously they need to update the table first but you get the point)
And now onto my problem. I'm creating the file by opening a stream. (But first I check to see if the file exists and if it does delete it, because I don't want to keep writing to that same file every time a user clicks the button.)
FileWriter fstream = new FileWriter("test.js");
The location of the file goes to my Eclipse folder directory, obviously. Even doing this,
FileWriter fstream = new FileWriter("./test.js");
put it there. Granted I didn't think it would change but I was testing it out.
The location of the JSP file when the project isn't 'deployed', or testing, its in the workspace location. But when it is 'deployed'
\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\BoomBaby\index.jsp
When I get the location of the JS file its:
/C:/Program%20Files/Apache/lib/
So my question, after all of this, is: How do I save the JS file in the same directory as the JSP file while deployed so I can access it from a JSP file by:
<script type="text/javascript" src="test.js"></script>
You need to build a WAR file. It is basically a zip file with a standardized layout. You put all your jsps in one place, and all your js files in another. Containers like tomcat understand the layout of the war and will run your application automatically. Popular build tools like ant and maven will construct wars for you with little effort.
You can't when deployed as a WAR file. The way this is usually done is, instead of generating a file and referring to it, generate the JavaScript source into the page directly.
We have to make a Java application demo available on Internet using JWS. It goes pretty well; all that's missing is making working directory files available for the application.
We know about the getResource() way... The problem is that we have different plugins for the same application and each one require different files (and often different versions of the same files) in their working directory to work properly. So we just change the working directory when we want the application to have a different behavior.
Currently, the demo is packaged in a signed jar file and it loads correctly until it requires a file from the working directory. Obviously, the Internet users of this demo don't have the files ready. We need a way to make these files available to the WebStart application (read/write access) in its working directory.
We've thought of some things, like having the application download the files itself when it starts, or package them in the jar and extract them on startup.
Looking for advices and/or new ideas. I'll continue working on this... I'll update if I ever find something reliable.
Thank you very much!
I said I would share what I found in my research for something that would fit my needs. Here's what I have so far.
I have found that the concept of current working directory (CWD) does not really make sense in the context of a Java Web Start (JWS) application. This had for effect that I stopped trying to find the CWD of a JWS and started looking for other options.
I have found that (no, I didn't know that) you can refer (using getResource()) to a file in the root directory of a JAR file by simply adding a '/' in front of its name. ("/log4j.properties", for example.) The impact of this is that I can now take any file which is only referred to in a read-only manner in the root of that JAR file (which is really only a ZIP file). You can refer to any file in the root of the JAR file using AnyClass.class.getResourceAsStream. That rules out the problem with read-only files required to run the application, at the cost of a switch in the code telling whether the application is run from a valid CWD or from a JWS context. (You can very simply set a property in the JNLP file of the JWS application and check if that property is set or not to know where to look for the file.)
For write-only files (log files in my case), I used the property , adding a directory with the name of the application: <user.home>/.appname and added log files to it.
Read/write files (which I don't have in my case) would probably simply go at the same place than write-only files. The software could deal with uploading them somewhere if needed, once modified, I guess.
That's the way I deal with the problem for now.
Note there is a service you can explicitly ask for, to get file access to the computer (unless you go all the way and ask for full access (which requires signed jar files)).
Then you need to determine where these files need to go - basically you have no idea what is where and whether you may actually write anywhere. You can create tmp-files but those go away.
Would a file system abstraction talking to the JNLP-server do so you store the users data on the server?
I create a web application (WAR) and deploy it on Tomcat. In the webapp there is a page with a form where an administrator can enter some configuration data. I don't want to store this data in an DBMS, but just in an XML file on the file system. Where to put it?
I would like to put the file somewhere in the directory tree where the application itself is deployed. Should my configuration file be in the WEB-INF directory? Or put it somewhere else?
And what is the Java code to use in a servlet to find the absolute path of the directory? Or can it be accessed with a relative path?
What we do is to put it in a separate directory on the server (you could use something like /config, /opt/config, /root/config, /home/username/config, or anything you want). When our servlets start up, they read the XML file, get a few things out of it (most importantly DB connection information), and that's it.
I asked about why we did this once.
It would be nice to store everything in the DB, but obviously you can't store DB connection information in the DB.
You could hardcode things in the code, but that's ugly for many reasons. If the info ever has to change you have to rebuild the code and redeploy. If someone gets a copy of your code or your WAR file they would then get that information.
Putting things in the WAR file seems nice, but if you want to change things much it could be a bad idea. The problem is that if you have to change the information, then next time you redeploy it will overwrite the file so anything you didn't remember to change in the version getting built into the WAR gets forgotten.
The file in a special place on the file system thing works quite well for us. It doesn't have any big downsides. You know where it is, it's stored seperatly, makes deploying to multiple machines easy if they all need different config values (since it's not part of the WAR).
The only other solution I can think of that would work well would be keeping everything in the DB except the DB login info. That would come from Java system properties that are retrieved through the JVM. This the Preferences API thing mentioned by Hans Doggen above. I don't think it was around when our application was first developed, if it was it wasn't used.
As for the path for accessing the configuration file, it's just a file on the filesystem. You don't need to worry about the web path. So when your servlet starts up it just opens the file at "/config/myapp/config.xml" (or whatever) and it will find the right thing. Just hardcodeing the path in for this one seems pretty harmless to me.
WEB-INF is a good place to put your config file. Here's some code to get the absolute path of the directory from a servlet.
public void init(ServletConfig servletConfig) throws ServletException{
super.init(servletConfig);
String path = servletConfig.getServletContext().getRealPath("/WEB-INF")
Putting it in WEB-INF will hide the XML file from users who try to access it directly through a URL, so yes, I'd say put it in WEB-INF.
I would not store it in the application folder, because that would override the configuration with a new deployment of the application.
I suggest you have a look at the Preferences API, or write something in the users folder (the user that is running Tomcat).
The answer to this depends on how you intend to read and write that config file.
For example, the Spring framework gives you the ability to use XML configuration files (or Java property files); these can be stored in your classpath (e.g., in the WEB-INF directory), anywhere else on the filesystem, or even in memory. If you were to use Spring for this, then the easiest place to store the config file is in your WEB-INF directory, and then use Spring's ClassPathXmlApplicationContext class to access your configuration file.
But again, it all depends on how you plan to access that file.
If it is your custom config WEB-INF is a good place for it. But some libraries may require configs to reside in WEB-INF/classes.