Community
Participate
Working Groups
AbstractRemoteProcessBuilder.environment() just does remoteEnv.putAll(System.getenv());, which sets the environment to be whatever is on the local system, which is not exactly useful for the remote case. None of the child classes override this behaviour.
Would making this an abstract method and moving the implementation to the child classes be sufficient?
(In reply to comment #1) > Would making this an abstract method and moving the implementation to the child > classes be sufficient? Provided that we're going to make some sensible implementations for the child classes, yes.
Ok, I've moved the implementations to the child classes. Any suggestions on what would make sense for the remote versions?
For Remote Tools, remoteEnv.putAll(System.getenv()) certainly does not make sense. Short term solution: Leaving the remoteEnv empty for RemoteToolsProcessBuilder. The map remoteEnv contains only variables to be added to the default remote environment. I understand that this differs from the LocalProcessBuilder and also differs from the expected behavior. But this solution is better then the current approach. Reason for the short term solution: The current implementation always inherits the remote environment for new remote processes. Therefore, there is no need to explicitly set the default environment variables. Furthermore, having many environment variables in remoteEnv will increase significantly the length of the command line generated by RemoteProcessBuilder. I am not sure if there is a maximal for a command line handled by SSH and the shall. This might be an issue for many environment variables. Long term solution: Add environment variables support to processes created by RemoteTools, using SSH support for environment variables. Unfortunately, at the time that RemoteTools was implemented, the underling Jsch library did not support environment variables. Therefore, RemoteTools uses the workaround that inherits environment variables instead of overriding. Alternative solution: RemoteTools queries the default environment variables on the remote host and initializes remoteEnv with these variables. In oder to create the command line, RemoteProcessBuilder calculates the difference between remoteEnv and the original remote environment queried before. The command line uses the 'env' command to adapt the inherited default environment based on the calculated difference(s).
(In reply to comment #3) > Ok, I've moved the implementations to the child classes. Any suggestions on what > would make sense for the remote versions? I'm working on a patch for the RSE provider. It has APIs for getting the remote environment.
Once this environment variables issue has been fixed, we need o address other related issues described in bug #239251.
Created attachment 107327 [details] proposed patch for RSE process builde
I've applied this patch. I guess we need a similar one for remote tools?
I have already commited a similar solution for remote tools.
