Servoy 5.1.2

We are pleased to announce the immediate availability of Servoy 5.1.2 Final
This version is released as workaround to the unexpected webstart security level change in Java 6 update 19 (which led to unusable security dialogs due to bugs in Java 6 update 19 itself)
When installing this version all non Servoy beans and plugins have to be signed by there vendor! Plugin/beans developer should have a look here

This version is available through the download page on the Servoy website (developer section) and auto update.
Always make a backup of your current Servoy installation (directory and database) before upgrading. :!:
To update eclipse open, Window → Preferences (update sites), change:
-Disable both eclipse.org update-sites, since there is a problem at the eclipse side!

Client changes:
[fix] 283364 JSEvent from table view does not always contain a formName
[fix] 282698 Loop due to resize event fires
[fix] 282903 onAction is sometimes triggered by onRightClick
[fix] 281622 Reference Error after solutionModel.revertForm()
[fix] 282410 SolutionModel attached onShow does not trigger
[fix] 279047 Valuelist with global method displayValue is always lowercase
[fix] 281424 Using the method databaseManager.copyMatchingColumns in RECORD_VIEW forms causes TYPE_AHEAD fields with relational valuelist attached to display incorrect data
[fix] 281421 The values of a valuelist are not updated correctly upon save having focus

Webclient changes:
[fix] 282539 Form with no table errors when referenced in webclient
[fix] 282762 onDoubleclick javascript usage in html fields in webclient
[fix] 281459 Weclient anchors cutting off fields
[fix] 281363 alignment issue showing image in media type field

Developer changes:
[fix] 274457 Client Freezes while developing
[fix] 281428 Placing a portal with fill name property and fill text property checkboxes selected for the dataproviders results in wrong titletext

Jan Blok:
We are pleased to announce the immediate availability of Servoy 5.1.2 Final
This version is released as workaround to the unexpected webstart security level change in Java 6 update 19 (which led to unusable security dialogs due to bugs in Java 6 update 19 itself)

Jan can you explain a little bit more?
Is this fix ONLY for Servoy itself and it’s plugins/bean?
Because we had the same issues with IT2BE’s plugin/beans( which btw, he is working on) or does this release, fix this also?

Do we need to contact all our plugin-vendors? or do they have an how-to, what to do next?

This release makes Servoy smartclient run out of the box again on Java 6u19, I’m writing a separate explanation for plugin developers.

The explanation for bean/plugin developers can be found here

So it appears smartclient doesn’t run solutions on 5.1.2 server that use unsigned beans regardless of java version, it that correct? The solutions run OK in 5.1.2 developer.

java 6.17 console:

Java Web Start Error:

Found unsigned entry in resource: (http://localhost:8080/beans/datebean.jar, 1268154238196)

you have to make sure that everything that is send to the client is signed
including 3th party beans:

viewtopic.php?f=15&t=13974

Prior to Servoy 5.1.2 we were able to use the toString() method of the function objects and create new JSMethod object. This approach still work when running a SmartClient in the Servoy Developer but when attempting the same while the solution is running on the server we get errors:

java.lang.RuntimeException: Error parsing function functionName…() {
[native code, arity=0]
}

The code causing this is similar to:

function someRealFunction()
{

}

function createResultForm()
{
var _resultForm = solutionModel.newForm(…);
var _functionCode = someRealFunction.toString();
_resultForm.newFormMethod(_functionCode);

}

Again, this used to work as expected prior to 5.1.2 and is still working as expected when run through the Servoy Developer but fails when running on the Server. Has there been a bug introduced (seems like it) or has there been some change in functionality which is not documented?

yes this is an optimize that is done on purpose.
its best that you don’t rely on the toString() of a function object.

Why don’t you use the solution model to get to the source of the function?

If you really want it back on then you need to set this system property:

servoy.generateJavascriptSource=true

And also push that to the smart clients.

But do know that this can result into up to 30% more memory usage per client, and that is especially in the webclient quite a lot.

jcompagner:
yes this is an optimize that is done on purpose.
its best that you don’t rely on the toString() of a function object.

Why don’t you use the solution model to get to the source of the function?

If you really want it back on then you need to set this system property:

servoy.generateJavascriptSource=true

And also push that to the smart clients.

But do know that this can result into up to 30% more memory usage per client, and that is especially in the webclient quite a lot.

How would the (Servoy) programmer’s life be if this kind of changes were documented upon release of a Servoy update ?

Better or worse ?

Let’s vote…

Regards,

jcompagner:
yes this is an optimize that is done on purpose. its best that you don’t rely on the toString() of a function object…

Thanks for the explanation. I suspected something like this. We are already moving away from using this approach anyway, I guess this will be the last reason to make us do it :wink:

As for having such information available to Servoy programmers upon the release of new versions - I vote firmly YES! It is one thing to have the information available and choose how to use it and completely another to not know what is going on lose time trying to figure out what should be done next.

Hi ,

When will the jasperreport plugin(.jar) (and dependencies) be signed ?

Regards,

http://code.google.com/p/servoy-jasperr … n_released

lwjwillemsen:
Hi ,

When will the jasperreport plugin(.jar) (and dependencies) be signed ?

Regards,

As Johan has highlighted, it’s already released. But it’s not including the latest version of jasperreports jar (jasperreports-3.7.1.jar instead of jasperreports-3.7.2.jar). So if you work on iReport 3.7.2 and need to use jasperreports-3.7.2.jar you have to sign it yourself and try to include it into Servoy without raising the “signed with different keystores” error, which is a pain!!