Bugzilla – Full Text Bug Listing
| Summary: | DataAccessException when trying to close an issue in Mylyn eclipse plugin | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Hung Huynh <magus_iii> | ||||
| Component: | Mylyn | Assignee: | Eugene Kuleshov <ekuleshov> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | ekuleshov, john.allen, marko.asplund | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Hung Huynh
Eugene: can you investigate? Will do. It seems like Hung's JIRA has some customization. I'll try to look at this on the weekend, but are we good to resume regular commits yet? Yes, you can go ahead with regular commits, the tree is tagged and a JIRA update can be made since it is on the Extras site. Great. Thanks. I've committed fix to add missing required fields. It now works on Hung's server, but we need to add the rest of fields to Issue.getFieldValues() method and add some more tests. Created attachment 72967 [details]
mylyn/context/zip
I'm seeing a similar issue trying to update an issue: Exception occurred: com.atlassian.jira.exception.DataAccessException: com.atlassian.jira.issue.customfields.impl.FieldValidationException: Invalid date format. Please enter the date in the format "d-MMM-yy". - Mylyn and the Jira connectors v2.0.0.v20070831-1600 dev build - Jira 3.10 - Eclipse 3.3 (MyEclipseIDE 6.0) Marko, are you working with some public JIRA instance or is it possible to get exported configuration from your JIRA? This seem like issue with JIRA customization that will be difficult to reproduce without seeing your configuration. It's an internal instance. I can probably get the administrator to provide you with the information you need. Could you give me instructions on what info to provide and how? Marko, if you could ask your JIRA admin to run Export action available from JIRA Administration page and email me exported archive that would be a huge help. Alternatively it will also work if you can create a test project in your JIRA instance (configured in a same way as one you having problems updating) and give me access to that project. According to our Jira admin all the project data will be included in the export so he feels uncomfortable providing the export file. Do you know if there's a way to just export the settings or to restrict the export contents? We've got the same issue since we upgraded JIRA from 3.7 to 3.10. There are a number of observations: 1) When hitting 'validate server settings' in the JIRA configuration one now gets a Mylyn only supports JIRA version above 3.3 error message. Fortunately you can still okay this and use the connector 2) Custom fields are the main stay of JIRA so any JIRA-Mylyn integration is going to have to handle these. We used to have plenty of custom fields on our 3.7 JIRA instance that Mylyn was happy with so I don't think it's directly related to this (could easily be wrong mind;). We JAD'ed some of the connector code and ran a packet sniffer on the dialogue between eclipse and JIRA. Observations from this include: Errors raised - one gets a NPE and a dataformaterror. the NPE is, i expect, from a corrupt JIRA issue object in the connector's model as it was coming from a simple issue.getCreateDate() and I would guess that came about from some other previous failing, sorry I don't have the NPE line at hand. One is able to comment an issue once using mylyn successfully and perform a synchronise but if one tries again we got a dateformaterror. All further syncs hit this error. Sniffing the edit post call you make to update the JIRA ticket shows that JIRA is coming back with an on screen error (actually JIRA represents the edit screen with a red box at the top, this is the type of box JIRA usually uses to 'inline highlight' which field is in error). The error box says that a required field has not been populated (or something like that) and quotes a custom field but I'm not really sure it is, and if it is, its not an on screen one (and mylyn used to work fine before we upgrdaded to JIRA 3.10 and we've not added any of our own new fields in that time). The main change we can see with our new JIRA 3.10 is the 'Edit your comment' and 'Edit your worklogs' stuff, and with that JIRA is now maintaining more data about a comment (date etc). I have assigned a developer to investigate this in house (Fujitsu Services) but we would be doing this by sniffing and trying to reverse engineer the connector so obviously someone who knows the design in the first place is going to be much better placed to sort it out. Sorry i havent got more concrete info bar, it used to work with JIRA 3.7 and now with JIAR 3.10.1 it doesn't but I've got egg on my face at the mo' i have sold mylyn big time into our development communities and have had to withdraw it. (In reply to comment #12) > We've got the same issue since we upgraded JIRA from 3.7 to 3.10. There are a > number of observations: > > 1) When hitting 'validate server settings' in the JIRA configuration one now > gets a Mylyn only supports JIRA version above 3.3 error message. Fortunately > you can still okay this and use the connector Please note that this issue been fixed almost 2 months ago. > 2) Custom fields are the main stay of JIRA so any JIRA-Mylyn integration is > going to have to handle these. We used to have plenty of custom fields on our > 3.7 JIRA instance that Mylyn was happy with so I don't think it's directly > related to this (could easily be wrong mind;). There are limitations about custom fields whe we have outlined in the connector FAQ at http://wiki.eclipse.org/Mylyn_FAQ#Known_limitations_2 > We JAD'ed some of the connector code and ran a packet sniffer on the dialogue > between eclipse and JIRA. Observations from this include: > [skipped] > I have assigned a developer to investigate this in house (Fujitsu Services) but > we would be doing this by sniffing and trying to reverse engineer the connector > [skipped] > > Sorry i havent got more concrete info bar, it used to work with JIRA 3.7 and > now with JIAR 3.10.1 it doesn't but I've got egg on my face at the mo' i have > sold mylyn big time into our development communities and have had to withdraw > it. Excuse my ignorance, but I am not quite get why do you need to reverse engineer open source code? We have relatively detailed guide how to setup your workspace, so you can simply step trough the Mylyn code in the debugger. However I just relized that the original issue been actually fixed, and recent dev build does work on reporter (Hung) JIRA instance. So, I'd really appreciate separate bug reports if you still having troubles to use connector on your own JIRA instance. (In reply to comment #13) > (In reply to comment #12) > > We've got the same issue since we upgraded JIRA from 3.7 to 3.10. There are a > > number of observations: > > > > 1) When hitting 'validate server settings' in the JIRA configuration one now > > gets a Mylyn only supports JIRA version above 3.3 error message. Fortunately > > you can still okay this and use the connector > > Please note that this issue been fixed almost 2 months ago. > > > 2) Custom fields are the main stay of JIRA so any JIRA-Mylyn integration is > > going to have to handle these. We used to have plenty of custom fields on our > > 3.7 JIRA instance that Mylyn was happy with so I don't think it's directly > > related to this (could easily be wrong mind;). > > There are limitations about custom fields whe we have outlined in the connector > FAQ at http://wiki.eclipse.org/Mylyn_FAQ#Known_limitations_2 > > > We JAD'ed some of the connector code and ran a packet sniffer on the dialogue > > between eclipse and JIRA. Observations from this include: > > [skipped] > > I have assigned a developer to investigate this in house (Fujitsu Services) but > > we would be doing this by sniffing and trying to reverse engineer the connector > > [skipped] > > > > Sorry i havent got more concrete info bar, it used to work with JIRA 3.7 and > > now with JIAR 3.10.1 it doesn't but I've got egg on my face at the mo' i have > > sold mylyn big time into our development communities and have had to withdraw > > it. > > Excuse my ignorance, but I am not quite get why do you need to reverse engineer > open source code? We have relatively detailed guide how to setup your > workspace, so you can simply step trough the Mylyn code in the debugger. When i say reverse engineer I do not mean decompile. The fact its open source does not negate the fact that we would need to spend more time than a mylyn dev as we would need to familiarise ourselves with its design and operation behaviours. > However I just relized that the original issue been actually fixed, and recent > dev build does work on reporter (Hung) JIRA instance. So, I'd really appreciate > separate bug reports if you still having troubles to use connector on your own > JIRA instance. This is most excellent news and i apologise for the inclusion of two bugs in one, my interest was related to this ticket's subject and i will schedule a trial of the latest dev build. (In reply to comment #14) > > > We JAD'ed some of the connector code... > When i say reverse engineer I do not mean decompile. He he. You just said that you did decompiled connector code. :-) > The fact its open source > does not negate the fact that we would need to spend more time than a mylyn dev > as we would need to familiarise ourselves with its design and operation > behaviours. True. That is why there are number of reasonable active mailing lists where you can ask questions to save your own time. please don't hesitate. See http://www.eclipse.org/mylyn/community/ > This is most excellent news and i apologise for the inclusion of two bugs in > one, my interest was related to this ticket's subject and i will schedule a > trial of the latest dev build. Great. (In reply to comment #11) > According to our Jira admin all the project data will be included in the export > so he feels uncomfortable providing the export file. > Do you know if there's a way to just export the settings or to restrict the > export contents? That is true and as far as I know there is no way around that. If you send it to me, I can only promise you that I'll only use this data for debugging and delete it once we'll resolve this issue. Maybe we can implement some kind of tool to scramble all the private data, but I am not sure if I'll have time to work on that this week. (In reply to comment #16) > (In reply to comment #11) > > According to our Jira admin all the project data will be included in the export > > so he feels uncomfortable providing the export file. > > Do you know if there's a way to just export the settings or to restrict the > > export contents? > Maybe you could try just creating a new JIRA project that uses all the same JIRA schemes? This should give it the same underlying JIRA schemas and, if you seed with data and replicate the fault, allow you to create a sandbox to test mylyn against? Of course this won't work if the problem is some historical data or some other evil but it might beworth a try. I took the issue up with our Jira admin again today but he was reluctant to provide the export file because the installation contains sensitive data about our client projects. (In reply to comment #17) > Maybe you could try just creating a new JIRA project that uses all the same > JIRA schemes? This should give it the same underlying JIRA schemas and, if you > seed with data and replicate the fault, allow you to create a sandbox to test > mylyn against? Of course this won't work if the problem is some historical data > or some other evil but it might beworth a try. Do you suggest creating another Jira installation and copy the configuration from the old installation? I'm not really familiar with Jira administration so unfortunately I don't know which files would be relevant here. Do you know which files should be copied in order to replicate the configuration? (In reply to comment #19) > Do you suggest creating another Jira installation and copy the configuration > from the old installation? > I'm not really familiar with Jira administration so unfortunately I don't know > which files would be relevant here. > Do you know which files should be copied in order to replicate the > configuration? Actually that is a good suggestion. You can install another JIRA instance, import your configuration there and then delete/rename all private/sensitive tasks/projects, etc. Just make sure that you still can reproduce same errors on this copied instance. Marco, since original issue been fixed, I am going to resolve this issue. Please open new bug report if you'll be able to figure out how can you share your configuration with us. Thanks. Marco: if the connector is not working for you, we should have an open bug for that regardless of whether you can share the configuration or not, so if you can't connect please do file a new bug summarizing the points that you made here. There seems to be new Mylyn and Jira connector dev builds (v2.0.0.v20070917-2100) available. Is this issue fixed in that build? Marko: there is a slightly newer dev build up (2.1.0.v20070920-1000). Please try that and let us know what is still failing. (In reply to comment #24) > Marko: there is a slightly newer dev build up (2.1.0.v20070920-1000). Please > try that and let us know what is still failing. > After upgrading to the latest build I'm now able to edit certain fields in a Jira task and add comments. Thanks. |