Community
Participate
Working Groups
This is out of the 2nd log attached to bug 158673: !MESSAGE Unable to connect to REXEC host service on port 512 of host HPADL805 !STACK 0 org.eclipse.rse.services.clientserver.messages.SystemMessageException: Unable to connect to REXEC host service on port 512 of host HPADL805 at org.eclipse.rse.connectorservice.dstore.DStoreConnectorService.internalConnect(DStoreConnectorService.java:1064) at org.eclipse.rse.core.subsystems.AbstractConnectorService.connect(AbstractConnectorService.java:792) at org.eclipse.rse.core.subsystems.SubSystem.internalConnect(SubSystem.java:2770) at org.eclipse.rse.core.subsystems.SubSystem.implicitConnect(SubSystem.java:1678) at org.eclipse.rse.core.subsystems.SubSystem$ConnectJob.performOperation(SubSystem.java:1605) at org.eclipse.rse.core.subsystems.SubSystem$SubSystemOperationJob.run(SubSystem.java:1321) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) !ENTRY org.eclipse.rse.ui 4 0 2006-09-25 17:12:44.181 !MESSAGE Exception resolving filters' strings !STACK 0 java.lang.NullPointerException at org.eclipse.rse.services.dstore.processes.DStoreProcessService.getMinerElement(DStoreProcessService.java:172) at org.eclipse.rse.services.dstore.processes.DStoreProcessService.listAllProcesses(DStoreProcessService.java:73) at org.eclipse.rse.subsystems.processes.servicesubsystem.ProcessServiceSubSystem.listAllProcesses(ProcessServiceSubSystem.java:124) at org.eclipse.rse.subsystems.processes.core.subsystem.impl.RemoteProcessSubSystemImpl.internalResolveFilterString(RemoteProcessSubSystemImpl.java:131) at org.eclipse.rse.core.subsystems.SubSystem.internalResolveFilterStrings(SubSystem.java:2888) at org.eclipse.rse.core.subsystems.SubSystem.resolveFilterStrings(SubSystem.java:2208) at org.eclipse.rse.ui.view.SystemViewFilterReferenceAdapter.internalGetChildren(SystemViewFilterReferenceAdapter.java:367) at org.eclipse.rse.ui.view.SystemViewFilterReferenceAdapter.getChildren(SystemViewFilterReferenceAdapter.java:226) at org.eclipse.rse.ui.operations.SystemFetchOperation.execute(SystemFetchOperation.java:197) at org.eclipse.rse.ui.operations.SystemFetchOperation.run(SystemFetchOperation.java:101) at org.eclipse.rse.ui.view.AbstractSystemViewAdapter.fetchDeferredChildren(AbstractSystemViewAdapter.java:1766) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:207) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) !MESSAGE Exception resolving filters' strings !STACK 0 java.lang.NullPointerException at org.eclipse.rse.services.dstore.AbstractDStoreService.getMinerElement(AbstractDStoreService.java:73) at org.eclipse.rse.services.dstore.AbstractDStoreService.getMinerElement(AbstractDStoreService.java:66) at org.eclipse.rse.services.dstore.files.DStoreFileService.getRoots(DStoreFileService.java:1143) at org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.getRoots(FileServiceSubSystem.java:312) at org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.listRoots(FileServiceSubSystem.java:424) at org.eclipse.rse.subsystems.files.core.subsystems.RemoteFileSubSystem.internalResolveFilterString(RemoteFileSubSystem.java:574) at org.eclipse.rse.subsystems.files.core.subsystems.RemoteFileSubSystem.internalResolveFilterStrings(RemoteFileSubSystem.java:415) at org.eclipse.rse.core.subsystems.SubSystem.resolveFilterStrings(SubSystem.java:2208) at org.eclipse.rse.ui.view.SystemViewFilterReferenceAdapter.internalGetChildren(SystemViewFilterReferenceAdapter.java:367) at org.eclipse.rse.ui.view.SystemViewFilterReferenceAdapter.getChildren(SystemViewFilterReferenceAdapter.java:226) at org.eclipse.rse.ui.operations.SystemFetchOperation.execute(SystemFetchOperation.java:197) at org.eclipse.rse.ui.operations.SystemFetchOperation.run(SystemFetchOperation.java:101) at org.eclipse.rse.ui.view.AbstractSystemViewAdapter.fetchDeferredChildren(AbstractSystemViewAdapter.java:1766) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:207) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -----------Enter bugs above this line----------- RSE 1.0 Testing round 1 installation : eclipse-platform-3.3M2 (I20060922-0010) RSE install : update-site RSE-complete java.runtime : Sun 1.5.0_08-b03 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : Dstore-unix targetos : HP-UX 11.11 targetuname : targetvm : ------------------------------------------------
The problem is we were using the wrong id for the process miner. I've fixed this now.
I think I'd prefer putting the verbatim String of the miner ID into the code rather than looking it up from the actual miner. First, that ID is part of the API and may thus also be exposed as such. Otherwise one could move the miner to a different package and think everything is OK, but it is not because that change would not be backward compatible. Second, I could imagine that in some future version of RSE the class files for the miners are no longer shipped and packaged with the client (since they are needed on the server only). Then, you wouldn't have access to the Minerclass.getClass() method at runtime because Minerclass would not be shipped with the client. Reopening to clarify and discuss.
(In reply to comment #2) > I think I'd prefer putting the verbatim String of the miner ID into the code > rather than looking it up from the actual miner. > > First, that ID is part of the API and may thus also be exposed as such. > Otherwise one could move the miner to a different package and think everything > is OK, but it is not because that change would not be backward compatible. The other dstore services do a similar thing to get the miner ID. The benefit of this approach is that if we do any refactoring, the ID changes automatically. At this point, I wouldn't expect too much refactoring, so I guess it may be okay to use strings in each of these cases although I don't see the urgency of this. > > Second, I could imagine that in some future version of RSE the class files for > the miners are no longer shipped and packaged with the client (since they are > needed on the server only). Then, you wouldn't have access to the > Minerclass.getClass() method at runtime because Minerclass would not be shipped > with the client. If this were to happen, the change to use a string would be simple enough to make and it would be obvious to the developer because it wouldn't compile without access to the miner class.
(In reply to comment #3) > The other dstore services do a similar thing to get the miner ID. The benefit > of this approach is that if we do any refactoring, the ID changes > automatically. But that's the point. We must not do any refactoring because the miner ID is part of the dstore protocol and thus part of external API. If we were to refactor this, TM 2.x would no longer work against TM 2.0 servers, would it?
(In reply to comment #4) > (In reply to comment #3) > > The other dstore services do a similar thing to get the miner ID. The benefit > > of this approach is that if we do any refactoring, the ID changes > > automatically. > > But that's the point. We must not do any refactoring because the miner ID is > part of the dstore protocol and thus part of external API. If we were to > refactor this, TM 2.x would no longer work against TM 2.0 servers, would it? > The miner ID isn't part of the dstore protocol, itself, it's really just the protocol for that particular miner. Are saying you don't want to be constrained by having the ID public - and would prefer that it were not external API? I'm presuming you want to have the option of refactoring the miner in TM 2.x (in the client code-based) - but the miner is already public API and therefore cannot be refactored in 2.x, can it?
I think that essentially, the miner ID is already API because if we went and refactored the miner into a different package for 3.0, then a 2.x client would not work against a 3.0 server (unless we provided a compatibility package). So what I'm saying is: - the miner ID is already API and cannot be changed/refactored without notice - therefore it should also be made explicit - therefore I'd recommend having it in a String constant rather than implicit through MinerClass.getClass().getName(). I opened bug #196624 for discussing this for the future -- it's not a very big issue though. Consequently marking this bug fixed again.
