Bug 211067

Summary:	[api] Redesign message retrieval for different service
Product:	[Tools] Target Management	Reporter:	Xuan Chen <xuanchen>
Component:	RSE	Assignee:	David McKnight <dmcknigh>
Status:	RESOLVED FIXED	QA Contact:	Martin Oberhuber <mober.at+eclipse>
Severity:	enhancement
Priority:	P3	CC:	ddykstal.eclipse, wbprio
Version:	3.0	Keywords:	api
Target Milestone:	3.0 M6
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	216252
Bug Blocks:

Description Xuan Chen

2007-11-27 10:12:02 EST

This bug is opened because of bug #210555.

We need to redesign how we get a particular message for different service.
We want to remove the getMessage() method inside different service.

Some suggestions:

First suggestion:
To add the following method to IFileService and
AbstractFileService:
    setMessageProvider(IMessageProvider m)
and have this method called right after creating the service. Store the
provider in AbstractFileService just like for Local. Same should be done for
the Process service -- see also bug 199871 where this came up originally for
Local.

This change is backward compatible because IFileService class Javadoc says that
clients must extend AbstractFileService rather than implementing IFileService
directly.

Second suggestion:
We're looking at an enhancement
along with some more refactoring that ought to be carried out via a different
defect.  If we tried to fix this defect by introducing the suggested approach,
there are a number of issues we would face.

The message required here is stored in systemmessages.xml which is part of the
rse.ui plugin.  Rse.ui is certainly not the right place to be storing
file-specific messages so we would need to consider dividing up these messages
to go in the appropriate plugins.  We could still get the job done, without
dividing up the messages, however, that leaves stuck with a service that uses
message ids for messages that are defined outside of the service's plugin and
it's dependencies.  

As an aside, the use of SystemMessage versus other types of messages is still,
in my mind, a bit questionable - at some point, are we going to  try to change
to a more standard message format?

Comment 1 Martin Oberhuber

2007-11-27 12:42:17 EST

As per http://wiki.eclipse.org/DSDP/TM/Committer_Phone_Meeting_27-Nov-2007 :

DaveD: SystemMessages are heavily used in IBM products, they rely on having message ID's. There are two problems: (a) the whole interface, and (b) the format in which messages are stored.

What does SystemMessage have, that could not be mapped to an IStatus object? --> The Level 2 Text. But the namespace spanned by IStatus is more general, (plugin id + severity + status code); SystemMessage codes need to be "administered" to ensure uniqueness 

Could we define an "RSEStatus" object that has all the properties we need from SystemMessage but still conforms to IStatus? i.e. extend IStatus interface to add the levelTwoText? - DaveD: There must be an associated Property, or code, with the IStatus (to do something useful, in case the message is not being translated). That code could perhaps be the plugin-id / code tuple but not sure about that.

It looks like for 3.0 we'll have to stick with SystemMessages?

Comment 2 Martin Oberhuber

2008-01-22 18:17:36 EST

Do we want to look at this for 3.0 or mark it as "Future"?

Comment 3 Martin Oberhuber

2008-02-05 12:01:33 EST

This bug is related to UI/Non-UI splitting (bug 190231) because in a plain headless environment, no SystemMessageProvider would be injected into the core services, leading to NPE's as we have seen before.

I'd thus like to target this issue 3.0 M6 since I really want headless RSE to work with that milestone.

Here are the possible solutions:
a) Change Services to use Eclipse NLS Strings instead of Message IDs
   Potentially also creating a kind of IStatus handling for Services
b) Create a second, headless SystemMessageProvider and split up 
   SystemMessages.xml into a UI and a non-UI part. The XML Dependency would
   still bring in quite a bit of extra load on a headless RSE.

Assigning Xuan to drive the discussion.

Comment 4 David McKnight

2008-02-21 14:55:39 EST

I think this has been addressed via Bug 216252.  The strings used for messages are divided among services in .properties files.  The messages (if required) can be constructed directly via SimpleSystemMessage in the services.   Is there anything we're missing now?

Comment 5 Martin Oberhuber

2008-02-25 21:14:00 EST

With the latest changes as per bug 216252 comment 23, this will indeed be fixed. But references to ISystemMessageProvider need to be removed from the service implementations completely, and constructors need to be updated accordingly.

Comment 6 David McKnight

2008-02-26 16:59:08 EST

ISystemMessageProvider is no longer, due to fixes in 216252, so I'm marking this one as fixed.