ghudson_1
-
Posts
284 -
Joined
-
Last visited
-
Days Won
3
ghudson_1's Achievements
-
This error only occurs when mysql is the repo db and is harmless, no impact on functionality (though messy log.) A defect on this is targeted for the upcoming release.
-
Issue DescriptionAfter customizing javascript files you can re-run steps to optimize the files for the sake of performance as described here: https://community.jaspersoft.com/documentation/tibco-jasperreports-server-ultimate-guide/v790/customizing-javascript-files A customer who uses visualize.js performed the steps above but then encountered an error in the browser console: Uncaught Reference Errors It was complaining about an error within visualize.js ResolutionIf you embed via visualize.js there is an additional step to perform between steps #9 and #10 in the documentation above. From the "Working" directory, run a command specific to visualize, passing in your own "js-optimization-output" directory in the "out" arg: nodejsnode r.js -o js-sourcesscriptsvisualizebuild.js optimize=uglify2 out=c:Usersghudsontestjs-optimization-outputvisualizevisualize.js This applies to JasperReports Server versions 7.5, 7.8, 7.9 Ref. Case 01935688
-
Issue DescriptionA stale apt-get repository resulted in a restart error of an image. Months ago a customer used the TIBCOSoftware/js-docker scripts to build a docker image. They needed to restart the container, upon restart a failure occurred: E: Failed to fetch http://deb.debian.org/debian/pool/main/s/systemd/systemd_241-7~deb10u5_amd64.deb 404 Not Found [iP: 1 99.232.130.132 80] E: Failed to fetch http://security.debian.org/debian-security/pool/updates/main/c/chromium/chromium-common_87.0.4280.141-0 .1~deb10u1_amd64.deb 404 Not Found [iP: 151.101.250.132 80] E: Failed to fetch http://security.debian.org/debian-security/pool/updates/main/c/chromium/chromium_87.0.4280.141-0.1~deb1 0u1_amd64.deb 404 Not Found [iP: 151.101.250.132 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? ResolutionThe ENTRYPOINT calls chromium-setup.sh which involves this command: apt-get install -y --no-install-recommends chromium. The failure occurs because the apt-get command is using an outdated package repository, in part because the image was built months ago and no statements indicated that apt-get should be refreshed. To fix this problem you can add a command for "apt-get update" on line 30 of chromium-setup.sh prior to the "apt-get install -y --no-install-recommends chromium", which should refresh the package repository. You'll need to rebuild the image. Another option is to move the apt-get install directive for chromium out of the scripts called during the ENTRYPOINT and move them into the dockerfile. Theoretically you can also just perform a new "git clone" if you only have short-term needs, but be mindful of Docker's build cache which will try to re-use unchanged instructions from prior dockerfiles for the sake of build performance. If you already have builds of the same dockerfile you can bypass build cache by adding "--nocache" to your build command, see https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache . Ref. Case 01931613
-
Issue DescriptionA customer upgraded from Studio 7.2 to 7.9 and encountered an error while previewing reports with HTML5 charts: net.sf.jasperreports.engine.JRRuntimeException: Chrome and/or PhantomJS not properly configured for server side rendering ResolutionStudio wasn't able to locate the chrome.exe application. To resolve this error we set a property. Via Window->Preferences-> Jaspersoft Studio -> Properties you can add: net.sf.jasperreports.chrome.executable.path with a value containing the full path for the chrome.exe on your harddrive. If you do not have Chrome/Chromium installed, you can download Chrome or Chromium during installation. For example in Win 10 this might be: C:/Program Files (x86)/Google/Chrome/Application/chrome.exe Ref. Case 01920486
-
If so, try this in a textfield expression of a test jrxml report:<![CDATA[((javax.servlet.http.HttpServletRequest)$P{REPORT_PARAMETERS_MAP}.get("HTTP_SERVLET_REQUEST")).getHeader("X-Forwarded-Host")]]>[/code]Or modify your appserver's logging, here's an example for tomcat: https://community.jaspersoft.com/wiki/add-header-tomcat-access-log-valve Additionally, something a little more superfluous would be to dump the entire http request (minus the body) via apache's RequestDumperFilter servlet: https://www.stackextend.com/java/tomcat/tomcat-debugging-tips-trace-full-request-content-of-all-coming-requests/
-
Add header to Tomcat Access Log Valve
ghudson_1 posted an entry in Troubleshooting
ghudson_1 posted an entry in Troubleshooting
Issue DescriptionWhen trouble-shooting issues involving proxies, authentication, etc it is sometimes helpful to determine exactly what inbound HTTP header values are hitting your appserver prior to entering the TIBCO JasperReports® Server servlet-based webapp. ResolutionTomcat's AccessLogValve provides basic webserver-style logging of http requests. Edit your tomcat's server.xml and add or adjust the AccessLogValve, for reference see https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html In the example below i'm logging four potential HTTP headers in addition to typical items you'd prefer to have like url, time, ip, etc: host HOST X-Forwarded-Proto X-Forwarded-Host <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%{host}i %{HOST}i %{X-Forwarded-Proto}i %{X-Forwarded-Host}ii %h %l %u %t "%r" %s %b" />[/code]A restart is required. The resulting logging in this example would be found in your /logs/localhost_access_log..txt -
This is broken as of Studio 7.3.1, but resolved as of 7.8.0
-
#MISFIRE_INSTRUCTION_SMART_POLICY=0 single job: #MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY=-1 #MISFIRE_INSTRUCTION_FIRE_NOW=1 simple repeating job: #MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY=-1 #MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT=5 #MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT=4 #MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT=2 #MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT=3 calendar/cron job #MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY=-1 #MISFIRE_INSTRUCTION_FIRE_ONCE_NOW=1 #MISFIRE_INSTRUCTION_DO_NOTHING=2[/code]
-
Yes, you can create a Tomcat user with a home directory and Install JasperServer as that user (the required files are now where they "should" be), but this isn't necessary.Instead, install as anyone you want (root, or any non-root user that can execute the scripts and add files), then you'll need to move the resulting encryption files to a location readable by the user running tomcat, do so follow step #2 here.https://community.jaspersoft.com/wiki/how-move-tibco-jasperreports-server-750-encryption-keystore-files-shared-linux-folder Or use step #1 from the same link above in conjunction with the WAR file installation approach to specify the optimal location for the resulting encryption files in advance.
-
1. It is with 100% confidence that I assure you SSL is not related to the original errors you posted above, which were: "Could not locate: org.apache.commons.configuration2.io.FileLocator@29942be5[fileName=.jrsksp,basePath=/root" Background info a) The JRS installation scripts don't really care which appserver you are using, there is a small config difference on deployment, but for the most part deployment is largely just exploding the .WAR into the proper dir. So they definitely don't know or care whether or not a certificate has been created and associated with tomcat configurations. Background info b) The main reason for the keystore and related files is to encrypt sensitive info within the repo database (like db connection passwords you define for datasources, user passwords etc). This is mandatory step for installation and startup, since the webapp needs to be able to read the keys to know how it should decrypt the encrypted values stored within the repository DB tables (otherwise passwords will all be broken due to mis-decryption, etc). The code creating the keystore has ZERO knowledge of the underlying appserver. Since it has zero knowledge of the underlying appserver it also has zero knowledge of whether or not SSL certs have been created, associated with your appserver, etc. I hope the above helps you no longer doubt whether or not SSL needs to be setup. 2. Initially you said the .jrsks and .jrsksp files don't exist in /root, but it sounds like they do. I need to repeat my prior question: "So does the user running tomcat have the ability to see/read those files?" If not, then you can follow the wiki articles which instruct how to move the files to a readable location like /opt/tomcat/myKeyFilesDir, update the files (with the new location info) and update the keystore.init.properties.
-
The .jrsks and .jrsksp files are indeed in /root? The original error was: "Could not locate: org.apache.commons.configuration2.io.FileLocator@29942be5[fileName=.jrsksp,basePath=/root" So does the user running tomcat have the ability to see/read those files? If not, then you can follow the wiki articles which instruct how to move the files to a readable location, update the files (with the new location info) and update the keystore.init.properties.
-
Two comments ago I asked a few questions, can you address those? Regarding my last point, specifically, what's in /opt/jasperreports-server-cp-7.8.0/buildomatic/keystore.init.properties and your /opt/jasperreports-server-cp-7.8.0/webapps/jasperserver-pro/WEB-INF/classes/keystore.init.properties I'd expect "ks=/root" since your log says "user_home_directory: /root" Thus i'd also expect the hidden ".jrsks" file to be in /root, but let's see what those files say.
-
Can you attach the install log to the orig post? I see the tomcat log, but not the install log
-
You indicated "same old same old errors (as above).", but the errors above are unrelated to postgres. Are you now seeing different errors? If so, paste the stacktrace with the "caused by" The keystore related errors have nothing to do with the DB and nothing to do with the appserver. Scripts make java encryption related calls and add a few files. In some use-cases the files are in the wrong places or have the wrong data, and this can result in the stacktrace you posted above. So if you have new errors, post em. If you have the original "Could not locate: org.apache.commons.configuration2.io.FileLocator@6ed28dd8[fileName=.jrsksp" then a) search your drive for the ".jrsksp" file, and see what the keystore.init.properties file lists as the location of the files. You can post the contents of the keystore.init.properties too
-
The git error is harmless. Do you see see .jrsks and .jrsksp anywhere if you search the box? If you edit the original post/question, you can add an attachment.
