We are pleased to announce the availability of Servoy 8.2.3 (releasenumber 3109)
This version is available through our download site
The update site is: http://download.servoy.com/developer/8xx_updates/
There are, compared to the 8.2.3rc, a few extra fixes are done to fix some regressions and one small improvement for Progress
see our wiki: 8.2.3 for the issues fixed in this release compared to: 8.2.3 release candidate.
This will be very likely the last 8.2.x release and it will be superseded by 8.3 where the version RC will be released beginning of April.
Hello,
I updated our application server to 8.2.3 and now it’s not possible to import a solution anymore.
servoy_log:
2018-03-28 08:08:10,758 ERROR [http-nio-8080-exec-4] com.servoy.j2db.util.Debug - java.lang.ClassCastException: com.servoy.j2db.persistence.WebObjectBasicImpl cannot be cast to com.servoy.j2db.persistence.WebObjectImpl [ ]
com.servoy.j2db.persistence.RepositoryException: java.lang.ClassCastException: com.servoy.j2db.persistence.WebObjectBasicImpl cannot be cast to com.servoy.j2db.persistence.WebObjectImpl
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:495)
at com.servoy.j2db.server.Zc.Zhb.importFromJarFile(Zhb.java:124)
at com.servoy.j2db.server.servlets.ConfigServlet.Za(ConfigServlet.java:703)
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:2780)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassCastException: com.servoy.j2db.persistence.WebObjectBasicImpl cannot be cast to com.servoy.j2db.persistence.WebObjectImpl
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:132)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:42)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:42)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:141)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:503)
... 25 more
How to fix this?
yes this is a known issue and already fixed.
It is weird that you get it in a normal import, because there sablo code (ngclient) should be there and that cast should work…
How is that WAR created? If you look into that WAR in the “WEB-INF\lib” dir does it have a sablo-xxxxx.jar ?
please next time, test also the RC… this would have been fixed if the RC was tested
It’s a normal export from developer that I wanted to import on the server.
I think testing all rc it’s not my job and I have a lot of other things to do… I assume that something like that was extensively tested by Servoy before final release… but anyway.
I have only updated on our testing appplication server, so no problem right now…
Now I have to wait for 8.2.4, right?
what do you call “application_server” ?
our applicaiton server installation or a WAR export and an deploy of that on a tomcat?
Because what you do is kind of weird. You import a solution that has WebComponents in it… (so ngclient) on an applicaton_server (or WAR without ngclient support)
That is something we don’t really test, because that is kind of a weird thing todo anyway… Because what you import will not work anyway in that deployement
Because the WebComponent can’t be used on a form really at runtime because the support is not in the runtime for that.
I am not talking about export of the solution.
The only way a solution with webcomponents will work is export first a WAR (with NGClient support, that means the active solution must be a normal or ngclient solution)
and then import the solution (or export the active solution right away with it)
A solution with webcomponents won’t really work on an servoy application server install or on a WAR that doesn’t have support for ngclient.
There won’t be a 824, the next release will be 83
But this is why we have RC’s if you don’t start testing that, then these kind of corner cases can happen, because as we said this is not what we test, because we see this as a wrong setup anyway.
Iam using the standard installation of an application server on a Windows Server. Nothing special.
I don’t need any webcomponents because we are using smart and webclient only.
Now I checked all my solutions and found webcomponents in the servoy framework we are using. Your framework has support for the ng-client, therefore I don’t know, why things like that are not tested by Servoy…
I deleted the WebComponent-Packages and deleted the components from the framework forms.
Import runs without problems now.
Thanks
Running the updater from an 8.1 install and I get the following error, preventing from updating.
Downloading…
Exception in thread “main” java.io.IOException: Server returned HTTP response code: 403 for URL: http://download.servoy.com/downloads/8x … e.jar.3036
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.servoy.updater.VersionCheck.downloadNewVersionJar(VersionCheck.java:181)
at com.servoy.updater.VersionCheck.downloadIncrementalNewVersions(VersionCheck.java:235)
at com.servoy.updater.VersionCheck.main(VersionCheck.java:350)
Caused by: java.io.IOException: Server returned HTTP response code: 403 for URL: http://download.servoy.com/downloads/8x … e.jar.3036
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at com.servoy.updater.VersionCheck.downloadNewVersionJar(VersionCheck.java:176)
… 2 more
this is a know issue and reported in 8.2, 8.2.1 and 8.2.2 release
see: viewtopic.php?f=16&t=21872
I updated our productive application server after testing on our test server. Everything was running fine and importing was no problem after deleting the webcomponents.
Today I can’t import my solution again
2018-04-01 12:06:51,506 ERROR [http-nio-8080-exec-3] com.servoy.j2db.util.Debug - java.lang.ClassCastException: com.servoy.j2db.persistence.WebObjectBasicImpl cannot be cast to com.servoy.j2db.persistence.WebObjectImpl [ ]
com.servoy.j2db.persistence.RepositoryException: java.lang.ClassCastException: com.servoy.j2db.persistence.WebObjectBasicImpl cannot be cast to com.servoy.j2db.persistence.WebObjectImpl
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:495)
at com.servoy.j2db.server.Zc.Zhb.importFromJarFile(Zhb.java:124)
at com.servoy.j2db.server.servlets.ConfigServlet.Za(ConfigServlet.java:703)
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:2780)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassCastException: com.servoy.j2db.persistence.WebObjectBasicImpl cannot be cast to com.servoy.j2db.persistence.WebObjectImpl
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:132)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:42)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:42)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:141)
at com.servoy.j2db.server.Zc.Zhb.Za(Zhb.java:503)
... 25 more
I checked all modules and there is no webcomponent and I have no idea what the problem is. How can i find out where the problem is coming from?
It’s a really big solution with about 140 modules and it’s nearly impossible to import every module separate to look which module creates this error…
Since Version 8.2.3 and the next version with the bugfix for my problem above, my cronjobs within the batchprocessor are running at the wrong time.
Example:
scheduler.addCronJob( “batchprozess_” + batchRecord.prozess, “0 30 16 ? * 2-6”, import_ECB_exchangeRates );
Job runs at 01:44 instead of 16:30
scheduler.addCronJob( “batchprozess_” + batchRecord.prozess, “0 0 16 * * ?”, importTalentLMSUserData );
Job runs at 01:44 instead of 16:00
Any ideas?
Is there a mistake in my sourcecode? Think I haven’t done any changes…
Hi Michael,
Your code looks okay.
Did you check if the server it runs on has the correct time?
And can you reproduce it in your developer environment?
Hi Robert,
yes, the server has the correct time, no changes.
Now I started a cronjob on my developer environment and there it’s running fine.
Hi Michael,
So 1:44 is a pretty specific time. And both cronjobs with the different scheduled times ran on that time which is weird.
Do you see this running at that time everyday?
i don’t see how that can be a change in servoy
The scheduler plugin itself hasn’t changed for years.
Also the quartz.jar that it uses is as far as i know the same for many versions (at least 814 and 823 are the same)
Friday I started logging the tasks to see what happend. These are the results:
Today: Both jobs running at 01:44
Yesterday: Only importTalentLMSUserData, that’s correct, but started at 01:18
Sunday: Only importTalentLMSUserData, that’s correct, but started at 01:44
Saturday: th jobs were running friday at 01:55 and
Friday: Both jobs running at 01:44
That’s really weird.
I have daily updates for my solution and every evening I delete all solutions on the application server and import my updated version. Therefore it can’t be a faulty import.
and restarting the serve gives exactly the same effect?
I already replaced the quartz.jar with an older version but without changes.
Hi Michael,
These cronjobs run in a single batch processor? How long do these jobs run normally?
Keep in mind that methods are single threading so if a job is still running then other cronjobs get queued behind it and won’t run until the previous method is done.
On weekend I updated java on the machine to 1.8.0_161. Same effect.
This evening I will install the latest Windows updates and restart the server after that process. Maybe that helps out… I don’t know…
I have more than these 2 cronjobs running in a single batch processor, but the others are running every 20 minutes, every hour etc… All jobs finished within a few seconds.
