Community
Participate
Working Groups
Currently RemoteFile.isArchive() will check the clients ArchiveHandlerManager to determine if a file is an archive. If the client has addition archive handlers installed that the remote server doesn't then isArchive() will return the wrong value. Possible Solutions: 1. Change isArchive(), so it queries the remote server to determine if a file is a supported Archive. 2. When we connect to a remote server synch up the archive handlers on the client and server. This is ideal, as it's unlikely users will rebuild the dstore server with the new Archive Handlers and if we can support it on the client we should be able to support it on the remote system. This bug was created from the discussion of bug #187427. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3 RSE install : RSE I20070713-0605 java.runtime : Sun 1.5.0_06-b05 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------
Actually this is a dstore only issue, since each subsystem is responsible itself for determining how isArchive() is computed -- it should be dstore's responsible to return the answer from the server's point of view, but it does return it from the client's point of view. I agree that the information about what kinds of archives are supported should be computed once at the beginning, when the dstore server is started (I guess that changing it once the server is running isn't possible anyways). I do not understand the comment "if we can support it on the client we should be able to support it on the remote system." -- can you explain? Xuan / DaveM could you give a comment whether this could be done without API change?
(In reply to comment #1) > I do not understand the comment "if we can support it on the client we should > be able to support it on the remote system." -- can you explain? What I meant is that if an archive handler is on the client, but not the server we should send the archive handler to the server. Or vice-versa. Since the same archive handler file works for local and dstore, the dstore server just needs the archive handler files. As Kushal said in bug #187427: "Ideally, if an archive handler is registered on the client or the server, it would automatically send to the other side if it's not there."
Ok, I see. Is the archive handler a single classfile? Getting it packaged, sent over the wire and installed into the live dstore server may be possible (Eclipse, for instance, also supports online updates), though this is certainly not a trivial job.
The dstore has a remote classloader mechanism which takes care of bringing classes (and their dependencies) from client to server or server to client. This can be used in cases such as where no miners exist on the host, yet there is a minerFile.dat indicating miners - in that case, dstore picks up the classes from the client.
