rene.j.bosch_1

I think I cracked it. I don't know for sure this is the solution but at least these changes coincided with differences in behaviour. In de extra <connection> tag in Tomcat's server.xml I initially had the attribute: protocol="http/1.1" Which resulted in the erratice behaviour in Edge and Chrome. I changed that to: protocol="org.apache.coyote.http11.Http11NioProtocol" Which strangely enough had the reverse effect. HTTPS worked fine in Edge/Chrome but no longer in FF. Then I noticed there is a third option: protocol="org.apache.coyote.http11.Http11Nio2Protocol" in other words: with Nio2 in stead of Nio. Again: whether that is actually the solution I'm not 100% sure, but for me it now works fine (and smooth) with all browsers I have available: Edge, Chrome, FF and Safari.

Jasperserver 8.0.0 / Windows Server 2019 After upgrading to Jasperserver 8.0.0. I have set it up to use https rather than http. As mentioned in the documentation I've added a connector in Tomcat's server.xml (port 8443) with a newly created keystore. I changed Jaspersever's web.xml to accept SSL only. Both locally and remotely this works reliably with Firefox and Safari, but not with Chrome based browsers such as Edge and Chrome itself. Using Jasperserver is slow in any case (also with Safari and Firefox), but with Chrome/Edge it is even slower and more often than not ends with a blank screen. Re-executing the URL will - usually after two or three attempts - give the desired result, but it is not really workable. It can happen with any screen: log-in screen, home screen or a report result screen. If I set up the system to use http rather than https, then everything works fine (and fast) with all browsers. Did I do something wrong in the https set-up or missed an important step?

Returning to Jasperreports after many years (back then using iReports) I have problems connecting to SQL Server. Both when using the JTDS or the Microsoft JDBC driver I cannot get a connection to my local SQL Server Express instance using WIndows Authentication. It returns the dreaded "This driver is not configured for integrated authentication" (for the MS driver) or "SSO failed: native SSPI Library not loaded" (JTDS) messages. With other applications (such as SQL Workbench/J) it works like a charm by placing the respective DLL files in the JRE's bin directory (which in that case is a Java 12). In the case of Jaspersoft Studio I placed them a) in the top directory of JasperSoft, b) in its JRE 1.8 bin directory, c) in WindowsSystem32, d) added it to the java.library.path, e) several places in/within the myreports directory, but all to no avail. The funny thing is that a Test in the data adapter seems to work fine the first time you press it ("Succesful!" message, albeit that it is returned suspiciously quickly). But a second press gets the before mentioned errors. Is there some hidden place I need to store the dll files?