New Install Problem : Category: Invalid Argument error

[bspolarich]

I'm experimenting with the demo to see how well the product works.

I've installed on Windows XP Pro SP1 w/ Firebird. I've loaded the CRM solution, and I'm able to connect to the admin interface and verify that it has been released. However when I connect to the client page (http://localhost:8080/) to launch the application, I receive the following error:

CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\bspolarich.NEPHROS\Local Settings\Temporary Internet Files\Content.IE5\SKD17E8Y\servoy_client[1].jnlp]

at com.sun.javaws.Main.main(Unknown Source)


What am I doing wrong? I'm sure this is pilot error...I just want to see what the sample application actually looks like from a client perspective.

[bspolarich]

Clearing the browser cache and/or setting the Sun JVM to be my browser default did the trick.

[Jan Aleman]

It's a common Microsoft Internet Explorer problem (although it could also be a Windows problem). When you have many files in your cache it gets confused by itself and can't locate downloaded files anymore. A solution is to set your cache size lower.

[Robert Huber]

Hi

First of all a happy new year to all of you!

It's a common Microsoft Internet Explorer problem (although it could also be a Windows problem). When you have many files in your cache it gets confused by itself and can't locate downloaded files anymore. A solution is to set your cache size lower.

We have this Problem now as we have introduced our Software at customer site. It is only Windows related, Macs don't have it. It's on Windows 7. The problem is reproducible. I install the Application, and, after a Machine restart, I get following error message. I must assume this is a widely known problem on Windows side.

Java 1.6.0_26
Servoy 5.2.10

Best regards, Robert

[Jan Aleman]

Wow resurrecting a 8 year old thread and quoting me twice.

It sounds like a r/w access issue to me. Does the user launching Servoy have r/w access to that directory?

[Robert Huber]

HI Jan

Corrected, so I quote you once as expected Up to today, I never had to deal with an access right in a cache directory, that should be handled by the app maintaining the cache. And, why does it work the first time if it would be an access right problem? Only always after a machine restart the problem occurs.

Wow resurrecting a 8 year old thread and quoting me twice.

It sounds like a r/w access issue to me. Does the user launching Servoy have r/w access to that directory?

Regards,

[Jan Aleman]

Up to today, I never had to deal with an access right in a cache directory, that should be handled by the app maintaining the cache

Neither have I seen any access right issues: other than those caused my incorrectly configured Windows systems. Nevertheless I'm trying to help. If your statement is that it should be handled by the app (the app should magically fix problems unknown to the app?) you allow little room for help.

[Robert Huber]

Hi Jan

I like to leave all room open for your help and appreciate it very much! I worked all the afternoon trying to fix the problem with another guy from customers IT department and found till this evening the following:
- There was a <app-name>.jnlp file in the above mentioned cache directory of IE (version 9) (to my surprise).
After deleting that .jnlp file, i. e. the cache of IE and removing the checkbox for: Delete browsing history on exit (on the Internet Options > General tab), I could start the application again.That was a surprise and only just the opposite one expects, at least to me. We couldn't figure out how and when this file comes to this place and why deleting it solves the problem.

As we where not completely convinced if that was really the solution to the problem, we tried downloading the app from the Servoy Application Server with Firefox. The problem seems to be gone completely away. We had no problems any more.

Temporary conclusion: At the least there is a strange default behavior of IE downloading apps, or one has to carefully set some options to avoid problems.

For now, we go with Firefox and see what happens the next days/weeks.

Best regards, Robert

[Robert Huber]

Hi All

Problem reappeared. After an install on a Windows 7 machine with Java 1.6.0_26, it's a matter of hours and the startup of our application via desktop icon breaks.
The installation:
- The computer is a fresh install of only Windows 7, Firefox and Java 1.6.0_26
- Deleting any files with Java Control Panel (Applications, Resources, ...) (first time it was empty of course)
- Download of our application from Servoy Application Server - leaving a desktop icon to start the application

After some hours, up to now about 2 days the most, the application can't be started any more with the desktop icon with following error:

Code: Select all

R207-01
Ausnahme:
CouldNotLoadArgumentException[ Angegebene Datei/URL konnte nicht geladen werden: C:\Users\argentonrebekka\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\36\321bc1a4- 2e8784f1]
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Gekapselte Ausnahme:
java.io.FileNotFoundException: C:\Users\argentonrebekka\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\36\321bc1a4- 2e8784f1 (Das System kann die angegebene Datei nicht finden)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

