> The documentation for RuntimeInstance.setConfiguration does not state > that the parameter is modified, so it's rude to modify it.
Ah that makes sense. >Actually, if Velocity supports this, then you can use your own >implementation of ExtendedProperties regardless of the response from the >commons collections folks. I think this is the most flexibile solution, any Velocity developers care to comment ? Thanks, Charlei -----Original Message----- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Wed 5/7/2008 8:21 AM To: Velocity Developers List Subject: Re: Expanding Environmental variables patch Charles, Sanders, Charles wrote: >> I actually dislike modifying passed-in parameters > > Why? The documentation for RuntimeInstance.setConfiguration does not state that the parameter is modified, so it's rude to modify it. Don't forget that the documentation is part of the API, too, and it's supposed to be a stable API. If you need to modify the ExtendedProperties, create a new one instead and modify that one. >> I'm a little curious why this capability needs to be added to Velocity >> in the first place. Does anybody really use environment variables >> anymore, anyway? > > Err, you don't use JAVA_HOME? I'm guessing you're not a *nix user ? I've never deployed anything on Microsoft Windows. Nobody uses environment variables anymore, even on *NIX. It's system properties, baby. System.getProperty("java.home") > The reason I want them in Velocity, is file.resource.loader.path only > accepts a full path. With several developers working on a project its a > pain to have explain how to update this for everyone who wants to run > the project. I understand the utility of properties files that know how to resolve references. I'm just not sure I understand why Velocity needs to do this and not the Properties implementation. By the way, another way to achieve your goal is to use a build script that replaces variables for you. Check out Apache ant, which comes with a whole host of utilities geared toward this purpose. > I agree the ExtendedProperties class is what needs patching, I don't > know how receptive they will be though. I'm sure they will be receptive. Instead of a patch, why not submit an entirely new class called EnvironmentExpandingExtendedProperties which extends ExtendedProperties. The methods you would have to override would be addProperty, combine, convertProperties, setProperty, and possibly the "load" methods. Even better, if you read the source code for ExtendedProperties you may find that every method used "interpolate" in order to replace parameterized keys and values. In that case, simply override interpolate() and your job is done. If you configure Velocity programatically, then you are done. If you use configuration files, you'll need to ask the Velocity folks to either replace their use of ExtendedProperties in their config file loader with EnvironmentExpandingExtendedProperties (which I doubt they'd do) or allow you to specify the ExtendedProperties subclass to use when loading configuration (which makes more sense anyway, and is more likely to actually be done). Actually, if Velocity supports this, then you can use your own implementation of ExtendedProperties regardless of the response from the commons collections folks. -chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
