Community
Participate
Working Groups
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?
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?
Do we want to look at this for 3.0 or mark it as "Future"?
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.
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?
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.
ISystemMessageProvider is no longer, due to fixes in 216252, so I'm marking this one as fixed.
