Community
Participate
Working Groups
Connect to remote SSH Only host. Select a file, right-click > delete --> Delete fails due to an NPE in AbstractFileService.deleteBatch() The problem is that in the course of changes for TM 3.0, deleteBatch() was changed and now includes this code: SystemMessage msg = getMessage("RSEF1315"); //$NON-NLS-1$ but the default implementation of getMessage() just returns null, so this code is bound to fail. I think the right solution is 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. -----------Enter bugs above this line----------- TM 3.0M3 Testing installation : eclipse-SDK-3.4M3-win32, cdt-5.0.0M3, emf-sdo-xsd-2.4.0M3 Download RSE-I20071108-0100: RSE-SDK,tests,discovery,terminal,remotecdt java.runtime : Sun 1.5.0_11-b03, mixed mode os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : SSH Only targetos1 : Linux RHEL4, Sun 1.5.0_11 ------------------------------------------------
Here is the NPE for reference: java.lang.NullPointerException at org.eclipse.rse.services.files.AbstractFileService.deleteBatch(AbstractFileService.java:134) at org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.deleteBatch(FileServiceSubSystem.java:831) at org.eclipse.rse.internal.files.ui.view.SystemViewRemoteFileAdapter.doDeleteBatch(SystemViewRemoteFileAdapter.java:2556) at org.eclipse.rse.internal.ui.actions.SystemCommonDeleteAction$DeleteJob.run(SystemCommonDeleteAction.java:148) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Xuan, I see that you added the getMessage("RSEF1315") call in when you worked on bug 160775. Looking at the IBM RSE code, we used to call getPluginMessage(ISystemMessages.FILEMSG_DELETING) so I can see you were attempting to port that. I think, for this defect, we need to get rid of this getMessage() call so that we don't have a major bug on our hands. Regarding the IMessageProvider idea, I think 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?
To fix this particular problem (NPE), I think we probably need to provide the deleteBatch() method in LocalFileService to override the default implementation of deleteBatch() in AbstractFileService. We may need to open a separate bug to discuss the message processing change mentioned in this bug.
I've always wanted to get rid of SystemMessages since nobody in Open Source really understands them. A separate bug for this task seems a good idea. In the short term, I need this NPE regression fixed soon, best for the next I-build. The suggestion outlined in the bug description seemed a proper short-term workaround for me.
Created attachment 83866 [details] Fix for the NPE
I've committed the changes to cvs.
Bug #211067 has been opened for message retrieving enhancement.
Verified in M4 I20080103-0700 driver.
Close since it is fixed.
