We are pleased to announce the availability of Servoy 2020.12.0 (release number 3622)
Look at the whats new for more info about the 2020.12.x changes
For all fixes in this release see issues list.
This version is available through the the download site
We ship only installers, so for windows an exe file and for osx a dmg, for linux we have a archive tar file.
The full installers/archives are only for new installs, never use that to update/overwrite an existing install, existing installations should always be updated through the “check for updates”.
This release can be updated by using the “latest” url: http://download.servoy.com/developer/latest/ (when you come from 2019.03 or higher)
If you install a clean install besides the current one which is 2019.12 or lower, be aware that the workspace will be upgraded and it is not recommended to use an upgraded workspace with an older release again.
This release is build on Eclipse 2020.09 (4.17)
If check for updates says there are no updates, then it could be a caching problem of eclipse, please restart the developer once and try again.
We ship a java with our installation (Java 15.0.1). So there doesn’t need to be a java installed on the system anymore.
Also with a next update, we can update the java version with it so no need to keep it up to date yourself anymore.
This is a release in our quarterly release cycle, if you want to stay on the LTS path you need to stick to 2020.03.2 and enabled only the lts update site.
I did and I regret it because Eclipse has a number of problems that don’t seem to be resolved with the 2020.12 update. These are core eclipse issues and not Servoy specific.
Not tried running on M1 though (waiting for the more powerful models to be released with 4 thunderbolt ports).
databaseManager.saveData() return false after login.
Testing the new version in my solution in developer I realise that always databaseManager.saveData() return false,
but if I do a process who save a record in a table at the login form before login and it return true.
Do I have to put something at the onOpen solution process to permit the solution to save record??
what is the record exception or the record markers (record.getRecordMarkers()) after a save fails?
Are you saying this didn’t happen in 2020.09 and it now it behaves differently in 2020.12?
I think for server based clients (ng,web) saving before login i think does work, but for smart it will for sure not work, it should bomb out with an exception (so not even returning just false)
I don’t have any exception and the record.recordMarkers:
{hasErrors:true,
onBeforeInsertFailed:false,
onBeforeUpdateFailed:false,
record:{baja:0,cod_iso:null,cod_iso_alfa2:null,cod_iso_num:null,
f_fch_alta:Fri Jan 08 13:46:32 WET 2021,f_fch_mod:null,
f_usu_alt:“CF594748-9F32-40ED-9C36-973F19564C5E”,f_usu_mod:null,
nacionalidad:null,nombre:“asdas”,pais_id:307,saas_id:57,tipo_pais:null}}
My previous version is the 2020.06 an I am using ng-client.
Hi Johan, I found the problem.
for some reason this version is more strict with the database.
I am trying to write a uuid(36 length) in a field which size is 35.
The recordMarkers.getMarkers() gave that message → Column “FIELDNAME” is too small.
Hi Johan,
I have exported a war file from my developer version 2020.12.0 without solution and modules.
I put it in the tomcat webapps folder and
I access to the servoy web admin page to the solutions (http://myIP/app/servoy-admin/solutions)
and of course there is no solution.
I export my solution from developer (Export Solution → File export) it create a .servoy file.
Returning to the servoy web admin page to the solutions,
I click on the “Import a solution”, I select my .servoy file and press the button “Import” and
nothing happens, no messages at the http://myIP/app/servoy-admin/solutions/import.
I click at the Server log and it shows that log message:
Is there any check to allow to import solution?
that’s option works fin at the 2020.06.1
I do that in a new tomcat install with a total empty repository.
no idea what that is that is just a temp file that is generated because of the upload shouldn’t have anything todo with modules or what ever (its just about that file)
we are using that there apache commons upload and we create a system temp file: importFile = File.createTempFile(“import”, “.servoy”);
that is not changed in ages.
And we just depend ons system stuff that the generate an unique file
Do you have a full stacktrace somewhere?
2021-01-11 07:55:18,208 ERROR [http-nio-8083-exec-9] com.servoy.j2db.util.Debug - Destination ‘C:\Program Files\Apache Software Foundation\Tomcat 9.0.41\temp\import8631841931862420730.servoy’ already exists
org.apache.commons.io.FileExistsException: Destination ‘C:\Program Files\Apache Software Foundation\Tomcat 9.0.41\temp\import8631841931862420730.servoy’ already exists
at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001) ~[commons-io.jar:2.6]
at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) ~[commons-fileupload.jar:1.4]
at com.servoy.j2db.server.servlets.ConfigServlet.Za(ConfigServlet.java:2293) [j2dbdev.jar:2020.12.0.3622]
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:1063) [j2dbdev.jar:2020.12.0.3622]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) [servlet-api.jar:4.0.FR]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) [catalina.jar:9.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:9.0.41]
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) [tomcat-websocket.jar:9.0.41]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:9.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:9.0.41]
at org.sablo.filter.SecurityFilter.doFilter(SecurityFilter.java:48) [sablo_2020.12.0.3622.jar:?]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:9.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:9.0.41]
at org.sablo.filter.SeparateSessionFilter.doFilter(SeparateSessionFilter.java:80) [sablo_2020.12.0.3622.jar:?]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:9.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:9.0.41]
at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71) [log4j-web-2.11.2.jar:2.11.2]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:9.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:9.0.41]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) [catalina.jar:9.0.41]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) [catalina.jar:9.0.41]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542) [catalina.jar:9.0.41]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [catalina.jar:9.0.41]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) [catalina.jar:9.0.41]
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) [catalina.jar:9.0.41]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) [catalina.jar:9.0.41]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) [catalina.jar:9.0.41]
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:374) [tomcat-coyote.jar:9.0.41]
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) [tomcat-coyote.jar:9.0.41]
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:888) [tomcat-coyote.jar:9.0.41]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1597) [tomcat-coyote.jar:9.0.41]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-coyote.jar:9.0.41]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_271]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-util.jar:9.0.41]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_271]
no i think its the update of commons-fileupload.jar that we upped from 1.3.3 to 1.4
and that has now some different behavior in
at org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)
you could potentially test this by getting the commons-upload.jar from 09 and write it over application_server/lib/commons-upload.jar of 12 and generate your WAR again
if you use a repository_server thats not done in an inmemory table
and you created that repository_server with a 2020.09 release then it could be that when upgrading to 2020.12 you will get a “upgrade repository” button on the admin page.
But that then bombs out with a primary key violation if that is the case you can fix that by running this statement first:
update servoy_user_properties set property_value = 53 where name = ‘repository_version’ (and property_value = 52)
because you are already on a repo version 53 but the the whole system doesn’t know that yet.
We had this same problem when importing a .servoy file.
Like Johan says, the solution was to get the application_server/lib/commons-fileupload.jar from an old servoy installation and recreate the war.
After deploying the new war, the .servoy could be imported.