|
What we know:
1. Data can be shared between systems, all methods successfully returned data . 2. getIssue will generate errors, ONLY with .Net. So far, I've been using Python for the same issue and it worked. 3 getIssue generate an error with .Net when the issue is having a custom field. 4. getIssue will generate error when the data is parsed by .Net. Plus, I commented out the custom issue generation in jira (RPC-SOAP files) and it worked. So, looks like there is some incompatibilities using webservices between Jira and .NET. Maybe there is something else, but that's a start since the same issue without custom field did complete the process loop. oops, is it possible to delete those comments? I thought they were part of the attachments.
Have a look at the files I attached. They should answer your questions Mark. Here is why Ubisoft admins are having problems with getIssue: The Issues are created, but the exception that is thrown means that there is no 'returnedIssue' from the createIssue(token, issue) method. As a result, the issue Key is NOT set. Thus, you cannot use getIssue(token, issueKey) to retrieve an issue, because the issue has no key (even though the key does appear from a user standpoint in Jira). Trying to use that key results in another error. Our actual problem is to get an Issue FROM jira TO .net that has custom fields.
We were able to create and delete simple issues (no issues and custom fields) But looks like there is two problems here. The getIssue and the createIssue with custom fields. <b>Right now, we are trying to display a Jira Issue in Microsoft asp.NET web page using webservices.</b> but there is a major problem when there is custom fields. "Our actual problem is to get an Issue FROM jira TO .net that has custom fields."
Right, but there is only one problem. getIssue() works just fine unless there are custom fields, it fails as a result of the error you first mentioned. It seems like the "soapenc:string" causes .Net some grief. I don't understand exactly why this is a problem only when there are custom fields but not for normal issue creation...
I've raised an issue that will hopefully fix this I don't know if there's a lot that can be done until we try this. It might also be worth while if you guys have some in house .Net expertise to see if they can help you out with .Net parsing XML responses with soapenc:string. We don't have any expertise in this area so we can't give you a real workaround.
Here's 2 things I just tried:
Adding custom field values to normal issues (Manual or Soap created). Soap retrieval fails (same error) (but then when you clear the custom values it works again) Creating issues with custom fields (using soap). Clearing the custom field value. Retrieval fails (same error). so I'm not sure if it's related to the "missing issue key" I was talking about before. It seems that (in .Net anyway) you can't retrieve issues that have custom fields because of the xml error. and that it results because they have custom fields. I'm trying to find information about this subject, but looks like there is not much on the web.
What I know so far is that there is different way to process webservices complex objects and Microsoft and Java are using different ones.... It is supposed to be a known issue, but as I said, I can't find this information on the web. What now? Here are the most interesting articles I have found so far: http://webservices.xml.com/pub/a/ws/2003/09/30/integrating.html Hope this helps finding a solution ? An overview and pointer to an interesting article on the general problem:
As we have very little experience with .NET internally, would you be able to write a sample .NET program that replicates the problem and attach it here. Hopefully using this program we can try to work out a fix for the situation.
Thanks, The asp project attached by Ubisoft didn't work for me. I'm attaching a simple windows application. You shouldn't have to set up anything for it to work.
1. double click on CustomField.sln to open the project (or CustomField.csproj ) – Each time you run the program, one issue will be created here: just tried the new ( 1.5.3) RPC plugin..
when retrieving issues that have custom fields, the error also occurs using getIssuesFromFilter(token, filterID) Guys,
I've implemented a fix for JIRA 3.2.1. Can you guys have a try on this and see how you go? The soapenc:string should now all be xsd:string. Sebastian - the fix is in JIRA itself and not the RPC plugin, so you'll have to upgrade JIRA. Let us know how you go & sorry for the hassle. Cheers Mark C Excellent!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Blocker
getIssue returning data incompatible with MS .NET (complex objects )
Do you know if the SOAP packet is getting to JIRA at all or is the error occurring in the .Net realm before the SOAP packet is transmitted?
Cheers
Mark C