[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] Re: DStoreConnectorService v1.57 is at risk of deadlock
|
Regarding comparison of messages, I think that our code
should never need
to compare messages. If code needs to react to a particular
(error) condition,
we should use a status code or an exception class instead
of passing a
particular message.
Messages should be reserved for user interaction
only.
That being said - looking at your refactorings, I saw that
in the big majority
of places, SystemMessages were just used in order to print
Strings or
make very simple substitutions. Only in a few places, an
actual message
was sent where a particular ID would make
sense.
I think it might make sense to allow SimpleSystemMessage
carry such
a maessage ID. It already carries the bundle ID, it could
also carry a
bundle-specific message ID, just like Eclipse IStatus has
the Status code
which is bundle specific. This could be implemented simply
by introducing
another Constructor.
Then, if you should really need it, you could compare
SystemMessages
by comparing the bundle ID and status code (aka message ID)
and
if they match, consider them being the
same.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Hi Martin,
I've dealt with most of this now. I still have to
deal with the startsWith() compare in DStoreConnectorService.
The issue that remains is what to do
about message IDs. In the original system message approach, the ID was
useful for determining where in the systemmessage.xml file to find the
corresponding message info. When using the SimpleSystemMessage approach,
the ID is not needed for that, however, it would still be useful to be able to
identify one message from another without comparing the strings. One
thing I like about SimpleSystemMessage is that the developer isn't forced to
come up with an ID but perhaps that's something we need. Any
suggestions?
