Community
Participate
Working Groups
Build Identifier: 3.6.1 M20101013-0800 Breakpoint marker attributes that were written as Strings are imported as an Integer (if the attribute value is a valid number) or Boolean (if the attribute is a valid boolean value) This causes problems for attributes that are expected to be strings even if they have a valid Integer or Boolean value. For example a file name can be called "1" and is stored as a string in a "FileName" attribute but is imported as an Integer. Not sure why the ImportBreakpointOperation.readAttribute() method doesn't use the same readAttribute strategy as Marker As a workaround I will have to add ".toString" for each attribute I read in and expect to be a string. I feel that the core code should respect the attribute type. Reproducible: Always
The problem is with the way we write + read the .bkpt file. Unlike persisted IMarkers we do not have the attributes set in their own kind of entry. IMarker attributes are stored in their own named entry in the memento like INTEGER_ATTRIBUTE, BOOLEAN_ATTRIBUTE, etc. Whereas in our bkpt file we store entries as just ATTRIB. Had we been thinking at the time we should have stored them according to their kind like IMarkers do. That being said, we would have to move to a system like that (the IMarker scheme)to ensure this problem does not occur or add a 'type' field to the ATTRIB in the bkpt file. Either way we have to be careful to maintain backwards compatibility for reading older file formats. For example we could add a 'type' field like: <attrib name="workingset_name" value="" type=STRING/> or make individual attribute kinds, like: <int_attrib name="org.eclipse.jdt.debug.core.installCount" value="0"/> <bool_attrib name="org.eclipse.jdt.debug.core.caught" value="false"/> <str_attrib name="workingset_name" value=""/>
I would think that most implementors of import/export do not expect strings to potentially come back as Integers or Booleans. So rather than be a compatibility issue this may fix incorrectly imported breakpoint attributes. I know when we coded the import part of our breakpoint support we expected attributes to come back as we had described them.
(In reply to comment #2) > I would think that most implementors of import/export do not expect strings to > potentially come back as Integers or Booleans. So rather than be a > compatibility issue this may fix incorrectly imported breakpoint attributes. > I agree 100%, but we would have to ensure the import code could still read a .bkpt file that does not have the new kind of attributes.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
