GetDown throws RuntimeException in setting the proxy settings

[Patrick Wachsmuth]

I've used GetDown from the getdown-maven-plugin from joxley with the GetDown-Version 1.2.

In case the enduser has a company laptop withou admin rights and the userdir is on a share.

When the update is executed i will get the follwing exception in the launcher.log and the update is not happend.

2014/07/01 17:35:55:699 INFO e.a: ------------------ VM Info ------------------

2014/07/01 17:35:55:715 INFO e.a: -- OS Name: Windows 7

2014/07/01 17:35:55:715 INFO e.a: -- OS Arch: x86

2014/07/01 17:35:55:715 INFO e.a: -- OS Vers: 6.1

2014/07/01 17:35:55:715 INFO e.a: -- Java Vers: 1.7.0_25

2014/07/01 17:35:55:715 INFO e.a: -- Java Home: C:\Users\TMC27161\Documents\ALR\eAlarmScope\eAP Project V 0.9_NEW\jar Version\jre7

2014/07/01 17:35:55:715 INFO e.a: -- User Name: TMC27161

2014/07/01 17:35:55:715 INFO e.a: -- User Home: \\sg1005p-v1\TMC27161$

2014/07/01 17:35:55:715 INFO e.a: -- Cur dir: C:\Users\TMC27161\Documents\ALR\eAlarmScope\eAP Project V 0.9_NEW\jar Version

2014/07/01 17:35:55:715 INFO e.a: ---------------------------------------------

2014/07/01 17:35:55:731 INFO e.a: Failed to find proxy settings in Windows registry [error=java.lang.UnsatisfiedLinkError: no jRegistryKey in java.library.path]

2014/07/01 17:35:55:731 INFO e.a: Checking whether we need to use a proxy...

2014/07/01 17:35:55:731 INFO e.a: Dropping status 'm.detecting_proxy'.

2014/07/01 17:35:55:731 WARNING e.a: run() failed.

java.lang.RuntimeException: Invalid appbase 'null'.

at com.threerings.getdown.data.Application.getConfigResource(Unknown Source)

at com.threerings.getdown.launcher.Getdown.detectProxy(Unknown Source)

at com.threerings.getdown.launcher.Getdown.run(Unknown Source)

2014/07/01 17:35:55:731 INFO e.a: Dropping status 'm.init_error|~Invalid appbase 'null'.|'.

Has someone a solution for that problem?

thx

[Patrick Wachsmuth]

When i used my computer it works perfect, so i can't determinate where the bug is.

[Michael Bayne]

On Fri, Jul 4, 2014 at 5:02 AM, Patrick Wachsmuth <ebc.f...@gmail.com> wrote:

2014/07/01 17:35:55:731 WARNING e.a: run() failed.

java.lang.RuntimeException: Invalid appbase 'null'.

at com.threerings.getdown.data.Application.getConfigResource(Unknown Source)

at com.threerings.getdown.launcher.Getdown.detectProxy(Unknown Source)

at com.threerings.getdown.launcher.Getdown.run(Unknown Source)

2014/07/01 17:35:55:731 INFO e.a: Dropping status 'm.init_error|~Invalid appbase 'null'.|'.

This is a red herring. It just happens to be during proxy configuration that Getdown first reads the getdown.txt file and looks up the appbase. I should improve this error message, but the root cause is likely that you have no getdown.txt file in the appdir and that's causing the failure. Naturally, that may be because the appdir is pointing to the wrong place instead. Or it's possible that you have a getdown.txt file but it doesn't contain an appbase config entry, but that's less likely.

-- m...@samskivert.com

[Patrick Wachsmuth]

Thx for your response. I have a getdown.txt in the directory and the appbase is also configured. It's possible that has side-effect with the system property of the proxy? In our Application we set the proxy settings also in the code before executing the update.

[Michael Bayne]

On Tue, Jul 8, 2014 at 12:40 AM, Patrick Wachsmuth <ebc.f...@gmail.com> wrote:

Thx for your response. I have a getdown.txt in the directory and the appbase is also configured. It's possible that has side-effect with the system property of the proxy? In our Application we set the proxy settings also in the code before executing the update.

The error you showed has nothing to do with the proxy. The error you showed results when either a) Getdown cannot find the getdown.txt file in the appdir, or b) it read the getdown.txt file and it contained no appbase configuration entry.

So one of those two things is happening. 

If you can use the latest Getdown (built from source), it will provide a better error message with more information on what might be going wrong. Maybe you think the appdir is set to a particular directory but it's not. Look at the existing log you sent, Getdown's current working directory is:

C:\Users\TMC27161\Documents\ALR\eAlarmScope\eAP Project V 0.9_NEW\jar Version

is that what you expect? When you're running Getdown what appdir are you passing? Is it relative to that directory? Or is that the correct appdir and you're passing . for the appdir?

-- m...@samskivert.com

[Patrick Wachsmuth]

i checked out the new source code and build my client. we will test it next week with our customer. We will inform you about our results.

[Patrick Wachsmuth]

We have tested today with our customer. You're correct with the answer, that the getdown.txt is missing.

But when we copied the getdown.txt the client will download the update. But because of some security restriction in his network, the jar cannot be downloaded successfully and the client installation will be corrupted.

Have you also such a problem or a workaround for this?

It is correct, that only the jar will be downloaded with getdown?

[Michael Bayne]

On Mon, Jul 14, 2014 at 6:06 AM, Patrick Wachsmuth <ebc.f...@gmail.com> wrote:

But because of some security restriction in his network, the jar cannot be downloaded successfully and the client installation will be corrupted.

Have you also such a problem or a workaround for this?

Getdown should detect that the jar is corrupted and try to download it again the next time it is run. It will keep attempting to redownload the client until it gets a jar file that matches the MD5 hash in the digest.txt.

However, if the security restriction is in effect every time, then it will just fail over and over again. I don't know what this security restriction is, so I have no idea how to work around it.

It is correct, that only the jar will be downloaded with getdown?

I'm not sure what you mean by this question. Can you clarify?

-- m...@samskivert.com

[Patrick Wachsmuth]

It is correct, that only the jar will be downloaded with getdown?

I'm not sure what you mean by this question. Can you clarify?

I mean, that only the jar from the server will be downloaded, so we can configure the firwall that this is passed the jar.file.

[Michael Bayne]

On Mon, Jul 14, 2014 at 8:03 AM, Patrick Wachsmuth <ebc.f...@gmail.com> wrote:

I mean, that only the jar from the server will be downloaded, so we can configure the firwall that this is passed the jar.file.

Getdown downloads the getdown.txt file, digest.txt file and every jar file listed in the getdown.txt file in code and resource entries. If you have to configure specific URLs to be allowed, you'll want something like:

http://appbaseurl/getdown.txt

http://appbaseurl/digest.txt

http://appbaseurl/jar1.jar

http://appbaseurl/jar2.jar

...

-- m...@samskivert.com