Basic issue of understanding #164
Comments
Are you saying that your configuration might contain file references that are older than the current version? Why would you do so? |
Thanks for the swift response. In case a client would be on a new installation, and have to perform some incremental (and sequentially dependant) updates, I would like to keep the old update files and have them available (and then of course delete the old update files locally). |
So that's the other way around, the configuration has some new files but not all of them changed over the last update, correct? Update4j supports this out of the box, it will only update the changed files. It uses the checksum to check if a file changed. |
I tried what you're talking about previously, and that worked fine for that particular case, but if I were to download e.g. 20 .tar files and unpack & install them, and then delete them (to not take up unnecessary space clientside), update4j would probably download the .tars again with the .update() command, right? Is there a way to circumvent this behavior in some way? |
Right, update4j won't have a way to check this on itself, but if you want to really go ballistic you can provide a custom UpdateHandler and do your own checks in |
The better way is to download the files directly instead of tarballs. Or, perhaps, leave the tar files for references for update4j to check against |
Alright, I guess I'll have to switch my approach to pure files instead in that case. On the same topic, since the updates are in some cases to be sequentially applied (as would be the case when appending text files with other text files) is there any way to stop .update() from downloading all the files at the same time, and instead only download a set of files and then trigger an install? Or would this perhaps also have to include modding the UpdateHandler? |
Can you tell me a concrete example of your problem? |
Apologies if I'm not concrete enough, I guess I lack certain lingo and knowledge in order to explain my problem better. Say that a new client downloads the program, with version 1.0. However, 10 new verisons have succeeded the first version, and we are now on 10.0. I would like this client to download version 2.0, install the update, download version 3.0, install that one... all the way to version 10.0. Is this feasible? |
Completely feasible and works with update4j, but you cannot use the default bootstrap via the CLI. The only thing it cares about is a config file. In your bootstrap, you need to find the correct config and use that to update. You can use your logic to locate the config according to the currently installed version. You might perhaps run a loop to update/install until you reach your desired version. |
Thank you for the answers, I've managed to create a working update implementation. I have one more problem. I'm trying to replace a running .jar and open up an updated instance of it. The first launch() works fine, but once I try to launch my updated application via the .launch() function in my IDE, it throws a java.nio.file.FileSystemException. I'm guessing I have to unload the .jar from the classpath in some way, or kill the process somehow? |
Please post your stack trace and your operating system. Also a bit of background roughly how your bootstrap process works will help |
Windows 10 java.nio.file.FileSystemException: C:\Users\Ante\IdeaProjects\bootstrap\jframe.jar -> C:\Users\Ante\IdeaProjects\ClientUpdateLibraryMode\bootstrap\1072319098167854436.tmp: The process cannot access the file because it is being used by another process
Background: What I would like to do is shut down the business application, and then once the update has been applied, boot the .jar again using .launch(). |
Ok, so to avoid these issues you need to release the file locks. Here's how to do it in update4j: var loader = new DynamicClassLoader()
Thread.currentThread().setContextClassLoader(loader)
config.launch() // first launch
// Later to unlock files from previous launch
loader.close()
// On next launch you can no longer use a closed loader, so create again
var loader2 = new DynamicClassLoader()
Thread.currentThread().setContextClassLoader(loader2)
otherConfig.launch() // second launch |
Hi again, tried the above method, but I seem to be still getting the same error. loader.close() doesn't seem to be doing anything, the .jar just keeps on running (for further context, I am running on Java 8, and the dependency that I had to import for DynamicClassLoader is Clojure 1.8.0). This is my code:
checkForUpdate prompts the user to select a version, which in turn changes the configUrl to the one matching the user's choice. |
You need to close before updating the 2nd time because that's when the file needs to be writable. |
First off, I appreciate your patience and the fact that you keep answering my questions. Secondly, I feel like this is where my lack of programming experience kicks in, so apologies if I fail to grasp some basic concepts. I tried the following code segment with the same result: ` DynamicClassLoader loader = new DynamicClassLoader();
The original application starts twice, but I get the same exception the next time that the loop is ran. I'm a bit unsure of what to do after loader.close() is ran, is it possible to completely shut down the application after doing loader.close(), as that would be optimal? |
So now you were successful to start twice, kudos! Basically, every time the loop runs you need to close the old and create a new loader inside the loop, don't hardcode this, it was just an example. |
The .jar that is picked first just keeps launching infinitely once it's in a loop, trying to do config.update() containing the new .jar just produces the same error as earlier. ` DynamicClassLoader loader = new DynamicClassLoader();
The file still seems to be locked in that case? |
Can you post the full code snippet with the loop and everything? |
That is actually the entire loop, I simply omitted the while loop surrounding it 😄 `
|
I don't see any logic swapping the config to a new version. You just keep updating and launching the same config, at least in the code above what I can tell. |
The checkForUpdate() method prompts the user to select a version and sets the configUrl accordingly: ` private void updatePrompt() throws IOException {
` |
Try returning the config variable in This is Java 101 |
Tried the above, but still got the same error. Thank you for your time, might help someone else with similar issues in the future. |
Hello Mordechaim,
I am a programming novice (at best) and I've been tasked with implementing automatic updates with update4j. I have no idea on how to make update4j ignore files which are older than the downloaded and installed version of the application. Is there any way to do this?
The text was updated successfully, but these errors were encountered: