Servoy 6.1.3

[Jan_Blok]

We are pleased to announce the immediate availability of Servoy 6.1.3 release (releaseNumber 1424).

This version is available through the download option on the Servoy website and auto-update.
Always make a backup of your current Servoy installation (directory and database) before installing/upgrading.
To update a Servoy eclipse open Check for updates via help menu.

Thanks to the external testers for helping out to get a solid release!

Small behaviour changes:

1. SVY-3354 No (default) background color set on non-transparent tabpanel in WC
   For Web Client, we added the default background color as default CSS to each container (tabpanel,split pane, accordion). This change may affect solutions using a custom default CSS or solutions that do not have transparent flag set correctly on container. Due to this change transparent flag on container has more strict behavior (so non transparent container will show default color).
2. SVY-3220 Methods are not executed when in find mode (in table view only)
   targetfoundset.loadRecord(sourcefoundset) no longer copies the foundset filters from the sourcefoundset to the targetfoundset.
   When targetfoundset and/or sourcefoundset have foundset filters, they are both applied to the sql in targetfoundset, but after a targetfoundset.loadAllrecords() call, targetfoundset is back to its original state with only the targetfoundset filters from before the loadRecords(foundset) call.

All the issues addressed:

Client Changes
[fix] SVY-2996 Wrong rounding in utils.numberformat
[fix] SVY-3311 onAction fired twice in webclient for MEDIA fields with a calculation as source
[fix] SVY-3285 Error when trying to open global methods from a solution
[fix] SVY-3282 Inconsistency in scripting tabpanels
[fix] SVY-3280 LISTBOX element changes its selected item when setValueListItems(dataset) method is executed. Happens in SmartClient only.
[fix] SVY-3279 Labels do not consistently render certain HTML tags
[fix] SVY-3226 JSDataset.getColumnAsArray() does not return a NativeArray
[fix] SVY-3216 Table view, toggling button visibility only works twice
[fix] SVY-3202 LoadFoundset(queryBuilder) whith global tableFilter
[fix] SVY-3179 button blinks when moved
[fix] SVY-3107 onDataChange not triggered from combo
[fix] SVY-3081 foundset.getQuery() in Find Mode returns incorrect value
[fix] SVY-3035 Servoy fails to update records on form based on table with long name.
[fix] SVY-2990 Weird behavior in application.showI18NDialog()
[fix] SVY-2968 Image media in label fields shifts 1 px in smart-client
[fix] SVY-2964 The function utils.stringToNumber has been changed between Servoy 5.x and Servoy 6.x. In Servoy 6.x is now uses the locale to find out the decimalseperator.
[fix] SVY-2867 Missing removeFormVariable in the JSForm object (solutionModel)
[fix] SVY-1710 The foundset selectedIndex is higher than the size of the foundset

Web Client Changes
[fix] SVY-3206 jQuery used is 1.5.2 in Servoy. The latest version is 1.8.2, any hope for an update?
[fix] SVY-3128 Hour Glass in Web Client
[fix] SVY-3342 Modal dialog not shown after logging in
[fix] SVY-3313 NoSuchMethodError: com.servoy.j2db.util.Utils.getURLContent(Ljava/lang/String;)
[fix] SVY-3302 Field on read-only form with format discrepancy causes user to be stuck
[fix] SVY-3292 Bug in Webclient
[fix] SVY-3275 Different margin in accordion panel images in SC and WC
[fix] SVY-3271 servoy.webclient.blockinputonrequest Does strange things with text-area in WC
[fix] SVY-3266 Keep Size/Position of Modal-Windows
[fix] SVY-3208 setScroll(x, y - 40) not working
[fix] SVY-3146 Performance: Manipulating a splitpane divider’s location property in code triggers full-screen redraws in Webclient.
[fix] SVY-3143 Icons are not shown when on textfield
[fix] SVY-3139 Rendering in WebClient & differences between WebClient from Developer and ‘Real WebClient’
[fix] SVY-3137 Select text content not working in editable text area fields
[fix] SVY-3127 HTML Editor caretPosition
[fix] SVY-3126 Scrollable grids messed up by calculation fields
[fix] SVY-3060 Webclient File upload shows path as “C:\fakepath\filename…”
[fix] SVY-3050 table view in web client with one of the columns as html area prevents the selection of the row
[fix] SVY-3031 Weird tab sequence in popup forms in Web Client
[fix] SVY-3010 application.closeAllWindows(); Error Message in web client in an iframe
[fix] SVY-3006 Script errors in IE8
[fix] SVY-2960 Web Client Issue with Standard Tags
[fix] SVY-2956 onRender Event is not working properly in servoy webclient
[fix] SVY-2934 Elements with Top Left Right anchors have wrong size in Web client when the window’s size is smaller than the form’s design time size.
[fix] SVY-2906 Table views are not working in servoy webclient
[fix] SVY-2892 Issue while rotating a label with text @ 270 or 90 degree

Developer Changes
[fix] SVY-3048 Deleting forms in Servoy Developer leave some resource references which the build process later attempts erroneously to use.
[fix] SVY-3068 databaseManager.createDataSourceByQuery Needs Type Hinting
[fix] SVY-3319 Cannot clear the Lookup Value setting on the Auto Enter tab for columns in the Table Editor
[fix] SVY-3272 Can’t edit passwords in Developer
[fix] SVY-3281 IDE: Random hang on startup.
[fix] SVY-3260 In the Table editor, if only the Lookup Value on the Auto Enter tab is changed for an existing column
[fix] SVY-3250 You Cannot Copy and Paste in an editable combo box
[fix] SVY-3222 Servoy Developer memory leak, cutting/pasting buttons, running webclient
[fix] SVY-3219 Cannot export solution if “Protect with password” option is checked
[fix] SVY-3207 Servoy developer doesnot startup
[fix] SVY-3099 TRend Micro Titanium 2013 reports Servoy.EXE (Developer) as a threat.
[fix] SVY-3096 Servoy IDE: The “Search for References” function on table columns is inaccurate.
[fix] SVY-3093 The readOnly property of fields gets reset to false when a form is removed from a TabPanel and then added back on and displayed
[fix] SVY-3090 Invalid error markers mentioning a strange length & scale values with Oracle.
[fix] SVY-3085 Referencing code outside the scope of the current form in JSField.onRender callback causes fields in the Footer part of TABLE_VIEW forms to lose their data binding
[fix] SVY-2994 Commit Media issue after upgrade to 6.1

Server Changes
[fix] SVY-3080 WicketRuntimeException: Cannot modify component hierarchy after render phase has started (page version cant change then anymore)
[fix] SVY-2954 Servoy does not handle searching on clob fields properly

Plugin Changes
[fix] SVY-2988 showFileOpenDialog is displayed within the bounds of the popup form in webclient
[fix] SVY-3301 udpPacket.readUTF() returns null as does udpPacket.readUTF(udpPacket.getLength())

[SteveInLA]

Some new warnings are appearing in my solutions. The variable ‘e’ defined in the try/catch statement (try { x } catch (e) { # }) used to have the properties message and name. Now Servoy does not recognize those properties as valid and does not appear to know the variable’s type. If I now need to include a JSDoc variable definition for the exception variable, how should the try/catch statement be constructed?

[swingman]

I saw the same problem as Steve when upgrading to 6.1.3.

The upgrade seems to solve most of the few issues I had with 6.1.2.

[SteveInLA]

I also see warnings for functions that pass a JSRecord variable from the main solution to a function in a module. I have created case SVY-3488 for this one. This doesn’t appear to affect the functionality of the methods, but it seems like the warning is erroneous.

I too feel that this upgrade has solved the issues I had in 6.1.2. Great job as always!

[ptalbot]

SteveInLA:
Some new warnings are appearing in my solutions. The variable ‘e’ defined in the try/catch statement (try { x } catch (e) { # }) used to have the properties message and name. Now Servoy does not recognize those properties as valid and does not appear to know the variable’s type. If I now need to include a JSDoc variable definition for the exception variable, how should the try/catch statement be constructed?

I agree, it seems that with each new version of Servoy 6.x the parser is getting dumber and dumber, it’s really annoying that you have to type almost every single variable now.

Sometimes you have to type simple int variables otherwise they are not recognized, like:
var num = 0;

Datasets are not recognized reliably anymore, for example when you do:

var ds = databaseManager.getDatasetByQuery(...)
// then later:
foundset.loadRecords(ds); // warning!

[SteveInLA]

ptalbot:
Datasets are not recognized reliably anymore

I see this too and not in all cases.

As what type of variable should ‘e’ be defined? Is it a ServoyException type? That type has a method for getMessage() but not a property for message.

[jcompagner]

The catch(e) is already fix, problem was that in the dltk something i made was reverted, this is because i typed “e” as an Error (js exception object) but “e” doesn’t have to be a exception at all (because you can do “throw 1” and then e is just a Number
For now i made “e” an Error again in the dltk version of Servoy, in the future this will be default but you are able to override it as catch(/** @type {Number*/ e) but when that will happen is not decided yet.

Patrick: there is constantly a lot of changes, it is getting better and better the only problem is that in the release of 6.1.3 there are some regressions because of those changes, for the most part they are all fixed already in the current open source code.
What do you mean with “var num = 0”, compared to what else?
Also your dataset example is working fine for me (in the current code, didn’t test in the actual 6.1.3)

[ptalbot]

Johan: I know there are lots of changes, and I know you are working on making it better, but from 6.1.0 to 6.1.3, I’m positive that I’ve had to add new JSDocs with every update, where previous version was interpreting the variables just fine.

In the case of the dataset, here’s what I see in 6.1.3:
[attachment=0]warning.png[/attachment]
And the warning is “The function loadRecords(JSFoundSet) is not applicable for the arguments (?)”
It disappears of course if I put
/** @type {JSDataSet} */ before the “var ds = …” line

As to: “var num = 0;” of course the warning is not directly in this line, but later.
I would have to chase some example of places where using num later is not recognized and where I had to put /** @type {Number} */ before that declaration, but I can assure you I’ve seen the case.
I’ll try to make more notes of that in the future instead of patiently adding some more JSDocs.

[jcompagner]

i can just say, don’t add just doc, just report it if you expect it to work. Then i will fix it asap.
this works fine for me in the current code:

var ds = databaseManager.convertToDataSet([1,2,3]);
if (ds) {
var fs = databaseManager.getFoundSet(“”,“”);
fs.loadRecords(ds);
}

if you hover over ds variable what does it say?

Can menuPKs be null? Because that is the only way that ds can be null (so you need if(ds))

[john.allen]

Big problem.

I updated an active solution from 6.1.2 to 6.1.3 first in Developer. Because of the set up here this can only run in web client. This whole solution has been recently upgraded from 5.2 to 6.1.2 and switched from mainly smart client to only web client. In Developer sometime after the upgrade I noticed that when launching a web client that that client could not load more than one record. If I did a find that returned more than one, it crashed the web page with the message: “Internal error Return to home page”. Finding just one record worked without any error. Launching a smart client from Developer also worked with no errors regardless of how many records were found. I thought that perhaps it was something to do with the few changes I had made to the solution and as I wasn’t having any trouble with the solution I had on the server I decided to try and figure out what I could have done and left everything alone on my production server. Today though I upgraded the exact same solution on my test server to 6.1.3 and got exactly the same error! Running fine before on 6.1.2 but upgraded to 6.1.3 and immediately crashed when finding more than one record.

Below is the error reported in the servoy-admin page from the test server when this happens. Also copied below is the error from the servoy-admin page when running it from Developer (they are almost the same).

Any ideas? This is a pretty big problem as I have now upgraded my solution and I’m not 100% sure I can work out which export of the solution was the last one before I upgraded. If I do figure that out I suppose I can start a new developer using 6.1.2 and import that solution into it. (Or maybe the current solution running under 6.1.3 could be imported into a 6.1.2 instance of Servoy?). If that works I could then export that in .WAR file to wipe out the old .WAR install and have 6.1.2 running. But maybe there is some simple explanation for this crash from the upgrade?

Please advise…

Server errors

Time Thread Level Category Message ClientId Solution Name
2012-11-30 18:39 TP-Processor6 ERROR com.servoy.j2db.util.Debug Error rendering the page patient 194599B4-1680-4562-AD57-9889E3F47C4D URO_ONCOLOGY
java.lang.NullPointerException
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView.getRowSelectionScript(WebCellBasedView.java:4271)
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView$OddEvenSelectedBehavior.renderHead(WebCellBasedView.java:268)
at org.apache.wicket.Component.renderHead(Component.java:2807)
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView.renderHead(WebCellBasedView.java:4086)
at org.apache.wicket.ajax.AjaxRequestTarget.respondHeaderContribution(AjaxRequestTarget.java:1152)
at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:856)
at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:680)
at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:590)
at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:105)
at com.servoy.j2db.server.headlessclient.WebClientsApplication$7.respond(WebClientsApplication.java:536)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1287)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1358)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1465)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
at com.servoy.j2db.server.servlets.Zt.doGet(Zt.java:14)
at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:138)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
2012-11-30 18:39 TP-Processor6 ERROR org.apache.wicket.RequestCycle null 194599B4-1680-4562-AD57-9889E3F47C4D URO_ONCOLOGY
java.lang.NullPointerException
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView.getRowSelectionScript(WebCellBasedView.java:4271)
.
. (same as exception above)
.

Developer server errors:

java.lang.NullPointerException
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView.getRowSelectionScript(WebCellBasedView.java:4271)
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView$OddEvenSelectedBehavior.renderHead(WebCellBasedView.java:268)
at org.apache.wicket.Component.renderHead(Component.java:2807)
at com.servoy.j2db.server.headlessclient.dataui.WebCellBasedView.renderHead(WebCellBasedView.java:4086)
at org.apache.wicket.ajax.AjaxRequestTarget.respondHeaderContribution(AjaxRequestTarget.java:1152)
at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:856)
at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:680)
at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:590)
at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:105)
at com.servoy.j2db.server.headlessclient.WebClientsApplication$7.respond(WebClientsApplication.java:536)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1287)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1358)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1465)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
at com.servoy.j2db.server.servlets.Zt.doGet(Zt.java:14)
at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:138)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)

[john.allen]

N.B. I also have another solution running on a separate server that was upgraded from 6.0.7 to 6.1.2 to 6.1.3 and has none of these problems. So I’m presuming it is related in some way to the solution but it only manifested itself in the upgrade to 6.1.3. There were and are no errors and only 3 warnings on that problem solution with the warnings all related to the fact I have some deprecated ‘RowBGColorCalc’ functions running.

[john.allen]

Further update…
After that last response I thought I’d try removing the RowBGColorCalcs from being called on the three forms. And bingo that seemed to do it. The main use of that function is in a form on the left side that allows the data manager or MD to see at a glance certain characteristics about the foundset of patients they are currently examining. It is handy (picture worth a thousand words and all that) but if I have to get rid of it I guess I’ll have to try using the onRender functions more…

[obuligan]

@john.allen It is recommended switching to the more powerful “onRender” mechanism in which you can calculate more than just the BG color (converting to onRender should be straight forward).
The issue you have is now fixed in the next release . As a workaround to keep RowBGColorCalcs you can define the 3 styles (selected, odd,even) with empty bodies and the null pointer should go away.

[rossent]

SteveInLA:
I also see warnings for functions that pass a JSRecord variable from the main solution to a function in a module. I have created case SVY-3488 for this one. This doesn’t appear to affect the functionality of the methods, but it seems like the warning is erroneous.

I too feel that this upgrade has solved the issues I had in 6.1.2. Great job as always!

When can we get a patch/fix for the issue (SVY-3488)? It is causing thousands of erroneous warnings for us and is impossible to distinguish the real issues in the code from the “fake” ones…

[Kahuna]

Hi Folks

We have been trialing our solution in 6.1.3 and it seems that every button has lost its link top the style. So in 6.0.8 a series of buttons are coloured blue using styleClass tci (in this instance). After opening the solution in 6.1 the styleClass is unresolved.

Obviously it will be a shed load of work to correct every instance of a missing style. Is there something we should be setting before opening a workspace or solution in 6.1?

[david]

JS docs for functions in variables used to show up with code completion in Servoy 6.0.x. Code completion still works in 6.1.3 for objects defined this way but js docs are not retrieved.

Setting up objects this way is a wonderful way to expose an API with code completion and full documentation at the coder’s fingertips. Can we get this feature added back in?

https://support.servoy.com/browse/SVY-3568

[attachment=0]qb js doc working.png[/attachment]

[mboegem]

Kahuna:
We have been trialing our solution in 6.1.3 and it seems that every button has lost its link top the style. So in 6.0.8 a series of buttons are coloured blue using styleClass tci (in this instance). After opening the solution in 6.1 the styleClass is unresolved.

Obviously it will be a shed load of work to correct every instance of a missing style. Is there something we should be setting before opening a workspace or solution in 6.1?

Have noticed in 6.1.2 already style classes are saved preserving upper/lowercase, where before even classes in for example camel case were stored lowercase in the form.
Also I’m being informed a new css parser is used, where for example a class like ‘label.coloured:Red’ should now be written as ‘label.coloured:Red’ (so escaping special characters)
As styleclasses are referenced by name, you should be able to do a search/replace on your forms throughout your workspace.

Good luck!

[rossent]

In 6.1.3 we are getting a lot of these (the errors are from the eclipse log file in the .metadata folder of the workspace):

!ENTRY org.eclipse.dltk.core 4 2 2012-12-14 14:04:53.151
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.dltk.core".
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed: Type "JSRecord<db:/argos_user_data/ac_account>" is a proxy
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
	at org.eclipse.dltk.internal.javascript.parser.JSDocValidatorFactory$TypeChecker.doCheckType(JSDocValidatorFactory.java:235)
	at org.eclipse.dltk.internal.javascript.parser.JSDocValidatorFactory$TypeChecker.validate(JSDocValidatorFactory.java:227)
	at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator.build(TypeInfoValidator.java:159)
	at org.eclipse.dltk.internal.core.ReconcileBuilder.run(ReconcileBuilder.java:99)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.dltk.internal.core.ReconcileBuilder.build(ReconcileBuilder.java:77)
	at org.eclipse.dltk.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:91)
	at org.eclipse.dltk.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:58)
	at org.eclipse.dltk.internal.core.ModelOperation.run(ModelOperation.java:698)
	at org.eclipse.dltk.internal.core.ModelOperation.runOperation(ModelOperation.java:764)
	at org.eclipse.dltk.internal.core.SourceModule.reconcile(SourceModule.java:330)
	at org.eclipse.dltk.internal.ui.text.ScriptReconcilingStrategy.reconcile(ScriptReconcilingStrategy.java:164)
	at org.eclipse.dltk.internal.ui.text.ScriptReconcilingStrategy.access$0(ScriptReconcilingStrategy.java:153)
	at org.eclipse.dltk.internal.ui.text.ScriptReconcilingStrategy$1.run(ScriptReconcilingStrategy.java:125)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.dltk.internal.ui.text.ScriptReconcilingStrategy.reconcile(ScriptReconcilingStrategy.java:120)
	at org.eclipse.dltk.internal.ui.text.ScriptReconcilingStrategy.reconcile(ScriptReconcilingStrategy.java:192)
	at org.eclipse.dltk.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:97)
	at org.eclipse.dltk.internal.ui.text.ScriptCompositeReconcilingStrategy.reconcile(ScriptCompositeReconcilingStrategy.java:100)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

The second error which actually eventually crashes the Servoy Developer is this:

!ENTRY org.eclipse.ui 4 0 2012-12-14 14:16:20.437
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTError: No more handles)
	at org.eclipse.swt.SWT.error(SWT.java:4282)
	at org.eclipse.swt.SWT.error(SWT.java:4197)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Caused by: org.eclipse.swt.SWTError: No more handles
	at org.eclipse.swt.SWT.error(SWT.java:4308)
	at org.eclipse.swt.SWT.error(SWT.java:4197)
	at org.eclipse.swt.SWT.error(SWT.java:4168)
	at org.eclipse.swt.internal.ImageList.copyWithAlpha(ImageList.java:179)
	at org.eclipse.swt.internal.ImageList.set(ImageList.java:409)
	at org.eclipse.swt.internal.ImageList.add(ImageList.java:70)
	at org.eclipse.swt.widgets.Table.imageIndex(Table.java:2930)
	at org.eclipse.swt.widgets.TableItem.setImage(TableItem.java:1100)
	at org.eclipse.jface.viewers.TableViewerRow.setImage(TableViewerRow.java:134)
	at org.eclipse.jface.viewers.ViewerCell.setImage(ViewerCell.java:169)
	at org.eclipse.jface.viewers.ColumnLabelProvider.update(ColumnLabelProvider.java:38)
	at com.servoy.eclipse.ui.views.solutionexplorer.DecoratingColumnLabelProvider.update(DecoratingColumnLabelProvider.java:326)
	at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:152)
	at org.eclipse.jface.viewers.AbstractTableViewer.doUpdateItem(AbstractTableViewer.java:399)
	at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:485)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2167)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefreshAll(AbstractTableViewer.java:711)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:649)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:636)
	at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1508)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1443)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1404)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1506)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:537)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1465)
	at com.servoy.eclipse.ui.views.solutionexplorer.SolutionExplorerView$16$2.run(SolutionExplorerView.java:1818)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	... 22 more

It appears that the Servoy Developer is “leaking” memory or handles and we need to restart the developer multiple times per day. We have not isolated this issue to a particular part of the Servoy Developer, but suspect that it has to do with searching for method or form references.

[jcompagner]

That first error shouldn’t really happen anymore in 6.1.3 or at least in the next 6.1.4. If you still see it in the 6.1.4 release please report it in a case.
The problem is that that specific type is made a proxy because all types are flushed because of a change. But those types shouldn’t be used then anymore.

For the second error, we have 1 more report of this also on 6.1.2 or something. But we really don’t have any idea what that happens, we really need some use case when that happens
I had the same thing in my plain java eclipse yesterday also… But that was i guess running for quite a while and the only thing that could be the same is eclipse itself and the svn plugin i guess
that stack i see is that quite plain eclipse updating a Tree/TableViewer but that doesn’t say much why it happens.

[rossent]

jcompagner:
That first error shouldn’t really happen anymore in 6.1.3 or at least in the next 6.1.4. If you still see it in the 6.1.4 release please report it in a case.
The problem is that that specific type is made a proxy because all types are flushed because of a change. But those types shouldn’t be used then anymore.

For the second error, we have 1 more report of this also on 6.1.2 or something. But we really don’t have any idea what that happens, we really need some use case when that happens
I had the same thing in my plain java eclipse yesterday also… But that was i guess running for quite a while and the only thing that could be the same is eclipse itself and the svn plugin i guess
that stack i see is that quite plain eclipse updating a Tree/TableViewer but that doesn’t say much why it happens.

The second error usually happens when the active solution references multiple modules which in turn reference multiple modules so the full solution tree is very large - in such cases reference searchers, running unit tests (and potentially building the tree of the unit tests), etc. are usually the “final” drop which causes the crash.

Another issue which happened to us several times already when testing the 6.1.3 server is out-of-memory condition which basically crashes the server. In all cases, this happened when using the web client. We managed to get a memory dump of one of those crashes. The following is from the memory dump analyser:

One instance of "com.servoy.j2db.server.headlessclient.dataui.WebTabPanel" loaded by "sun.misc.Launcher$AppClassLoader @ 0x29ab5388" occupies 798,819,024 (61.69%) bytes. The memory is accumulated in one instance of "java.lang.Object[]" loaded by "<system class loader>".

Keywords
java.lang.Object[]
sun.misc.Launcher$AppClassLoader @ 0x29ab5388
com.servoy.j2db.server.headlessclient.dataui.WebTabPanel

I have the memory dump available on an FTP server in case you want to take a look at it. These are some of the entries form the server log when these crashes occur:

2012-12-12 16:45:14,244 ERROR [http-8085-4] com.servoy.j2db.util.Debug - Throwable [E3E250DC-E3E6-4288-9BBB-C2A2DC8102D7 argos_agile_client]
org.apache.wicket.WicketRuntimeException: After 1 minute the Pagemap null is still locked by: Thread[http-8085-5,5,main], giving up trying to get the page for path: 4
	at java.lang.Class.isArray(Native Method)
	at org.mozilla.javascript.ScriptRuntime.toBoolean(ScriptRuntime.java:349)
	at org.mozilla.javascript.Interpreter.stack_boolean(Interpreter.java:3102)
	at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1354)
	at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:837)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:158)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:406)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3192)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:156)
	at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:574)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4930)
	at com.servoy.j2db.FormController.executeFormMethod(FormController.java:5261)
	at com.servoy.j2db.FormController.executeOnLoadMethod(FormController.java:5113)
	at com.servoy.j2db.FormManager.getFormController(FormManager.java:800)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabFormLookup.getWebForm(WebTabFormLookup.java:147)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabFormLookup.getWebForm(WebTabFormLookup.java:135)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.getCurrentForm(WebTabPanel.java:510)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.getChildForms(WebTabPanel.java:515)
	at com.servoy.j2db.server.headlessclient.dataui.WebDataRendererFactory.goDownContainer(WebDataRendererFactory.java:344)
	at com.servoy.j2db.server.headlessclient.dataui.WebDataRendererFactory.reapplyTabSequence(WebDataRendererFactory.java:442)
	at com.servoy.j2db.FormController.recomputeTabSequence(FormController.java:5456)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.recomputeTabSequence(WebTabPanel.java:540)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.setCurrentForm(WebTabPanel.java:491)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.initalizeFirstTab(WebTabPanel.java:568)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$6.component(WebEventExecutor.java:703)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$6.component(WebEventExecutor.java:1)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:920)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.generateResponse(WebEventExecutor.java:699)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.onEvent(WebEventExecutor.java:403)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$2.onEvent(WebEventExecutor.java:180)
	at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
	at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:312)
	at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:157)
	at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
	at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1279)
	at org.apache.wicket.RequestCycle.step(RequestCycle.java:1358)
	at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1465)
	at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
	at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
	at com.servoy.j2db.server.servlets.Zt.doGet(Zt.java:14)
	at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:138)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:554)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
	at java.lang.Thread.run(Unknown Source)
2012-12-12 16:49:25,449 ERROR [ModificationWatcher Task] org.apache.wicket.util.thread.Task - Task ModificationWatcher terminated [ ]
java.lang.OutOfMemoryError: Java heap space
2012-12-12 16:50:45,435 ERROR [http-8085-5] org.apache.wicket.Session - Exception when detaching/serializing page [E3E250DC-E3E6-4288-9BBB-C2A2DC8102D7 argos_agile_client]
java.lang.OutOfMemoryError: Java heap space
2012-12-12 16:50:45,435 ERROR [http-8085-5] com.servoy.j2db.util.Debug - RuntimeException in the ServoyFilter.doGet [ ]
java.lang.OutOfMemoryError: Java heap space
	at org.mozilla.javascript.ScriptRuntime.wrapNumber(ScriptRuntime.java:328)
	at org.mozilla.javascript.NativeArray.getInstanceIdValue(NativeArray.java:139)
	at org.mozilla.javascript.IdScriptableObject.get(IdScriptableObject.java:366)
	at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:2141)
	at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1518)
	at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1505)
	at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1408)
	at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:837)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:158)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:406)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3192)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:156)
	at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:574)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4930)
	at com.servoy.j2db.FormController.executeFormMethod(FormController.java:5261)
	at com.servoy.j2db.FormController.executeOnLoadMethod(FormController.java:5113)
	at com.servoy.j2db.FormManager.getFormController(FormManager.java:800)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabFormLookup.getWebForm(WebTabFormLookup.java:147)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabFormLookup.getWebForm(WebTabFormLookup.java:135)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.getCurrentForm(WebTabPanel.java:510)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.getChildForms(WebTabPanel.java:515)
	at com.servoy.j2db.server.headlessclient.dataui.WebDataRendererFactory.goDownContainer(WebDataRendererFactory.java:344)
	at com.servoy.j2db.server.headlessclient.dataui.WebDataRendererFactory.reapplyTabSequence(WebDataRendererFactory.java:442)
	at com.servoy.j2db.FormController.recomputeTabSequence(FormController.java:5456)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.recomputeTabSequence(WebTabPanel.java:540)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.setCurrentForm(WebTabPanel.java:491)
	at com.servoy.j2db.server.headlessclient.dataui.WebTabPanel.initalizeFirstTab(WebTabPanel.java:568)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$6.component(WebEventExecutor.java:703)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$6.component(WebEventExecutor.java:1)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:920)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)
	at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:935)

We cannot reproduce the crashes “at will” and preliminary inspection of our code does not show anything suspicious. It appears as if under some conditions the application server gets into some sort of infinite loop trying to generate the HTML for the web client. Several of the crashes happened when we remove a form from a tab panel and display a different one. After the crash if we try the same thing it always works fine without issues. Let me know if you would like to download the memory dump.