Ensure JFS Patch for JIRA Is Installed

These signs indicate that JFS patch for JIRA has not been installed properly:

  • Custom field values are hidden from Issue View, but stay visible in Change History;
  • Changed values are visible in Activity Streams;
  • Hidden values are visible in Issue Print View or in MS Word representation.

If you experience one of these problems, you should download proper JFS patch for JIRA and reinstall it according to JFS Installation&Upgrade Guide. Please pay extra attention to the folder you are unpacking the patch archive.

To check if the patch is applied:

  • Navigate to Administration -> System Info;
  • Modified Files section should look like this:

    [Installation Type: Standalone] secure/views/issue/moveissue-confirm.jsp, jira-application.properties, secure/views/issue/convertissuetosubtask-confirm.jsp, com/atlassian/jira/issue/history/ChangeLogUtils.class, entitydefs/entitymodel.xml, templates/plugins/issueviews/single-word.vm, com/atlassian/jira/issue/history/ChangeItemBean.class, templates/plugins/jira/issuetabpanels/changehistory.vm, com/atlassian/jira/plugin/atlassian-bundled-plugins.zip, com/atlassian/jira/issue/fields/CustomFieldImpl.class

    If it looks like the one below - the patch has not been applied properly:

    [Installation Type: Standalone] jira-application.properties, entityengine.xml, secure/admin/user/views/userbrowser.js

Non-English Symbols Get Corrupted

If you are using non-English language and your default operating system encoding is not UTF8  (usually on Windows system), it is required to set Java default encoding to UTF8 . To do this: set Java property file.encoding to UTF8: -Dfile.encoding=UTF8.
You can find more info on how to set Java property for Tomcat installed as a Windows Service here: http://confluence.atlassian.com/display/JIRA/Setting+Properties+and+Options+on+Startup#SettingPropertiesandOptionsonStartup-TomcatinstalledasaWindowsService%3A

Unable to Install the License Code

Symptoms

Exception stack trace is shown when trying to install JFS license code:

java.lang.NoClassDefFoundError: javax/persistence/spi/PersistenceProvider
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2957)
...

The license code could not be installed.

Cause

This is due to interference with JavaMelody plugin.

Workaround

  1. Temporarily remove JavaMelody plugin from the system
    1. Stop JIRA
    2. Remove JavaMelody JAR from WEB-INF/lib (deactivating JavaMelody via UPM is not enough)
    3. Start JIRA
    4. Install JFS license
    5. Stop JIRA
    6. Place JavaMelody JAR back to WEB-INF/lib
    7. Start JIRA
  2. OR place the code directly to jfs-settings.xml file 
    1. The jfs-settings.xml file is located in JIRA_HOME/jfs folder
    2. Make a backup copy of the file
    3. Place the code inside <licenseRawCode> tag
    4. Save the file
    5. Restart JIRA

Both plugins should work fine now, but you still will not be able to update JFS license while JavaMelody is present in the system

Uncontrollable Log File Growth

Symptoms

When a user performs an export of search results to CSV JIRA log files are flooded with stack traces as below which causes an uncontrollable log file growth.

2017-01-18 14:21:02,576 http-apr-8080-exec-707 WARN abcd 860x19727349x2 uo3kh5 172.200.50.127,172.210.64.12 /sr/jira.issueviews:searchrequest-csv-all-fields/temp/SearchRequest.csv [c.q.j.f.issue.export.DelegatingCustomFieldType] this should never be called: java.lang.Throwable
                at com.quisapps.jira.fieldsecurity.issue.export.DelegatingCustomFieldType.warn(DelegatingCustomFieldType.java:34)
                at com.quisapps.jira.fieldsecurity.issue.export.DelegatingCustomFieldType.getValueFromIssue(DelegatingCustomFieldType.java:117)
                at com.quisapps.jira.fieldsecurity.issue.export.SecureCsvIssueExporter$CustomFieldMethodInterceptor$1.getValueFromIssue(SecureCsvIssueExporter.java:149)
                at com.atlassian.jira.issue.export.customfield.DefaultCsvIssueExporter.getFieldExportRepresentationForCustomField(DefaultCsvIssueExporter.java:144)
                ...

Cause

This is due to the interference with a third-party add-on, which does not support the new 'Export to CSV' feature correctly. This feature was introduced in JIRA 7.2. 

Fix

Upgrade to JFS v1.4.36 or later.

Workaround

  • Set Logging level to ERROR on the JFS Settings page

OR

  • Navigate to Logging and Profiling at JIRA Admin and set logging level for com.quisapps.jira.fieldsecurity.issue.export.DelegatingCustomFieldType to ERROR

Disabling "Block Unknown URLs" Setting

Before creating a support request try to disable Block Unknown URLs setting at Administration -> Field Security -> JFS Settings.

Preparing Data for Support Request

  1. Navigate to Administration->Field Security->JFS Settings and:
    1. Set Logging Level to TRACE;
    2. If the error is related to SOAP or XML-RPC API: set "Dump Request & Response Data to File" option to ON;
    3. Click the Save button to submit changes;
  2. Perform actions that are causing the error;
  3. Navigate to Administration->Field Security->JFS Settings and disable extended debugging by setting Logging Level to INFO and "Dump Request & Response Data to File" option to OFF; click Save button to submit;
  4. Attach JIRA log file and application server log file to the support request (see this page for how to find log files; choose your JIRA version);
  5. If the error is related to SOAP or XML-RPC: navigate to /jfs/tmp subfolder in the JIRA home folder of your instance, archive its content with any common archiver (e.g. ZIP) and attach to support request.

Please note that log files and/or dump files may contain some sensible information. We recommend choosing any sample JIRA issues for reproducing erroneous behavior. Furthermore, we hereby confirm that a) we will use any submitted data only for debugging purposes, a) we will not share this data with anyone without written permission of the owner and c) we will permanently delete all submitted data upon completion of the support request or if requested by the owner.

  • No labels