Servoy 2020.12.0

[jcompagner]

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.

[rafig]

Happy New Year!
And congratulations on getting out the latest version

[swingman]

Happy New Year!

What is the status of this version running on Mac OS X 11 (Big Sur) or Apple Silicon?

[steve1376656734]

Don't upgrade to Big Sur!

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).

Steve

[Juan Etec]

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??

Un Saludo

[jcompagner]

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)

[Juan Etec]

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.

[jcompagner]

not sure what is printed that but as you can see it has record markers and it says "hasErrors"
so something did go wrong saving that record

please investigate the markers coming from the record so check the JSREcordMarkers.getGenericExceptions() and so on

[Juan Etec]

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.

Thanks for you help.

[jcompagner]

so until now you always lost a byte?!

[Juan Etec]

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:

2021-01-11 08:36 http-nio-8083-exec-8 ERROR com.servoy.j2db.util.Debug Destination 'C:\Program Files\Apache Software Foundation\Tomcat 9.0.41\temp\import6077676454136917744.servoy' already exists

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.

[jcompagner]

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?

[Juan Etec]

This is what I found:

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]

[Juan Etec]

Could be a problem with the Tomcat version??

[jcompagner]

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