Community
Participate
Working Groups
Eclipse: I20101221-1019 Mylyn: 3.5.0.I20101215-2000-e3x Bugzilla: bugs.eclipse.org After trying to refresh attributes in the Task Editor I was presented with an error message saying: Error parsing xmlrpc response. Unexpected exception>java.lang.String incompatible with java.lang.Integer
What's interesting, setting a target milestone to a value the Task Editor doesn't know about (couldn't fetch it from the repo) results in displaying "" in the Target Milestone combo in the editor.
Did you see that with a public Bugzilla instance? Frank, if a task has an unknown milestone, can we add the value to the list of options instead of showing a blank field?
When you disable "Use xmlrpc.cgi" under the Additional Settings the problem is solved. I did not know if bugs.eclipse.org is enabled for xmlrpc. But I think that here can be a problem in the Bugzilla instzallation on bugs.eclipse.org.
Created attachment 185820 [details] mylyn/context/zip
(In reply to comment #1) > What's interesting, setting a target milestone to a value the Task Editor > doesn't know about (couldn't fetch it from the repo) results in displaying "" in > the Target Milestone combo in the editor. How did you set the target milestone to a value that is not in the Task Editor. I see no way!
This is a common scenario if a new milestone is added in Bugzilla and set on a bug through the web interface.
(In reply to comment #6) > This is a common scenario if a new milestone is added in Bugzilla and set on a > bug through the web interface. That is correct. I was forced to leave the Task Editor, update the bug in a browser and when I switched back to the editor I saw comment 1.
Created attachment 186334 [details] commited patch This patch includes * test if all values of an attribute are in the options if exists * fire an update configuration job if we found one value not in the options
Created attachment 186335 [details] mylyn/context/zip
I am not fully understanding the proposed change. Where is the the "Update Config" exception is actually thrown? Retrieving the configuration is a potentially expensive operation and we have to be very careful when to allow that. I would prefer if we reverted this change and discussed alternatives first, e.g. automatically adding the missing option if an unknown milestone/component/version is retrieved.
Created attachment 186666 [details] disable throw new CoreException (In reply to comment #10) > I am not fully understanding the proposed change. Where is the the "Update > Config" exception is actually thrown? BugzillaTaskDataHandler.initializeTaskData. Now this is disabled > Retrieving the configuration is a > potentially expensive operation and we have to be very careful when to allow > that. I would prefer if we reverted this change and discussed alternatives > first, e.g. automatically adding the missing option if an unknown > milestone/component/version is retrieved. The missing option is already added in the BugzillaTaskDataHandler.initializeTaskData
Created attachment 186667 [details] mylyn/context/zip
Created attachment 189373 [details] patch V4 Steffen, I change the update of the configuration to now use TaskJob and no longer direct client.getRepositoryConfiguration. With this we have an async way for the update. Do you think we can now activate the disabled "Update Config" exception?
Created attachment 189374 [details] mylyn/context/zip
It is problematic if the the connector spawns jobs that are not managed by the framework. It could lead to several configuration refresh jobs running in parallel for instance. I think we need to solve this differently. What is the problem that we are trying to solve here exactly?
(In reply to comment #15) > It is problematic if the the connector spawns jobs that are not managed by the > framework. It could lead to several configuration refresh jobs running in > parallel for instance. I think we need to solve this differently. What is the > problem that we are trying to solve here exactly? The problem I want to solve is the following: We know if we found an missing value that the configuration is not up to date so I want to get the latest version, so that ohter tasks / refresh of tasks did not get the same problem. That why I create the Update Job. Did you know a better way?
First off, we should be dynamically adding newly discovered component, milestones and versions to the configuration without triggering a re-download. Does that already work? I still occasionally get a blank field when new milestones are added but that should be simple to fix. We could then also set a flag that marks the configuration as stale and inform the framework that an update is required or do it as part of the regular update cycle. In either case, the download configuration refresh to be managed by the framework.
Created attachment 189850 [details] patch V5 (In reply to comment #17) > First off, we should be dynamically adding newly discovered component, > milestones and versions to the configuration without triggering a re-download. > Does that already work? I still occasionally get a blank field when new > milestones are added but that should be simple to fix. I add the new value to the localTaskDate but BugzillaAttributeMapper.getOptions() use the values from the configuration so I change this. Can I commit the patch or should we wait for version 3.6 > > We could then also set a flag that marks the configuration as stale and inform > the framework that an update is required or do it as part of the regular update > cycle. In either case, the download configuration refresh to be managed by the > framework. I think we should do this after 3.5 is released. Thoughts?
Created attachment 189851 [details] mylyn/context/zip
(In reply to comment #18) > I add the new value to the localTaskDate but > BugzillaAttributeMapper.getOptions() use the values from the configuration so I > change this. > > Can I commit the patch or should we wait for version 3.6 Good find! We need the code in the mapper to work the way it does right now to reflect configuration refreshes in the task editor. For product, milestone etc. could we do a check if the current value is part of the options coming from the repository and add it from the attribute if not? That way we could still display current configuration options but would not have the problem that newer values show blank. > > > > We could then also set a flag that marks the configuration as stale and inform > > the framework that an update is required or do it as part of the regular > update > > cycle. In either case, the download configuration refresh to be managed by the > > framework. > > I think we should do this after 3.5 is released. > > Thoughts? Agreed. We should create a bug for 3.6 to consider that improvement.
Created attachment 189857 [details] patch V6 (In reply to comment #20) > (In reply to comment #18) > > I add the new value to the localTaskDate but > > BugzillaAttributeMapper.getOptions() use the values from the configuration so I > > change this. > > > > Can I commit the patch or should we wait for version 3.6 > > Good find! We need the code in the mapper to work the way it does right now to > reflect configuration refreshes in the task editor. For product, milestone etc. > could we do a check if the current value is part of the options coming from the > repository and add it from the attribute if not? That way we could still > display current configuration options but would not have the problem that newer > values show blank. > This patch fix this. Can we do this for 3.5 because we have only have P3 for this?
Created attachment 189858 [details] mylyn/context/zip
(In reply to comment #21) > This patch fix this. Can we do this for 3.5 because we have only have P3 for > this? Yes, that's fine. We'll freeze end of next week but it's okay to make this change now. Thanks for asking. Change looks good to me. Can you add a comment why the value gets added if it's not in the options?
Patch V6 is now in HEAD with the requested comment. So I close this bug. I open bug# 338347 for some improvements.
Created attachment 189899 [details] mylyn/context/zip
Did the changes from V4 get reverted? That would be important. We can address the configuration update in a standard way through the framework for 3.6 but I would prefer to leave the current behavior for 3.5.
(In reply to comment #26) > Did the changes from V4 get reverted? That would be important. We can address > the configuration update in a standard way through the framework for 3.6 but I > would prefer to leave the current behavior for 3.5. No I did not revert the changes. The update of the configuration is disabled. When you want it to be active then we must remove the comments in line 507 - 511 in file BugzillaTaskDataHandler. Should I do this? Actual the missing options get added twice. 1) in BugzillaTaskDataHandler.initializeTaskData 2) in BugzillaAttributeMapper.getOptions
(In reply to comment #27) > No I did not revert the changes. > The update of the configuration is disabled. When you want it to be active then > we must remove the comments in line 507 - 511 in file BugzillaTaskDataHandler. I would like to have the job entirely removed from the Bugzilla connector. It should not reference TaskJob. > Actual the missing options get added twice. > 1) in BugzillaTaskDataHandler.initializeTaskData > 2) in BugzillaAttributeMapper.getOptions That seems fine.
This seems to have introduced a regression: If I create a new task the "" empty value is part of the choices for components on Eclipse.org.
Created attachment 190190 [details] patch V7 committed patch. This is not a regression. The problem was that in some case the initData only contain a product from an other repository.
Created attachment 190192 [details] mylyn/context/zip
resolved! If the component is null we set product and component from the configuration
Noticed another problem: When creating subtasks the component field is blank. Frank, could look into that and add a test case?
(In reply to comment #33) > Noticed another problem: When creating subtasks the component field is blank. > Frank, could look into that and add a test case? Steffen, sorry I can not reproduce this. The only way that I see to get this is with a parent task which has an not valid component. Can you give me some more details? I changed the way when component was null but this can not fix your problem.
Created attachment 190452 [details] mylyn/context/zip
Thanks. I can not reproduce this any longer. Something must have fixed it.
