Community
Participate
Working Groups
Created attachment 131145 [details] Screenshot of bug Build ID: M20080911-1700 Steps To Reproduce: 1.Obtain the org.eclipse.mylyn.xml3 samples (both core and ui) from CVS: org.eclipse.mylyn/sandbox/connector-tutorial/org.eclipse.mylyn.xml3.core and org.eclipse.mylyn/sandbox/connector-tutorial/org.eclipse.mylyn.xml3.ui 2. Run Eclipse with both, then add a new File-Based XML task repository. Give the server and the label the same value. 3. Add a new Query to the repository. 4. In the task list, the new query will show up as "queryname [ <unknown host> ]" 5. If the server and label is not the same, then it will correctly display the repository label More information: This will happen with any repository, and is not specific to the XML sample. I've attached a screen shot showing the problem. In the screenshot, I used "sameserverandlabel" as both the server name and label. You will also see a query calld differentserverandlabel that works correctly.
Created attachment 131152 [details] Patch: Use repository label instead of "[<unknown host>]" when label and url are the same and MalformedURLException is caught
Created attachment 131153 [details] mylyn/context/zip
On further investigation it turns out that this is being caused by TaskLabelDecorator.decorate(). It compares the repository url and label, and if the two are the same it then tries to create a URL instance using the repository url, which then throws a MalformedURLException. This exception is then caught and "[ <unknown host> ]" is then added as the suffix. For web based repositories, this probably works ok, but in my case I'm using a thirdparty API to retrieve all the task data, so no url's are involved. What's not clear from the code is why it doesn't just work the same in all cases. 1. Why does it try to create a URL if the repository label and url is the same? 2. Why does it not try to create a URL or check the validity of the URL if the comparison fails? I've attached a patch file that makes the behaviour the same if the MalformedURLException is thrown.
Mik, do you remember the reason for this behavior?
Appears that this was old code that is not needed anymore. I have removed the special case handling.
Created attachment 135889 [details] mylyn/context/zip