Community
Participate
Working Groups
The javadoc for IRuntime.getLocation() reads as follows: /** * Returns the absolute path in the local file system to the root of the runtime, * typically the installation directory. * * @return the location of this runtime, or <code>null</code> if none */ The javadoc here requires that a valid absolute path is returned by IRuntime.getLocation(), and the behavior of this code simply pulls it from the datastore of the runtime object. Since this is a method on IRuntime, adopters have no ability to override it or participate in returning it. The delegate is not consulted at all, and so any value that is stored inside the IRuntime is currently returned unmodified for the most part. The request here is to allow variables to be in the path, and to have the servertools framework resolve those variables before returning the location. In this way, one may perform something like setLocation("/home/rob/some/${variable}/") and to have getLocation() return a resolved string. This would require server.core to add a dependency on org.eclipse.core.variables to do the resolution. This also would mean that clients who use a IRuntimeLifecycleListener to be informed in a change of the location will no longer be able to trust the returned value, unless, we get wst.server to also listen for changes in the IStringVariableManager and to force runtime objects to re-resolve their location value and fire events if the resolved path has changed. This further means that the use of Dynamic variables should be forbidden, as there is no listener framework for being informed when they change, and would likely lead to too many events being fired. An alternative is that you change the javadoc on IRuntime.getLocation() to indicate the path may have unresolved elements or is not guaranteed to exist. This would leave resolution of the string up to the client entirely. A further alternative would be to introduce a method in RuntimeDelegate to aid in resolving the string before returning it to the user. This would ensure that an absolute IPath is returned, but it would hinder clients who were trusting their IRuntimeLifecycleListener to be informed of all changes in any value stored on the IRuntime.
