I need to create a control-file (for SQLLoader) depending on some variables (filename, bad-filename, table to load into, etc).
Right now I have a method in java that creates the file and works fine. My problem comes when I have to modify the structure of that control file. I need to change that in java source code, compile, undeploy previous app, deploy the new one, just to change that control's file structure.
I was wondering if there is a way to make a template where I just pass the variables (mentioned above) but outside java, let's say some kind of xml or something, so I just change that "template" and voilà my app just fill in the variables.
In one of our applications we generate the control file from code (in our case C#, but that doesn't matter)
Create the file from a template (outside of your app), fill in the variables and have your application copy it to the place where SQLLoader expects it.
Only thing you need is for your java app to have permission to write to that directory.
If it is a Java web application this is a little tricky, as writing files from the webapp can introduce a security risk
Related
I've been trying to make jar application that can read a csv file in the same directory as it. This is, however, proving difficult as my means for accessing the file currently is:
InputStream is = getClass().getClassLoader().getResourceAsStream(filename);
Which works for my program running in the IDE and for my tests but doesn't work when I run the program from the compiled jar file. I have no idea how to get it to work for both. I seriously can't understand this path stuff, it seems like there are a million ways to do it and only one of them work for only one specific scenario.
I've been trying to make jar application that can read a csv file in the same directory as it.
Ah, there's your problem. That just isn't a thing.
There are only 2 types of files:
Application Resources
These are read only, and are as much part of your app as your class files are. It is not in any way relevant to think about 'editing' them - that's not the kind of thing they are. It is reasonable to assume that if this resource is somehow missing, the app is as corrupt / misinstalled as it would be if class files are missing.
For this, you use .getResource and .getResourceAsStream. And note that getClass().getClassLoader() is wrong, you want MyClass.class.getResource and then add a slash if you want to go from root (because getClass() potentially breaks when you subclass, and going via classloader is [A] just typing for no reason, and [B] breaks in bootload scenarios. MyOwnClassName.class.getResource never breaks, so, always use that).
This asks java to look in the same place class files are and nowhere else. Your class files are inside the jar files, and not next to them, therefore, it won't find a text file that is sitting next to jar files.
it does not make sense that it does work during development: That means you shoved a file inside the resources folder, which is equivalent to having a CSV file inside the jar file. You must have gone out of your way to tell your build system to do weird things. Don't do that.
If that CSV file is not intended to be user editable it should be inside the jar file and not next to it: That makes it an application resource. Examples of application resources:
You have a GUI, and you need to store the icon files and splash screen art and such someplace.
You ship static data with your app, such as a table of all US states along with the zipcodes they use (could be a text or csv file for example).
Templates of config files. Not config files themselves.
DLLs and the like that you need to unpack (because windows/linux/mac isn't going to look inside jars for them).
You're a webapp and you want to ship the HTML static files along with your webapp.
If this is what your CSV file is, the fix is to put it in the jar, not next to it, then load it with MyClass.class.getResource(name).
Config files and project files
For example:
For a rich text editor (like, say, LibreOffice Writer), the .odt files representing your writings.
Save games for a game.
A config file, which can be edited by the user, or is edited by your own app in a 'preferences' dialog. This stores for example whether to open the app full screen or not, or authentication info for a third party API you're using.
These should not be in the jar, should not be loaded with .getResource at all, and should not be in src/main/resources in the first place.
They also should not be next to your jar! That's an outdated and insecure model (the idea that editable files sit in the same place the app itself sits): A proper OS configuration means that an app cannot write to itself which is most easily accomplished by having it be incapable of writing to its directory. Some OSes (notably, windows) did this wrong for a while.
For example on windows, your app lives in C:\Program Files\MakorisAwesomeApp\makori.jar, and the data files for it live somewhere in C:\Users\UserThatInstalledIt\Documents\MakorisAwesomeApp.
oh linux, your app might be /usr/bin/makori and the data lives somewhere in the home dir. Config data might live in /etc/.
You don't "ship" your config files, you instead make installers that create them. You can do this part in-app by detecting that the relevant config file does not exist, load in a template (that is a resource, shipped inside your jar, loaded with getResource), and write it out, and tell the user to go look at it and edit it.
I really want a CSV file next to my jars!
Well, that's wrong, so, there are no libraries that make this easy. When you want to do silly things its good that APIs don't make that easy, right?
There are really hacky ways to do this. You can use .getResource to get a URL and then 'parse' this. This breaks the classloader abstraction concept (because in java, you can write your own classloaders and they can load from anywhere, not just files or entries in jars), but you can ask for 'yourself' (MyClass.class.getResource("MyClass.class")), pull the URL apart and figure out what's happening - does it start with file://? Then it is a file, so turn it into a j.i.File object, and go from there. Does it start with jar://? find the !, substring out the jar part, and now you know the jar. Make that a java.io.File, ask for the parent dir, and look there for the CSV.
You have to write all this. It's complicated code that is hard to test. You should not do this.
I need to load "configuration" type files for my program in Android, they are both .bin files containing dictionary data for the NLP library. I'm a bit new to Android still, and I'm having trouble finding a folder to place the files in so I can access them when the activity starts.
I also need to create/save/load a filetype specific to my program, and I don't know where to put it either. All I've been able to find on here is people using the getAssetManager() function to fetch input streams, but I explicitly need File objects for me to be able to load them into my pre-existing desktop software code I'd like to reuse (plus the libraries require them anyway)
I've also seen people using a "res/raw" folder, however the ADT did not generate this "raw" file when I made the project - so I'm not sure what to do there either.
Here is how I usually start the software in the desktop version, but I need to fetch these files in an Android environment:
brain.start(new File("memboric.core"), new File("en_pos_maxent.bin"), new File("en_sent.bin"));
core = brain.getInterpreter().getCore();
The memboric.core file can be generated, but I need to know WHERE and HOW to do so.
Thank you very much for your time, feel free to direct me to other resources if you feel this question is inadequate.
TLDR; how do I load "static" files for the software to function (needs to be included with software), and how to create/load/save "personal" files into an appropriate area of the device?
Use Context.getFilesDir(). Your application can read and write files in that folder and they'll automatically get deleted if your application gets uninstalled.
From that point forward, you can create, delete and read from files like any other Java application.
the "raw"-folder you can create it on your own. So check this out, which shows how to handle files in Android: http://developer.android.com/training/basics/data-storage/files.html
Task: Copy Folder and contents from one vdi to another vdi. This application is internally facing within the company.
Method:
In jsp have user browse for folder
The folder selection is in a text box, the folder path is passed into an action class
The folder path is placed into a teradata table
A script is called to query the table for the source path and target path (pre-determined) and make the copy
Due Dilligence: So far I have tried the <input type="file", which selects a file, not a folder. Also, the file path is not passed through due to security reasons. I have read other possible solutions but none work.
Question: Are sevlets a viable solution, and if so, how do I create one?
I'm going to go with no. There are several reasons for this.
A Java Enterprise Edition application (be it a Servlet or Java Server Page) is not supposed to access the file system directly.
It is inherently unsafe to expose internal infrastructure through an external website.
I think you need to break it up a bit more.
Save a list of shares the server has access to in a data store of some sort, like a new teradata table or for a quick proof of concept plain text file (if you're on Linux you can use the output of something like showmount -e localhost).
Let the user pick the src share from a combobox or something similar.
Continue from your step 2.
This gives you two immediately obviously advantages, which may or may not be relevant.
You can use the system without having access to the physical shares.
You can add metadata (like description or aliases).
I am developing an application that stores data dynamically and displays it as it is generated or uploaded. But the problem is when I am uploading any image then it should be displayed. It's path is also defined perfectly but until I refresh the whole application in eclipse it remains unchanged.
So to update application, I have to refresh it.
My application is Java based and is useing JSP and Servlet. Is there any code that can be used to update or refresh the application?
Right now I am doing it by right click -> refresh or directly F5 it.
Or suppose I want to create directory then where will I have to create it that will be accesses easily without refresh.
When I'll host my application then which place is better for to store data?
I know it's outside the web app but any specific place? Because there is no drive so how can I create or make directory and access that one in my code.
A solution to this is a design pattern called Observer. You should read about it.
Is there any code that can be used to update or refresh the application?
Right now I am doing it by right click -> refresh or directly F5 it.
I think you need to look into the workspace re-fresh option in Eclipse ( was made available from Eclipse version 3.7.x ). You can enable it in Preferences > General > Workspace and select Refresh on access or as per need you can change to whatever setting you require.
When I ll host my application then which place is better for to store data ? I know it's outside the web app but any specific place ? Because there is no drive so how can I create or make directory and access that one in my code.
The location of static content is best if placed outside of the scope of the project itself. Maybe some other directory on your server ( be it any directory ).
I can share what I have normally seen as a trend in different applications that I have personally worked on. We had a separate tomcat server that just hosted all static content ( all media ) and our web application accessed that static-server (as it was named) within a secured network. All hits to static content could only be made via our application server and thus all direct hits were either rejected or not entertained at all.
Edit
I would suggest using a an absolute path
and on windows environment
you will HAVE to use the drive lletter
and specify the path as X:\some\path
if you want to hide your letter drive
due to obvious security reason
I can suggest another idea
Idea 1 : Make a separate drive (lets call it drive F) and make a folder with the name of "static". Then in your application , you just forward all requests to file uploads using this path ( F:\static......) . I would advise loading the directory name from a property file instead of hard-coding it in your code
Idea 2 : If you cant make a separate drive, then make a directory namely "static" on the root of same drive ( C:\static ) . Make a user group and give him read/write permissions on this drive and revoke writing permissions from this user on all other drives ( just in case someone messes up with this user-group). Next do the same thing as above i.e specify this path into your application. One thing is that you would have to run your application with that specific user-group to ensure that the permissions security you have setup can be implemented.
Best practice is to store such data outside the webapp's tree to avoid issues on redeployment.
You can't serve these files directly though, commonly it's done by creating a servlet mapped to eg. images/*; that parse the request URL (eg ) and based on that url fetches and serves. You need to set the correct MIME type for the output, and streamcopy the requested file to the servlet's output.
A well explained example of such a servlet can be found on BalusC's blog.
I have developed a command-line (read: no GUI) Java application which crunches through numbers based on a given dataset and a series of parameters; and spits out a series of HTML files as resultant reports. These reports hold a large amount of data in tables, so in order to give the users a easy and quick overview of the results, I utilized the JUNG2 library and created a nice graph.
Here's where it gets interesting; since I would like the graph to be interactive it should be deployed after the application has run and files are generated, whenever the user wants to view the reports. I decided to go with an applet based deployment, however I am not too happy with the current setup due to the following reasons:
I want to make the software as simple to use as possible (my users won't be tech-savvy, and even tech-intimidated in most cases). I would really like to distribute one JAR only, which forced me to put the applet with everything else it needs in a package in the same JAR as the main application.
The applet and the main application need to communicate the results, so I create a xML-based report which is used to hold information. As long as the files are on a local machine and are not moved around it all works fine. Unfortunately I also need the files to be moved around. A user should be able to take the "results" folder to a USB stick, go anywhere plug the stick to another computer and be able to use the report as he/she likes.
For the time being the applets are implemented with the following html code:
<applet code="package.myapp.visualization.GraphApplet.class"
codebase="file:/home/user/myApp"
archive="myApp-0.2.6-r28.jar"
width="750" height="750">
<param name=input value="results/test_name/results.fxml">
</applet>
As you can see this applet will not work if the parent folder is moved to another location.
As far as I know I have a couple of alternatives:
a) Change codebase to point to an URL on our webserver where I could put the jar file. This however creates the problem with permissions, as the applet will not be able to read the results file. Alternative is to upload the results file to the server when the user wants to visualize the graph, although I am not sure if that's a good option due to server security and also if it could be made so that upload happens automatically without bothering the user.
b) I can use a relative path on the codebase attribute, but then the whole folder hierarchy needs to be intact upon copy. This could be a last resort, if I cant come up with a better way to do it.
c) change the deployment method (would like to avoid this alternative to not spend more time on the development phase)
Any ideas? Am I missing something? How could I tackle this problem?
Thanks,
I'm not sure I entirely understand your use-case, but from what I do understand, I would suggest this:
Dump the applet for an application launched using Java Web Start. Have the JNLP file declare a file association for the fxml file type. When the user double clicks an fxml file, it will be passed as an argument to the main(String[]) of the JWS application.
A sand-boxed JWS application can gain access to resources on the local file system using the JNLP API. Here is my demo. of the JNLP API file services.