Servoy Forum

Affected by the same or similar issue on two XP PCs running update 19, but shown in the Java control panel as 17. I realise this may be another problem, but it seems linked to the Java update issue.

These two PCs have been running Servoy successfully since first installation around autumn 2008. Their Java was updated yesterday to 19. This morning, neither PC would start the Servoy application, yet five other PCs which had not updated Java are OK.

I have removed swingbeans.jar and have followed instructions re mixed code (not mode).

I have followed the advice in this thread to remove swingbeans.jar and have restarted the application server.

However, attempting to download a fresh client application from the server to the affected PCs, we see 'Unable to load resource: (http://server:8080/beans/swingbeans.jar?version-id=.....).

What else do I need to do to change the client so that the swingbeans.jar is no longer referenced by the application server code?

Stef wrote:Just tested, Outlook plugin is still working!

Nice!

What else do I need to do to change the client so that the swingbeans.jar is no longer referenced by the application server code?

Did you restart the server and clear client cache before testing?

Yes Marcel: both server restarted and client cache cleared.

Some times a real clean of the webstart cache is needed, if you do it through the java control panel then you must make sure that you also throw away the "Resources" not only the "Application" section.

What error does the calendar bean of marcel generate now? Is there a server where i can connect to?

Marcel: do you sign your beans/plugins with your own certificate?

At the moment it really seems that all jars from core and all the plugins and beans need to be signed and it could be that the have to have the manifest entry: Trusted-Library: true

Further observation. With swingbeans.jar removed from the application server/beans folder, the application behaves as expected when downloaded to my text Mac; and also works when downloaded to the two problematic XP machines once I have removed from the PC Java update 19 using their Add/Remove programs control panel.

Edit: Note: when removing Java update 19, a dialog window reported 'Java update 10' being removed. Is this a symptom of poor quality assurance on Sun's part?

For today our remedial process is to remove Java update 19 from machines affected; and to set Java control panels to 'never update'. We also clean out Java caches: both Resources and Applications; and start over with a fresh download from the server.

Noted, thanks, Johan's 'real clean' approach to clearing the webstart cache.

Richard

At the moment it really seems that all jars from core and all the plugins and beans need to be signed and it could be that the have to have the manifest entry: Trusted-Library: true

Some are signed (when necessary) and some are not.
There are also libraries. Some signed, some not...

We found a solution to avoid users logging in without the components.
-in the onopen method of the solution we use 'plugins.kioskmode.setStatusBarVisible(false)', which is not accepted when a user clicks "Yes" in the warning dialog
-as firstform we made a screen like this:


This forces the user to restart and click "no" in the warning dialog...

have a look: http://www.compeers.com

HTH
Stef

pbakker wrote:In addition to what Johan already said in the previous post:

Sun/Oracle has pushed a change into update 19 of Java 6 that, in our opinion should have been reserved for a major update (Java 7).

The change in update 19 doesn't take into account scenario's Java WebStart scenario's like Servoy's (and many, many other software vendors that use Java WebStart) that use libraries, both signed and unsigned and that can be extended with additional libraries of 3rd parties (beans, plugins etc).

This change has broken many Java WebStart implementations, including ours.

The workarounds for now are:
- Removal of the /application_server/beans/swingbeans.jar
- Make sure your customers do not upgrade to Java 6 update 19
- If your customer(s) have already upgraded to Java 6 update 19, the best option would be to downgrade or activate a previous version on Java on their client machines.
- If they have upgraded and cannot downgrade, they can disable "verification" under Advanced tab > security > "mixed mode" in the Java Control Panel on the client machine(s) , see:
http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#jcp.

Our effort will continue to provide you with a structural solution asap.

Paul

I've tested some other (commercial) Java Webstart applications (with a lot of jars) we work with and they work fine without any security message/warning...

Seems to me a case of a lack of pro active maintenance Servoy side cause the signing issues are not new and security in general is in the spotlights for some time...

My motto is : Fix the problem today if you know the problem will arise the next week/month/year...

Regards.

This doesnt have anything to do with lack of maintenance or something in that direction.

Sun/Oracle changed in a minor release major things what really affects servoys way of doing stuff.
All the resources from the main jnlp file where all signed and permissions where set.
And then we load in everything else as extensions, what in our eyes just lift with our security settings.
This was working fine for years...

Suddenly they changed it and now that second step, the extensions also need to be signed else you will get that warning.
Problem is for Servoy that many of those extensions are not from Servoy.. They are from 3th party even fully open source plugins
or internally developed plugins.. All those plugins suddenly must be signed (and all there dependencies).. Or you will get that dialog that you will get every time you start the client.

So it seems that from now on, you have have 3 options:
1> only use fully signed plugins and beans (no dialog will be shown)
2> use signed plugins and beans but some are self signed (a dialog will be shown at startup but this dialog does have a checkbox "always trust")
3> use unsigned plugins or beans then that dialog which comes up now will always come up at every startup.. (no option to say "always trust")

Currently it is even worse because with 6_u19 there is a bug with <3> so that the dialog they show completely hangs. Because of some threading issues inside Sun code
And <3> is current situation we are dealing with.

I already created many bug reports and feature request the last 2 days in Suns bug database, so hopefully they will improve this.

Johan,

Is there a way that Servoy Development can have new JAVA updates before they get available to the public?
In that case you could test new versions of JAVA and maybe so we can avoid such a situation like this.
Or is Servoy considered as an end-user just like me and all other Servoy users?

Martin

We're downgrading to 6_18, but after a similar problem with that version for us (now fixed by Servoy unsigning one of the jars), my client's I.T. department is not thrilled/getting tired of going to every workstation to downgrade Java. Now they're also turning off auto-update on Java on each workstation (with 250 possible workstations at many sites around the county). Thanks to everyone working on this! Appreciated.

Just checking for an ETA on a fix from Sun or otherwise? Everything above doesn't really work on my install, because of various IT2BE plugins we rely on. Thanks much!

- If they have upgraded and cannot downgrade, they can disable "verification" under Advanced tab > security > "mixed mode" in the Java Control Panel on the client machine(s) , see:http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#jcp.

Just tried the above after installing 1.6.0u19 which didn't work (got the same error regarding swingbeans.jar)

What I need to do to fix this is change the configuration for the j2se version specified in the JNLP file for the smart clients --

...<j2se version="1.4+" max-heap-size="256m"/>...

to

...<j2se version="1.6.0_17" max-heap-size="256m"/>...

Please let me know how I can configure this in Servoy.

ellenmeserow wrote:Just checking for an ETA on a fix from Sun or otherwise? Everything above doesn't really work on my install, because of various IT2BE plugins we rely on. Thanks much!

Hi Ellen, I have done the basic work for Servoy 4/5 last week. That means that all components and libraries are signed and as far as I can see it works. However there are 2 hurdles to take:

1. I need a build from Servoy to test (Servoy will send me a temp build but I have no ETA for that).
2. The jars are now self-signed. That is not what I want so I ordered a certificate. However, I was told that the verification process can take a couple of days. I will not release before I received the certificate because otherwise everybody has to update twice.