Community
Participate
Working Groups
Eclipse Build id: M20060921-0945 Mylar 1.01 jira plugin 1.01 I have a TaskList catagory that is a synchronized to a JIRA respos for a specific server side (jira server) saved query. The tasklist catagory is displayed not expanded and does not have a "+" sign (I am not sure why). I double click it and get a Mylar Error dialog Dialog reports "Reason: Jira Authentication Failure" Behind that dialog window is Edit Repository Query window. Error log has this: !ENTRY org.eclipse.mylar.core 4 0 2007-01-10 10:06:21.580 !MESSAGE Jira Authentication Failed. Please check your Jira username and password in the Task Repositories view !STACK 0 org.tigris.jira.core.service.exceptions.AuthenticationException at org.tigris.jira.internal.core.service.soap.SoapJiraService.getSavedFilters(SoapJiraService.java:341) at org.tigris.jira.core.service.CachedRpcJiraServer.getNamedFilters(CachedRpcJiraServer.java:496) at org.eclipse.mylar.internal.jira.core.ui.wizards.JiraQueryWizardPage$3.run(JiraQueryWizardPage.java:185) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Interestly, when I closed eclipse and restarted, the problem cannot be reproduced. Furthermore, the "+" sign exists for the catagory and I can see that it is synchonized.
I have the same problem and I normally use the following workaround: I go to the Task Repositories view, I select my repository of interest, I click on the Properties menu item from the context menu and I revalidate the repository parameters with the "Validate" button in the wizard. I then return to the Task List view and resyncrhonize the query and all my issues show up. My problem though is that I keep on losing my query results throughout my day, so that I am forced to repeat the procedure outlined above at least ten times per day, which is a little excessive.
This issue is similar to bug 169102 (though happens trough different execution path). We are still trying to figure out how to resolve this.
Yes, this is bug 169102, and it seems to happen to me even more often now. I have put the work-around (stated in comment#1) on top of the JIRA FAQ entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=169102 *** This bug has been marked as a duplicate of bug 169102 ***
Mik, please note that neither validate nor workarounds that we have in the code don't help with that. The only thing that works is to actually remove repository and add it back (basically clean all the locally cached data), which can be done by clicking OK on repository preferences dialog.
Hmm, what if for now we make "Update Attributes" action on the Task Repository delete and add the server? I think that causes core services to discard cached data, but I'm not completely sure.
That would work. We'll have to do that for nearly any JIRA operation to make sure that connection is alive... Right now I don't know any other way to reset that auth data... except an evil hack with reflection api.
But if we do this for every JIRA operation, and not just have it invoked manually, then don't we trigger the very slow operation of getting all attributes on a repository like CodeHaus? Still, just about anything is better than the horribly flaky behavior that we have now. What I don't get is why it seems to have degraded so much since 1.0.1.
I think it was always like this. We can add it to query synchronization and any task data retrieval that happens in background, so it shouldn't be too bad because of background operation. What may be critical is to not trigger it when task data is synchronized when editor is opened.
OK, for today's build, which should be available soon, every query calls a new JiraServerFacade.forceServerReset(..) method which removes and then re-adds the server. Chances are that it wasn't actually Validate Settings that was fixing this, but this add/remove that happens when the Task Repository is changed.
Created attachment 57614 [details] mylar/context/zip
