We need to import ~500-2000 issues daily from a legacy ticketing system. Many will be duplicates. We created a validator to locate the duplicates (based off their unique summary) and prevent their creation. The import is performed by end-users on our team, using the issue -> 'import from csv' link
We see a "Fatal error during import" everytime we use the validator
2016-05-05 07:51:29,439 INFO - Importer started!
2016-05-05 07:51:29,440 INFO - Engine is running in Import mode
2016-05-05 07:51:29,450 INFO - All issues will be imported to project: TestProject (TEST)
2016-05-05 07:51:29,454 INFO - Creating issue: ExternalIssue
{externalId=autoid-4493924815619197614, summary=CM1, issueType=CM Unknown Subtask}
2016-05-05 07:51:29,693 ERROR - Fatal error during import
java.lang.NullPointerException
at com.atlassian.jira.config.DefaultSubTaskManager.createSubTaskIssueLink(DefaultSubTaskManager.java:582)
at sun.reflect.GeneratedMethodAccessor2522.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.atlassian.plugin.osgi.hostcomponents.impl.DefaultComponentRegistrar$ContextClassLoaderSettingInvocationHandler.invoke(DefaultComponentRegistrar.java:134)
at com.sun.proxy.$Proxy484.createSubTaskIssueLink(Unknown Source)
at sun.reflect.GeneratedMethodAccessor2522.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)
at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:56)
at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:39)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy4201.createSubTaskIssueLink(Unknown Source)
at com.atlassian.jira.plugins.importer.imports.importer.impl.CompatibilityUtil.createSubTaskIssueLink(CompatibilityUtil.java:137)
at com.atlassian.jira.plugins.importer.compatibility.CompatibilityBridgeUtils.createSubTaskIssueLink(CompatibilityBridgeUtils.java:172)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.createSubTaskLink(BulkCreateDataImporter.java:326)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImportSubtasks(BulkCreateDataImporter.java:298)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.runImporterEngine(BulkCreateDataImporter.java:175)
at com.atlassian.jira.plugins.importer.imports.bulkcreate.engine.BulkCreateDataImporter.doImport(BulkCreateDataImporter.java:148)
at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:26)
at com.atlassian.jira.plugins.importer.imports.importer.impl.ImporterCallable.call(ImporterCallable.java:15)
at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:528)
at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:491)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:254)
at java.lang.Thread.run(Thread.java:745)It doesn't matter if its a subtask, or a new issue its always resulted in the issue.
The validator looks like this,
the validator is a "Validation based on JQL query"
JQL Query:
project = "Project Name" AND summary ~ "%{00000}"
Condition: number of issues returned by the JQL query satisfies a boolean expression, with "Ephemeral number 1" (code
{00058}) storing the number of returned issues
Boolean expression:
{00058} = 0
Anybody have any ideas on how we can use this to prevent duplicates without it error out? Ive tried this as an administrator and it throws the same errors as well. We have attempted to import with a clean CSV file thats two lines long to ensure its not related to bad CSV data - and we always face the same issue.
Thanks!
To be honest I was in a real hurry when I was installing this upgrade and don't remember exactly what fixed it. However, I can give you a few things to check.
Make sure the docbase is set to the right war file in Tomcat's server.xml file and that it's actually loading it. I think my problem was I had an older expanded version of Jira in the webapps folder. I'm not a Tomcat expert but it seemed to me that Tomcat was using this expanded version and ignoring the new WAR file. I deleted the expanded Jira code in the webapps folder and that forced Tomcat to deploy the new WAR file.
Also, make sure jira.home is set to the current home directory. When upgrading I'll create a new home directory just in case I need to backout to the old version.
Again, sorry I can pin down the root cause of the problem.
Mike
I'm getting the same issue, with Jira 6.2.5 WAR. Followed the link but I don't have the argument (and also using Java 6).
Any suggestions?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, this stack trace refers to this kb: https://confluence.atlassian.com/display/JIRAKB/Upgrade+failed+due+to+UnsupportedOperationException
You may want to check whether this is the case.
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.