Commonly Asked RPC Questions and Known Issues

Have you searched the forum / JAC? Have you tried searching the Atlassian forum and Issue Tracker? You should. Most of the questions have been asked and answered over and over and over. These are some other useful links for finding an answer: Creating a SOAP Client Creating a XML-RPC Client

Common Problems

Couldn't build RPC Plugin due to NullPointerException

If you are getting NullPointerException and a stack trace which looks similar with the one described here, you may need to disable unit testing in project.xml for a smooth build as mentioned in the previous link.

Getting InfrastructureException or ClassCastException upon invocation

If you are getting ClassCastException or com.atlassian.jira.InfrastructureException upon invocation, it is likely that you are providing the incorrect data types in the arguments.

If you have double-checked that your code is correct and the error still occurs, it is highly likely that autotyping is the culprit. This can be easily solved by disabling autotyping or to explicitly declare the type of arguments.

SOAP

Converting to type as defined in WSDL

Sometimes you may encounter problem in mapping the correct data type of your programming language to the one defined in WSDL. The best answer to this is to refer to the user guide or API documentation of the client library you are using, e.g. WSDL<->Java mapping, Python's SOAPpy, etc.

Changing the authentication token timeout value

The timeout value of the token (which obtained once you've logged in) is defined by the DEFAULT_TIMEOUT constant in current com.atlassian.jira.rpc.auth.TokenManager implementation, i.e. com.atlassian.jira.rpc.auth.TokenManagerImpl.

Providing schemes to method's arguments

Users usually are unsure about whether they should construct or retrieve the scheme object(s) which will be passed to an argument. For your understanding, internally, the RPC plugin recognizes just the id of the scheme, hence the name, type, description, etc. are usually insignificant.

Could not update an issue with a RemoteIssue object

Of course you can't because it is not how it is defined in the WSDL, i.e. the createIssue() method expects a RemoteIssue object as its argument and updateIssue() expects an array of RemoteFieldValue object.

Setting the value of cascading select customfield

The way of setting the value of a customfield upon creation and update are different as mentioned above. The right way of setting the value of a cascading select customfield is even more tricky:

• While creating an issue, the parent field is set by providing the customfieldId and values (single-element array with option's id) and the child field is set by providing the customfieldId, key (as 1) and values.

• While updating an issue, the parent field is set by providing value (a single-element array with option's id) to the customfieldId and the child field is set by providing value to the customfieldId:key (key as 1, e.g. customfield_10000:1).

The same logic applies to XML-RPC, see this example.

Could not invoke methods due to session invalidation

There are some users who hit into IllegalStateException when trying to invoke the RPC methods, for instance:

java.lang.IllegalStateException: getAttribute: Session already invalidated
	at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:221)
	at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:128)
	at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:633)
	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:719)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1685)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
	at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
	at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
	at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
	at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
	at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
	at org.apache.axis.client.Call.invokeEngine(Call.java:2754)
	at org.apache.axis.client.Call.invoke(Call.java:2737)
	at org.apache.axis.client.Call.invoke(Call.java:2413)
	at org.apache.axis.client.Call.invoke(Call.java:2336)
	at org.apache.axis.client.Call.invoke(Call.java:1793)
	at com.atlassian.jira.rpc.soapclient.JirasoapserviceV2SoapBindingStub.getFieldsForAction(JirasoapserviceV2SoapBindingStub.java:3414)

This is actually a bug being tracked at JRA-8009. Please contribute to the issue if you encounter into this problem.

Getting fixed targetNamespace

This is actually a bug being tracked at JRA-10849. The targetNamespace of the WSDL is defined by the first request to it.

Having concurrency problem with multiple issue update

Constantly or simultaneously updating an issue causes data inconsistency of the issue. This issue is currently being tracked at JRA-11382.

Could not invoke user-group methods due to deserialization or invalid element problems

Some Python (SOAPpy) users reported that their client ran into deserialization problem or invalid element problems while invoking the addUserToGroup() method, e.g.

