Community
Participate
Working Groups
In the WebSphere Business Integration Message Broker toolkit, we use markers to add to the tasklist warnings and errors that associated with IResources. We have noticed that some of the warnings were not showing up when using the "on any resource in same project" filtering option. The problem was very visible when we select all the tasklist entries that are shown, and we compare the numbers showing at the very bottom ("9 items selected: 0 errors, 9 warnings, 0 infos") of the main application window, with the numbers shown just under "Problems" "0 errors, 11 warnings, 0 infos (Filter matched 11 of 29 items". If I change the filtering to "on selected Resource only", then the problem disappears. This problem is breaking our autofix feature that needs to have all warnings and errors available. I have a screen capture if it makes things easiar.
I have investigated this problem further and I have the following scenario that can reproduce the same problem in a jave file. Basically in our product, the problem occurs with markers that have exactly the same text. In java files, the problem occurs with markers that have exactly the same text and same line. The markers have to be on the same file and the marker filter is set "On selected resource only" To reproduce this problem, generate a plugin project. In the plugin project, add the java class below: public class Test1 { public Test1() { super(); } String test2; private void changeTest2() { byte[] bytes = test2.getBytes(); String test3 = new String(bytes, 3); String test4 = new String(bytes, 4); String test5 = new String(bytes, 4); } } The public String(byte[] ascii,int hibyte)is deprecated so it will give a warning "The constructor String(byte[], int) is deprecated" In this case, 3 warnings should and are posted. If you change the method to look like the following: private void changeTest2() { byte[] bytes = test2.getBytes(); String test3 = new String(bytes, 3); String test4 = new String (bytes, 4); String test5 = new String(bytes, 4); } Then 2 warnings are shown only. Again if you change the method to look like the following: private void changeTest2() { byte[] bytes = test2.getBytes(); String test3 = new String(bytes, 3); String test4 = new String (bytes, 4); String test5 = new String(bytes, 4); } Then only 1 warning is shown. The difference between the markers that we post and the markers that the java files are associated with is that the jave ones have a line number associated with them. So in the jave markers case, if text is the same and the line numbers are different then similar markers are shown. If the text and the lines are the same for multiple similar warnings, only one is shown. In our case, if the text is the same, then only one warning is shown, which is the wrong behaviour, and is breaking the quick fix features that we introduced.
Sorry Steve, I've moved the discussion into the bug report as my email just doesn't work so good (you got 2 of 5 emails it spat out yesterday). What I was trying to say is: The short answer is I won't be able to look at this until after 3.2M1, which is Aug 5th. I suspect this won't help you guys anyway, as I'm not sure what platform you ship on but eclipse 3.1 went out the door end of June. I'm not sure when 3.1.1 is scheduled for, but that's the earliest that a fix for this would make it into a release. The long answer is I haven't looked at the problem, I was just assigned all of Stefan's bugs as he's moved on. I did have a quick look at the code sample Hamzeh submitted, and can reproduce the problem in my 3.1 version. The hover over the marker shows all 3 identical warnings, but the problem view itself shows 7 warnings filter, but 5 warnings in the windows. (2 hidden). If I find out anything else, I'll post it. PW
So ProblemView extends MarkerView extends TableView ... and the TableView uses a TableSorter to help manage it's changes in it's ProblemMarkers. TableSorter sorts by the View's fields (ProblemView has 5 visible and one hidden). That's why ProblemMarkers that return the same 5 fields and were created at the same time disappear ... also why it was hard to reproduce (if the creation time was slightly different, the problem went away, which was especially true if you insert break points). 2 possible fixes: 1. Add a second hidden field that looks at the problemMarker.getMarker().getId() field. The ID is gaurranteed to be different in 2 different markers in the same resource. 2. Change the TableSorter (and similar comparitors) so the last check they do if all other fields were equal is an identity check. Option 1 is certainly more isolated to the problem at hand, while Option 2 is the more generic solution if it's acceptable that the comparitor was never supposed to reduce 2 separate objects to one display object. PW
(In reply to comment #3) Paul - thanks for the extra information. For fix 1 are you saying that we change our task list messages to include an extra field?
(In reply to comment #4) Hey-o Steve, No, both of those fixes were eclipse fixes, where we would update internal data. But unless you released your product on 3.1.1 (and I'm not sure when that's coming out) my fixes won't help you. 2 quick hacks that you might be able to use: 1. add fake line numbers to your markers. If you are concerned about customer confusion, you could start them at 10000 :-) 2. possibly, if you create them with little delays between each (this is a bad solution for performance reasons). I can't think of anything other quick fixes that might help you. PW
I can look at this for 3.1.1. PW
Created attachment 26169 [details] Problem view fix for markers with the same text v01 The patch is to add the marker ID as a hidden field. The table sorter compares based on the visible + hidden fields it's passed, and the marker ID is guaranteed to be unique within a given resource (one of the visible fields). PW
Also released to 3.2.
It's been released into 3.1.1 and 3.2
verified for 3.2.
