We are pleased to announce the availability of Servoy 2021.12 (release number 3722)
Look at the whats new for more info about the 2021.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)
This release is build on Eclipse 2021.09 (4.21)
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 17.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 2021.03.1 LTS and enabled only the lts update site.
Congratulations on the new release!
I just downloaded the Mac version, but it seems to be just the ‘Intel’ version, how do I get the new Apple Silicon M1 (Universal) version?
Thanks
Rafi
in application_server\lib we strip the versions (for most of them) because of our legacy application server (else the batch files, wrapper confs that we had constantly needs to change)
thats why log4j-slf4j-impl.jar is also called like that and not log4j-slf4j18-impl.jar
so the files are not different, they just have a different name…
Also if you use a tool/scanner and that reports that as a problem then immediately stop using that tool, because a tool never should look at the file names, but actually at the file contents (so META-INF/manifest.mf)
Upgraded to 2021.12, updated packages, built war file. When i try and deploy the war file on our test server Tomcat is unable to start our app.
contents of mananger.log
05-Jan-2022 14:16:58.742 INFO [http-nio-80-exec-1] org.apache.catalina.core.ApplicationContext.log HTMLManager: init: Associated with Deployer ‘Catalina:type=Deployer,host=localhost’
05-Jan-2022 14:16:58.743 INFO [http-nio-80-exec-1] org.apache.catalina.core.ApplicationContext.log HTMLManager: init: Global resources are available
05-Jan-2022 14:16:58.757 INFO [http-nio-80-exec-1] org.apache.catalina.core.ApplicationContext.log HTMLManager: start: Starting web application ‘/aquarius’
05-Jan-2022 14:17:00.228 SEVERE [http-nio-80-exec-1] org.apache.catalina.core.ApplicationContext.log HTMLManager: Error starting [/aquarius]
org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/aquarius]]
at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1418)
at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:703)
at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:223)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:652)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:211)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:667)
at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:378)
at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:56)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:374)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1707)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.SecurityException: class “org.apache.logging.log4j.core.lookup.ConfigurationStrSubstitutor”'s signer information does not match signer information of other classes in the same package
at java.base/java.lang.ClassLoader.checkCerts(ClassLoader.java:1151)
at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:906)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1015)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2432)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:864)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1333)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1187)
at org.apache.logging.log4j.web.WebLoggerContextUtils.getWebLifeCycle(WebLoggerContextUtils.java:86)
at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:56)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5166)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
… 35 more
05-Jan-2022 14:17:00.230 INFO [http-nio-80-exec-1] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host ‘localhost’
you seem to have multiply jars of log4j that are not only ours…
because you have signing differences between jars (of log4j) that shouldn’t be there
Did you stil have some left overs of your own patch that you maybe applied?
What is the directory contents of the xxx.WAR/WEB-INF/lib folder? (war is just a zip)
Since updating to 2021.12.0 we are getting the following error logged whenever we try to create a JWT token:
ERROR plugin.jwt - Cannot create algorithm. Both public and private keys cannot be null.
ERROR plugin.jwt - The Algorithm cannot be null.
WARN com.servoy.j2db.util.Debug - A token could not be generated. Check JWT plugin configuration / server secret.
at /Users/stevehawes/Dropbox/git/tsp/svySecurity/svySecurity.js:3015 (logWarning)
at /Users/stevehawes/Dropbox/git/tsp/svySecurity/svySecurity.js:3495 (setToken)
at /Users/stevehawes/Dropbox/git/tsp/svySecurity/svySecurity.js:299 (login)
I have checked and there is definitely a secret set.
steve1376656734:
Since updating to 2021.12.0 we are getting the following error logged whenever we try to create a JWT token:
ERROR plugin.jwt - Cannot create algorithm. Both public and private keys cannot be null.
ERROR plugin.jwt - The Algorithm cannot be null.
WARN com.servoy.j2db.util.Debug - A token could not be generated. Check JWT plugin configuration / server secret.
at /Users/stevehawes/Dropbox/git/tsp/svySecurity/svySecurity.js:3015 (logWarning)
at /Users/stevehawes/Dropbox/git/tsp/svySecurity/svySecurity.js:3495 (setToken)
at /Users/stevehawes/Dropbox/git/tsp/svySecurity/svySecurity.js:299 (login)
I have checked and there is definitely a secret set.
at first glance that looks like a regression, because we check something (and throw that error if not everything is set) a bit to soon because the it could go on without that in this specific example
will have a look at it
When you upload files using the MultiFile Upload component, the onFileUploaded method receives a JSUpload object and if you call the getName() method of that object it is now returning a UUID instead of the actual filename. As far as I can see there is now no way to get the filename from the JSUpload object which is a big problem for us.
I guess that is because of the new TUS protocol use in the Uppy plugin we use for file upload.
The thing is it seems to work in NG2 but not in NG1 so i think we mis some setting/configuration in the ng1 multi file upload component
i fixed the MultiFileUpload problem in NG1: https://support.servoy.com/browse/SVY-16772
was a bit tricky to find, but yes in NG1 we did a initialization for something property (Tus) that shouldnt be done (and what we didn’t do in NG2 impl). That was causing an extra filter over the metaData fields which shouldn’t happen.
This is purely in the ServoyExtraComponents webpackage. so i will make a release for this in the next week.