What we found is that the file referenced as Target:
C:\Windows\SysWOW64\javaws.exe -localfile "C:\Users\Administrator\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\35\59d1c063-40a604eb"
in the Properties > Shortcut of the desktop icon points to a file, i. e. in this example the file 59d1c063-40a604eb (the xml file containing the startup up info and parameters), that does not exist any more at this path.

We have no idea why this file is at some point of time not there any more. How cold it have gone? For sure there is no person doing that manually, so I assume it must be some "process" doing that

Anyone having an idea what's going on here?

Thanks and regards,

PS: This happens on more than 10 different Windows 7 machines, so it is not a single machine effect.

[tgs]

Hi Robert,

I do have more than 10 Servoy Smart Client customers on Win 7, but never such an issue like you.

On my Win 7 System the target location of the Servoy App shortcut is very similar to yours. But you have postet the location at:

...Deployment\cache\6.0\35\59d1c063-40a604eb....

and the error output is:

...Deployment\cache\6.0\36\321bc1a4- 2e8784f1....

This are two different locations!
The only in short I can imagine is the setting of the Firefox preferences that could occur the problem. On close Firefox you can delete all browser cache. I had to load the application every time again, after closing Firefox with the deleting cache settings.

Regards

[Robert Huber]

Hi Thomas

Thanks for your reply.

Sorry if I confused with the example. There are different because the code one is only an example.

Immediately after installing the path/filename in the desktop icon (link) IS the same as the one in the cache. But after some hours or couple of hours, they are different. After 2 days of trying to figure out what's going on, that's the only real fact we have.
Question remains: Who does change the file in the cache? Is it the Java Web Start mechanism which checks if any changes happened on the application server and creates a new cached xml file with another name and the desktop icon can't (doesn't) follow?

Have you exactly the same configuration with Servoy and Java versions?

Regards,

[tgs]

Currently the configuration is Servoy 6 and java 1.6_29 on Mac/Win (1.6_26 on Linux), but 5.2.10/11 and 1.6_26 (Win/Mac clients) worked also in the past.
The servermachine is a Mac and a Linux/Debian. I don't use Win Servers, but this should be not the problem.

Regards

[Robert Huber]

Hi Thomas

Currently the configuration is Servoy 6 and java 1.6_29 on Mac/Win (1.6_26 on Linux), but 5.2.10/11 and 1.6_26 (Win/Mac clients) worked also in the past.
The servermachine is a Mac and a Linux/Debian. I don't use Win Servers, but this should be not the problem.

Regards

The combination OS/Java makes for sure a difference. We never had this problem using a Mac OS X Server 10.6.x with any version of Java 1.6.0_x.

With the combination Windows Server 2008 R2/Java 1.6.0_26 as server and Windows 7/Java 1.6.0_26 as client, we definitely have this problem, I don't joke, although I may be could need one after these days (and nights) trying to solve the problem and with the heat in the neck, as of next monday about 150 teachers have to enter their students marks on the application.

We found following description which fits very nicely our situation, but it says should be fixed since Java 1.6.0_14, and we are with Java 1.6.0_26.

http://bugs.sun.com/view_bug.do?bug_id=6809125

Anyone having a Windows Server 2008 R2 (no SP's installed), Windows 7 and Java 1.6.0_26 installation to comment on it?

Thanks very much for any hint and regards,

PS: As far as I understand it doesn't seem to exist a workaround to try for the bug described on the above mentioned URL?

[Harjo]

Hi Robert, are the PC's there member of a domain?
maybe there are some rules/policies that clean up the temp java cache, after a while?? or something like that...

And what happens if you start the client than by URL: http://yourserver:8080/servoy-client... ... ution.jnlp?

We have multiple 2008 servers and mixed windows XP & 7 clients all Java 1.6 (from what older to the latest Java 1.6) So this should'nt be an issue.

[Robert Huber]

Hi Harjo

Hi Robert, are the PC's there member of a domain?
maybe there are some rules/policies that clean up the temp java cache, after a while?? or something like that...

Some are in domain, but we installed 4 machines fresh with only Windows 7, Java 1.6.0_26, and Firefox. nothing else.

And what happens if you start the client than by URL: http://yourserver:8080/servoy-client... ... ution.jnlp?

We have multiple 2008 servers and mixed windows XP & 7 clients all Java 1.6 (from what older to the latest Java 1.6) So this should'nt be an issue.

I'll try that with starting per URL. What exact Java version are you running? We have 1.6.0_26.

Thanks and regards,