ghudson_1
-
Posts
284 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forum
Events
Featured Visualizations
Knowledge Base
Documentation (PDF Downloads)
Blog
Documentation (Test Area)
Documentation
Dr. Jaspersoft Webinar Series
Downloads
Posts posted by ghudson_1
-
-
This is broken as of Studio 7.3.1, but resolved as of 7.8.0
-
- 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.
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.
-
There is nothing in docs about how to install without SSL because SSL is unnecessary, unneeded. Sorry if my comments above weren't clear, but to repeat, SSL is NOT needed to start, run, and use JRS. My 7.8.0 on centos has no SSL setup, my 7.8.0 on windows also has no SSL setup. APR and TC native are specific to Tomcat, correct? 1. JRS can run on many different appservers, 2. the buildomatic install scripts don't rely on the appserver, only your JDK (java code is execute, jdbc connections are made to the db, and file are copied to some appserver's deployment dir)
Regarding "there isn't any .jrsksp file" - then the install failed, and should be noted in the install log.
The install scripts will try to create the .jrsks files in the home dir of the user performing the install. Via default steps, the webapp will look for those files in the place where the install scripts attempted to create them.
-
Regarding the startup error (which is causing the chain of bean errors), the "cause by" in the stacktrace says :
Could not locate: org.apache.commons.configuration2.io.FileLocator@6ed28dd8[fileName=.jrsksp,basePath=/root,sourceURL=,encoding=ISO-8859-1,fileSystem=com.jaspersoft.jasperserver.crypto.utils.Base64SynchronizingFileSystem@752983fd,locationStrategy=com.jaspersoft.jasperserver.crypto.utils.JrsBasePathLocationStrategy@1897850a]
Is it possible tomcat is running as some user that is different than the user who performed the install? If so, the tomcat user would be looking in it's own user.dir for the files and wouldn't find them (since they'd be located in the user.dir of the person who did the install)
So is the .jrsksp file at /root? is it readable?
-
JRS is just a servlet-based webapp. You can deploy it into tomcat, jboss, websphere, and others, and no SSL certs need be present. So regarding "APR and TC-Native", are these things required for your setup of Tomcat?
-
Thanks mfarmer!
Jaspersoft Support is filing a bug against 7.5.x now.
Try removing mail-1.4.5.jar
-
Are Studio and the java app on the same machine? If not, fonts could be the issue, and font extensions the resolution.
-
.getEnd() or .getStart() will return the actual java.util.Date value if that's what you need.
http://jasperreports.sourceforge.net/api/net/sf/jasperreports/types/date/DateRange.html
-
yes - the JVM's ram/memory/heap
It is asynchronous and are parts are session-bound. For example the specific IDs in /<requestId>/exports/<id> are only accessible via the user-session which originated the request.
Session expiration set to zero would be bad, don't do that or you'll eventually encounter an out of memory exception (and wonky stuff will occur prior).
-
When using reportExecutions the report stays in memory on the server, similar to the filled JRPrint object that gets filled before being flushed out during an export in JRS UI use-cases, for example from the UI ReportViewer to PDF. The JRPrints stay in memory entirely unless they are so huge page-wise that virtualization kicks in (and you can search wiki/community for details on virtualization if needed).
It stays for the duration of the user-session which made the reportExecutions call. (see web.xml for session timeout)
-
If you have a commercial (aka professional) license, you can create a case for Tibco Jaspersoft technical support in your portal - http://support.tibco.com
-
JRXML reports use Java expressions by default, they aren't using something proprietary. And at the report element level you can also define them to use groovy instead of even javascript. So I recommend you grab a java developer or groovy developer and have them provide you syntax.
-
HTML export relies on the client-Browser (chrome, firefox, etc) to fetch the true font from the OS.
PDF doesn't have this ability, so if you aren't referencing one of the handful of 'CORE' fonts which are part of the PDF Spec/Standard, then you actually embed the ttf in the PDF. Easiest way to do this is via Font extensions, see the font extensions chapter in the Studio User Guide.
-
Could be this, eh?
https://bugs.openjdk.java.net/browse/JDK-8140601
for grins & giggles i'd try installing and using a different JDK on the client.
-
Via Font Extensions you can add entire font Family for use. Font Extensions are discussed in the Studio Guide. This will make the entire set available for use in the report. iText API is called when the PDF is actually created. Do you see something in iText regarding your issue with how the font is actually being embedded? Can you provide more info?
-
Sounds like you are already familiar with passing attributes into a domain, but if not, and you had a way of setting attributes dynamically you could pass them into a derived table:
http://community.jaspersoft.com/wiki/using-attributes-domains-derived-table
Attributes can be set via REST api... so theoretically some third party app could post new values into a user's profile dynamically.
-
You cannot parameterize derived tables directly in JRS 6.3.0 or prior. In some future version they hope to have the ability to reference parameters in derived tables.
Have you considered creating Ad Hoc Views from topics that are domain based? Using Studio, you create a new jrxml report with queries against your domain, and these queries within Studio can be parameterized (via typical jrxml parameters). And of course you define the fields. Then publish this report to the JRS topics folder, then create your Ad Hoc View from this topic.
-
Since 4.5, Jasper Reports Server has built-in security validation which uses regex to prohibit things like delete statements within SQL queries (other sql injection):
http://community.jaspersoft.com/wiki/jaspersoft-security-changes-and-configuration
Of course this is JRS, not the development tools like Studio.
Error "JasperServerMaintenanceScheduler_Worker-2:131 - You can't specify target table 'JIAccessEvent' for update in FROM clause" - JasperReportServer 7.8.0
in Products
Posted
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.