<Fault soapenv:Server.userException: org.xml.sax.SAXException: No deserializer defined for array type {http://soapinterop.org/xsd}SOAPStruct: 
<SOAPpy.Types.structType detail at 1085258540>: {'hostname': 'atlassian01.contegix.com', 'faultData': <SOAPpy.Types.structType faultData at 
1084456684>: {'exception': None, 'message': 'No deserializer defined for array type {http://soapinterop.org/xsd}SOAPStruct'}}>
Traceback (most recent call last):
File "./soapclient.py", line 58, in ?
soap.addUserToGroup(auth, group, user)

SOAPpy.Types.faultType: <Fault soapenv:Server.userException: org.xml.sax.SAXException: Invalid element in com.atlassian.jira.rpc.soap.beans.
RemoteGroup - email: <SOAPpy.Types.structType detail at 29991600>: {'hostname': 'bruwa116', 'faultData': <SOAPpy.Types.structType faultData
at 29991680>: {'exception': None, 'message': 'Invalid element in com.atlassian.jira.rpc.soap.beans.RemoteGroup - email'}}>

The workarounds suggested in these issues are proven working: JRA-7920 and JRA-7971

Using the addActorsToProjectRole method

The JiraSoapService.addActorsToProjectRole() method, internally invokes the ProjectRoleService.addActorsToProjectRole() method. You have to provide either an array of users or groups based on the actorType value, i.e. UserRoleActor.TYPE or GroupRoleActor.TYPE.

For example,

jiraSoapService.addActorsToProjectRole(token, new String[]{"admin", "foo", "bar"}, projectRole, project, UserRoleActor.TYPE);

Could not upload attachments to an issue due to OutOfMemoryError

There are quite a number of users reported that their Java (Axis) SOAP client ran into problem, i.e. OutOfMemoryError while attaching files to an issue. This seems to be an Axis 1.3 problem and the issue is currently being tracked at JRA-11693.

Getting content-type complaint with .NET client

This seems to be the problem of .NET web service library. Please contribute to JRA-11515 if you encounter the similar problem.

Other Known Issues

These are some commonly known issues which have already been raised at our issue tracker. As the source code of the RPC plugin is freely available for you to modify, you may like to manually patch or customize them.

Setting the reporter value upon issue creation?

If you are not able to set the reporter value (to someone other than the current SOAP client) even though it is provided, you may be using the old RPC plugin (3.6.x and older). This improvement (JRA-8794) is delivered in the latest version (3.7.x onwards).

Logging work to an issue

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-7260 with your comments and vote.

Updating user information

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-11252 with your comments and vote.

Deleting version

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-11532 with your comments and vote.

Creating subtask

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-6896 with your comments and vote.

Changing status and resolution of an issue

The only way to set the status and resolution of an issue is by invoking the progressWorkflowAction() method. Feel free contribute to the issue at JRA-10472 with your comments and vote.

Posting comment while progressing workflow

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-11278 with your comments and vote.

Setting comment "Viewable By" security

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-11278 with your comments and vote.

Getting required and available fields for issue creation

Unfortunately, this is not supported at the moment. Feel free contribute to the issue at JRA-11597 with your comments and vote.

XML-RPC

Please take note that some of the XML-RPC common questions are closely related with the ones in SOAP as part of the functions of the XML-RPC service are using SOAP service underlyingly. Ergo, they may not be re-mentioned here.

Could not create and update issue with same Dictionary

Internally, JIRA's XmlRpcService uses SOAP to create and update an issue. Due to this reason, the Dictionary (or Hashtable, or Map) argument in createIssue() and updateIssue() are different as explained above.

This Perl XMLRPC::Lite example demonstrates how an issue is created and updated:

# Create an issue with a RemoteIssue structure

$jira->call("jira1.createIssue", $auth, {
  "project" => "MYC",
  "type" => 1,
  "reporter" => "admin",
  "assignee" => "admin",
  "summary" => "Issue created via Perl XMLRPC :)",
  "customFieldValues" => [
    {"customfieldId" => "customfield_10000",
     "values" => [SOAP::Data->type(string => "10000")]
    },
    {"customfieldId" => "customfield_10000",
     "key" => "1",
     "values" => [SOAP::Data->type(string => "10002")]
    }
  ]
});

# Update an issue with field-values pairs

$jira->call("jira1.updateIssue", $auth, "MYC-3", 
  {"customfield_10000" => [SOAP::Data->type(string => "10000")],
   "customfield_10000:1" => [SOAP::Data->type(string => "10002")]
  }
);

Setting the value of cascading select customfield

Please refer to the explanation in SOAP section.