Jump to content
We've recently updated our Privacy Statement, available here ×

ghudson_1

Members
  • 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

    • 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. 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.

  2. 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.

  3. 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.

  4. 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

     

  5. 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.  

  6. 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?

     

     

     

  7. 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).

  8. 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)

     

     

     

  9. 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.

  10. 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?

  11. 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.   

     

     

     

     

×
×
  • Create New...