I am using the java properties file construct. At the beginning I read it to populate a dialog, but I also give the users the ability to change the values in the dialog and click save. This causes me to call the setProperty method of the properties file. Now, since this webapp can exist over multiple browsers, all changing the same file, I want to be able to "lock" the properties file whenever I am in the "save" method. How can I accomplish this? I've seen similar questions refering to FileLock, but I am unsure if this applies to the properties file construct. Is each "setProperty" a different write?
Thanks!
setProperty merely updates the set of properties, it does not write the file. You have to call the store(OutputStream out, String header) method to actually write out the file to disk, and that is the time where you'll have to "lock" the file.
You can use FileLock to prevent multiple users from writing to the file at the same time, however, each time your user wants to save, you will need to reload the property file from disk, change the property, and write the file back again, all without releasing the file lock, to make sure no stale data is saved.
Related
I am building a basic paint application and have implemented Open and Save functionality, however, I would like to add in "Save As." Essentially, Save As would always make use of JFileChooser, but Save would automatically write to file if a file already exists and is currently being edited.
With that said, what strategies can I invoke to streamline this process? Obviously, Save As is already complete per the implementation of the Save feature I have already written (I apologize if that wording is confusing). However, in order to make the "Save" feature function as I intend it to, I believe I would need a way to keep track of whether or not the file exists and is currently being edited.
So what is a good way to keep track of whether or not a file exists and is currently loaded--and if it is, the Save function will write without JFileChooser, but if it isn't, it will launch the Save As functionality.
For what its worth, the Save feature, as highlighted, should apply when the Open dialog is called, so I could keep track of this somehow. I am also Opening bufferedimages and laying them as TexturePaint over my shape objects. So when the above happens is when I want the Save dialog to work as a "normal" save function, so that is another feature to take into consideration.
However, I would really like to learn about some good strategies to accomplish this in a more generic sense. Thus far, I have come up empty handed.
You can add a field to the object that stores the file name, and it's only set when you Open a file, or when you use Save As. Then, if the file name is null, clicking on Save actually calls Save As's code instead.
I have written a JSP and a class that takes a file upload and stores it locally on the server. After saving the file, the uploaded file is to be processed. The required method calls should not be called statically for the file storage.
Not like this:
storefile (file);
MyPostprocessingManager pm = new MyPostprocessingManager(file);
pm.createThumbs();
pm.doFooBarWithTheFile();
This coupling is too tight.
The methods should be started on a kind of "event". So after uploading a file is an event fired and informed the appropriate classes who will carry out further processing.
The whole fails only on the fact that I do not know where and how I need to register the appropriate listener. In most instances this is already done in a main class. But I can not do so since I do not have a central starting point.
I am fully wrong track? Maybe one of you has another idea?
Thanks and greetings,
Ben
I have a properties file that i create manualy.
I can to get the propert in the file by getProperty() function, but I can't change it!
I try with setProperty() function, but the file isn't changed.
can u help me?
thanks!
zipi
You need to write the properties file again using store() (of which there are two variants). The setProperty() method changes the value of property stored in memory, not the value of the property in the file the properties were loaded from.
For further reading see the Properties Tutorial.
SetProperty() will only set the property during the runtime. It will not go and override your file property. It wont modify your file.
Did you try to call something like
prop.store(new FileOutputStream("config.properties"), null);after calling prop.setProperty method? Because it's the way you flush changes to file.
Without calling store changes are visible only in application memory.
The goal with my program is to have it save when closed, and reloaded when opened.
I have a driver (which contains all of the graphics) and I want it to create and save a file. I've seen numerous tutorials on the internet, but what they fail to explain is how to correctly implement this system in an actual program.
Do I create the OutputStrema in my main method? Do I need to check if a file has been created and if not create one, and if so read from it? How do I accomplish all of this? Should I have a WindowListener for quitting so that it can save all of the data?
Thanks
Yes, a WindowListener sounds like a good idea. One way to save the state of a program is to use Properties. Please have a look at the tutorial linked to above. I'm not sure what to recommend for your "graphics". Please tell us more details about just what you mean here.
Edit
Do I create the OutputStrema in my main method?
you're question re creating the OutputStream in the main method is asking about program structure that we know nothing about. My gut tells me that i wouldn't create anything like this in the main method, even if the JFrame is created there (or in a static method called from main). The OutputStream would be created in the class that implements the WindowListener, and this can be its own stand alone class. You want to make the main method as small as possible.
Do I need to check if a file has been created and if not create one, and if so read from it?
Possibly. This question revolves around what you're going to do with the stored information once created. Perhaps you'll search for it and read it on program start up? I don't know as it all depends on your needs, something you'll have to figure out.
How do I accomplish all of this? Should I have a WindowListener for quitting so that it can save all of the data?
If this is a Swing application, then yes, a WindowListener would help you control your application's closing.
Do I create the OutputStrema in my main method?
It would be better to create the stream at the point where you are saving the state.
When my program runs it is going to take in the saved data file with its ObjectInputStream. Do I put the code to accomplish this in my Main method?
Sounds like a good choice. Basically, you need to do this before you attempt to do something that needs that data. Anything that achieves this will work (though doing it using static initialization is a bad idea ...)
Do I need to check if a file has been created and if not create one, and if so read from it?
This question is confusing writing the state file and reading it. They occur at different points in the lifecycle, and use different code to do the task.
There is no point checking to see if a save file exists before creating one ... unless you propose to rename the existing save file.
Conversely, if a save file doesn't exist when you start the application, then the constructor that attempts to open it will throw a FileNotFoundException. Just catch the exception and skip the code that reads the saved state.
... if there has not been a file created yet, will this cause an error?
Yes. A FileNotFoundException; see above. So your code has to deal with that, or test to see if the file exists before attempting to open in; see File.exists() and related methods.
Should I have a WindowListener for quitting so that it can save all of the data?
That sounds like part of the solution. (But what about the case where the program crashes or is killed? Do you want to save state in those cases ... or not?)
A couple of things to beware of:
Many GUI-related objects do not implement Serializable, and therefore cannot be saved using an ObjectOutputStream. Threads, streams, sockets and a few other things can't be serialized either.
When you save instances of classes using ObjectOutputStream, change the classes or their names, and then attempt to reload them using ObjectInputStream, you are liable to run into trouble with saved instances not matching the new versions of the classes. If you have to be able to read that serialized state you are in trouble.
I have an XML file that has certain properties and mappings defined in it. These properties change very rarely. I don't want to reload and evaluate the properties/mappings every time I call use my jar file. Is there any way I can pre-compile my XML file into an object, so that the XML values get stored in the object? Whenever I change the XML file, if ever, I just need to recompile it once.
You could just use a Java file to define these properties and mappings to begin with. No need to mess with XML if you aren't going to take advantage of loading changes to it without recompiling.
After you've read your XML data into an object you could write it to a file using Serialization and check next time, before you load your XML source whether it has been changed (by comparing their timestamps). In cases the XML source hasn't changed you could simply restore the configuration object by de-serialization from the file system.
Couple a questions that might help you find an approach are:
How big is your XML file?
How long does it take for you to parse it and turn it into an object?
Is it prohibitive to have this process (load + parse + convert to object) every time your library loads?
Spring does exactly this; you configure the context with XML and when you boot your application it loads, parses and creates the objects according to your configuration. I've been dealing with big XML files in Spring and I can say it's pretty fast - and considering it's only done once, at boot, it's hardly ever a problem.
Spring also has an alternative in which your configuration is actual code, but I'm guessing you want to stick to XML configuration.
Another approach is having a tool to read the XML, convert it to an object and then storing this object to a file using object serialization. You can then load this file as a de-serialized object.
This might not be regarded as the best practice in the world... but if you're wanting to do this outside of any particular framework, you can always just use plain vanilla Java serialization. It's exactly what you're talking about... storing an object to disk (or whatever) and restoring it to memory later. Check out this tutorial if the subject is unfamiliar.
You can read the data from XML into a java object and then serialize that object. You should even be able to have your object check the timestamp of the xml file and automatically reread it when it changes.