-
Bug
-
Resolution: Fixed
-
Low (View bug fix roadmap)
-
5.2.11, 6.0-OD-12/RC1, 6.0
-
Tested on HSQL and PSQL 8.4
Note: MySQL will not allow the character 𠡬
-
5.02
-
NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.
Symptom:
- restoring XML to JIRA 5.2.11 or JIRA 6.0 rc1
- JIRA throws the following error immediately when trying to restore an XML backup data:
java.lang.NullPointerException at java.util.AbstractCollection.addAll(AbstractCollection.java:303) at com.atlassian.jira.imports.project.util.XMLEscapeUtil.unicodeInPlaceEncode(XMLEscapeUtil.java:201) at com.atlassian.jira.imports.project.util.XMLEscapeUtil.unicodeInPlaceEncode(XMLEscapeUtil.java:154)
Steps to Reproduce:
- Create an issue that has the character 𠡬 as a summary or description
- Create an XML backup
- Restore the newly created backup or perform a project import
- The steps will result in an NPE
This is not reproducible when restoring the same XML backup data into JIRA 5.2.10
Root cause
- invalid characters in the XML backup data
Workaround
- fix the data using the XML cleaner on the entities.xml before importing the clean XML backup data . The guide available at here
- Detail workaround steps at https://confluence.atlassian.com/display/JIRAKB/Project+Import+will+lead+to+NPE
- Upgrade to JIRA 6.0.1
- relates to
-
-
- Closed
-
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page"){kind=icon}
[JRASERVER-33019] NullPointerException While Restoring JIRA Data If the XML Backup contains the character 𠡬
Verified successfully using the qa build on both master and stable. The aforementioned character on an issue summary or description does not cause the import to fail anymore.
Technically speaking the problematic character is a 3-byte one (when encoded as UTF-8).
I assume that the problem was caused by Unicode characters outside the BMP.
I wrote new test to check all possible 2-byte characters, found what problem was and fixed it.
I am afraid that this problem is not specific to this Unicode character and could be reproduces with many others. Please be sure you do a proper test, so you can provide a proper fix for the problem.
People can paste a wide range of unicode strings in descriptions or comments.
If character is 3 or 4 bytes it's split by parser into 2 characters and that's the way Java will see it later. That's why testing all 2-byte characters will be enough.