Skip to content
This repository has been archived by the owner on Mar 18, 2024. It is now read-only.

Demo Application

Jump to bottom
Mordechai Meisels edited this page Mar 18, 2024 · 9 revisions

To run the demo app, first download the latest version of update4j, then run this command:

java -jar update4j-<version>.jar --remote https://s3.amazonaws.com/docs.update4j.org/demo/setup.xml

Replace <version> with the real version string.

What's happening?

This application has an interesting twist that regular deployed apps would usually not do. Namely, it uses 2 bootstraps where the first is merely a setup to get the "real" — intermediate — bootstrap to run. It just downloads everything required for the bootstrap. When it launches, it starts the second bootstrap; that's where you see the visual launcher.

Once the setup has run and downloaded, subsequent runs can also be started:

java -cp "update4j-<version>.jar:bootstrap/*" org.update4j.Bootstrap

replace : with ; for Windows.

I did this for a few reasons:

  1. See it running with a single command; no setups required. This is optimal for a demo app, but real applications should have no issue with running an install software to place required bootstrap files in place.
  2. Download platform dependent JavaFX modules, but only for that operating system.
  3. Updating bootstrap files are now much easier. It is now safe to overwrite files running in the second bootstrap just like any other business application. Otherwise, bootstrap updates require to leave the old files behind and download new files with different filenames etc.
  4. To demonstrate how both the default bootstrap (used in the setup) and a custom bootstrap work.
  5. Just to demonstrate that you can stack delegates one on top of the other. You can figure out many more uses for this.

Running the first command will start the default bootstrap, since there aren't anything else in the classpath. It reads the config from https://s3.amazonaws.com/docs.update4j.org/demo/setup.xml which lists 4 JavaFX files (with a different file for each OS) and a bootstrap file. Then when launched, it uses the default launcher which reads a main class name from the property default.launcher.main.class which was set to org.update4j.Bootstrap. This means it points to the class that will look for delegates. But this time around it will not start the default bootstrap, since the new bootstrap file was already dynamically augmented to the classpath and it has a higher version() number.

In a sane environment you should never do this (point back to org.update4j.Bootstrap) but instead list the launcher class name in Configuration.Builder::launcher

The second bootstrap then reads a different config from https://s3.amazonaws.com/docs.update4j.org/demo/business/config.xml which lists the business application plus a few popular JavaFX libraries.

You can read the source code of the bootstrap and the business applications at update4j/demo

Clone this wiki locally