Dynamic appbase

[vitalidze]

Hi

First of all, thank you very much for a great project. We are targeting it as a replacement of current web start solution.

Our "boxed" app is distributed as an all-in-one server app. Then it runs some HTTP server hosting JNLP file and all jars from that JNLP file. Then on workstations the client for the server app is installed through web start with dynamic set up of the application base depending on the current server's IP address/hostname. Please let me know how this can be achieved with getdown?

[gravelld]

You can override the domain for the appbase by specifying the system property -Dappbase_domain. See the code in Application.replaceDomain.

Unfortunately this does not appear like it will work for all cases as it assumes HTTP rather than also allowing HTTPS.

[samskivert]

On Wed, Feb 8, 2017 at 4:37 AM, Dan Gravell [email protected] wrote:

You can override the domain for the appbase by specifying the system property -Dappbase_domain. See the code in Application.replaceDomain.

Unfortunately this does not appear like it will work for all cases as it assumes HTTP rather than also allowing HTTPS.

I just added support for an appbase_override system property which allows you to completely override the appbase with a new URL. However, I would still consider having this all-in-one server just generate the correct getdown.txt and digest files at install time as that's not tremendously complex and it avoids pushing complexity out to the installer, which must then ensure that the app is always started with this appropriate system property in place.

-- [email protected]

[gravelld]

Thanks for this, sounds good. ~~How often are releases cut?~~ looks like that's already released!

Regarding getdown.txt and simply writing that... a couple of use cases for -Dappbase_domain:

• When testing update on test hosts
• Allowing an installation to be on a different "track" of updates. E.g. beta testers.

And you can't simply edit getdown.txt to do this as required because that violates the digest, and then the getdown.txt is replaced from the appbase (IIRC).

[tschulte]

I use https://github.com/tschulte/gradle-jnlp-plugin/blob/1aad76fe9be351d754b6a98624640f479abbe52d/jnlp-servlet/src/main/java/de/gliderpilot/jnlp/servlet/JnlpFileFilter.java to replace $$codebase in the getdown.txt with the real codebase.

And I created another filter to replace the digest lines for getdown.txt, digest.txt and digest2.txt in the digest files with the changed digests.

[borgogelli]

Hello guys. The discussion here is not very clear, nor the solution. Do I have to use -Dappbase_domain or -Dappbase_override ? Where I have to use that argument ? is it in the jvmarg statement of getdown.txt ? Thank you in advance

[samskivert]

If you want a dynamic appbase, you have two choices.

If only the domain of your appbase changes, you can use -Dappbase_domain=newdomain.com and that will change an appbase of, for example: https://olddomain.com/myapp/ to https://newdomain.com/myapp/

If you want to change the entire URL then you can pass -Dappbase_override=https://newdomain.com/newapp/. This allows you to change both the domain and the path, which may be better or worse depending on your use case.

As to where to apply these system properties, they cannot go into the getdown.txt file, which is why I don't recommend using this approach. These have to be passed to the JVM that runs Getdown. So when you create an installer that eventually runs a command like:

java -jar getdown.jar approotdir

You have to include the system property there:

java -Dappbase_override=... -jar getdown.jar approotdir

Because the appbase is used to download the getdown.txt file, so the overridden appbase URL must be known before Getdown tries to download the getdown.txt file. Indeed, the getdown.txt file will (must) contain the original appbase because the precise text of the getdown.txt file must match its cryptographic hash in the digest.txt file.

This whole appbase override mechanism exists so that a single getdown.txt file can be served from multiple web servers without having to create a custom getdown.txt and digest.txt for each webserver that hosts the app.

Again, my recommendation is to create a custom getdown.txt and digest.txt for each webserver that hosts the app (possibly on the fly via a servlet or just pre-generate them, depending on your use case). But that doesn't work for everyone, so we added this somewhat complex additional mechanism to allow the appbase to be overridden.

[samskivert]

My example is not quite accurate. Looking at the code that handles appbase_domain, you have to pass the entire URL prefix. So:

-Dappbase_domain=https://newdomain.com

and it will replace everything up to the first / following the domain name in the original appbase with what you supply. The code for this is a little wonky (it assumes http), so I'm fixing that now to at least work with https URLs since those are fairly ubiquitous these days.

[Adrodoc]

Is there a best practice on how to handle system properties like java.naming.provider.url that should point to the server where the app is deployed? Or is there a supported way for the launched app to know it's server?

[ascertrobw]

So I have an issue/query around this area.

Our WebStart model which we are replacing already used Servlet replacement text, so adjusting this for getdown.txt is trivial:

appbase = ${__url.path}

(we use an Apache-like variable substitution model)

But this does throw up a couple of things, which maybe reflects a lack in our understanding on GetDown:

• the digest generator does not like an invalid URL for appbase, which seems to mean we need 2 different getdown.txt versions: one for live as above; and one with a fixed/static URL for build when we are generating digests. That's a bit of a pain and doesn't feel quite right

• the checksum on getdown.txt will always fail. Not a biggie really, since the file is always going to be pulled down anyway so perhaps that is just normal.

[ascertrobw]

OK - so it looks like I can get around the Digester issue with the -Dappbase_override property.

Without this I get:

c:\mnt\Data>java -cp getdown-core.jar com.threerings.getdown.tools.Digester vtmp
Generating digest file 'vtmp\digest.txt'...
Exception in thread "main" java.io.IOException: m.invalid_appbase|~${__url.path}
        at com.threerings.getdown.data.Application.init(Application.java:568)
        at com.threerings.getdown.tools.Digester.createDigest(Digester.java:78)
        at com.threerings.getdown.tools.Digester.createDigests(Digester.java:60)
        at com.threerings.getdown.tools.Digester.main(Digester.java:42)
Caused by: java.net.MalformedURLException: no protocol: ${__url.path}/
        at java.net.URL.<init>(URL.java:593)
        at java.net.URL.<init>(URL.java:490)
        at java.net.URL.<init>(URL.java:439)
        at com.threerings.getdown.data.Application.createVAppBase(Application.java:1385)
        at com.threerings.getdown.data.Application.init(Application.java:565)
        ... 3 more

But using the appbase_override it is happy:

c:\mnt\Data>java -Dappbase_override=http://localhost:8084/tas/dsv/ascert/vtmp -cp getdown-core.jar com.threerings.getdown.tools.Digester vtmp 
Generating digest file 'vtmp\digest.txt'...
Generating digest file 'vtmp\digest2.txt'...

Still get a checksum error at launchtime on getdown.txt - but I think I can live with that for now