struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Sutton <>
Subject Re: [OT] Re: environment awareness (project stage in JSF)
Date Sun, 29 Jun 2008 15:41:39 GMT
(I've chopped some of the previous messages from the end for the benefit 
of those in digest mode).

I'm coming from the other side of the configuration debate; the side 
that says you should have the configuration file which shows whats 
happening as opposed to having "intelligent" defaults which hide 
configuration options from the deployer/support person.

So, for your class reloading example, if someone takes your framework, 
uses it in dev, does something which relies on the class being reloaded, 
and when the app is moved into production it suddently doesn't you'll 
end up with the person building on your code going "It works for me". 
You can't rely on people reading documents, you can't rely on them 
knowing a few years down the line what you choice of dev, test, and 
production settings were, and therefore knowing what behaviour to expect.

I disagree that there is configuration defined by environment deployment 
people but managed by developers. Managers of the environment should be 
able to manage the configuration, developers should only have an 
advisory role. The product my company produces is running in well over a 
hundred different companies, can you imagine the reponse we would get if 
we said that we were the only people who could change it's 
configuration?, if we had to be involved if their changed their servers, 
clustering solution, database, or anything else related to the app?, and 
the increase in support work for us because we imposed that rule? we 
wouldn't make anywhere near the sales of the product we do. One of the 
things companies look for is the solution to the "If the development 
company goes bust can we run without them?", and how can they do that if 
the development company is the only people who can make changes to 

You can set some best guess values for things like cache sizes, thread 
pools, etc., but the end user should still be able to alter them 
hopefully with the advice of a developer. You put disclaimers saying 
things like "Altering these values without our involvements is not 
advised and may result in an non-working application", but you still 
shouldn't stop them doing it. If there is spare techie time and they 
want to test a P4 server against a Q6600 server against a virtualised 
multi-core machine on a massive multi-CPU box then thats something they 
should be able to do without having to call the developer every time 
they want to try something new.

This could be a difference in viewpoint that we have based on our 
experience (I get the feeling your app is designed for deployment in 
environments you t have a fair amount of control over), but for me apps 
should never enforce configuration changes on users purely based on what 
environment they in, the deployment/support folk should always be able 
to change things when neccessary (including dropping down thread pool 
sizes if they need to run the app on a less powerful server in an 


Brian Pontarelli wrote:
> I've written code that uses environment. Of course, I mainly write 
> frameworks, so it probably makes more sense there, but I have used 
> environment to dictate code rules. Eager singletons versus on-demand 
> singletons, class-reloading, etc. I think it breaks down to this 
> question, "is there a convention that is based on environment where 
> adding configuration would incur unnecessary overhead?"
> Take class-reloading as an example. The answer to the question would 
> be yes. The convention is that in development reload and in production 
> don't. You could use a configuration parameter with a default value 
> that says reload, but then the developer has to remember to add the 
> configuration for production to turn it off. For me, it often comes 
> down to being pragmatic about it while reducing configuration whenever 
> possible. So, I think code still needs access to the environment.
> In terms of configuration, it falls out into these rough areas:
> - There are configuration that should be defined by environment 
> deployment folks, like computer names, but managed by developers 
> (since after-all we are going to be using that configuration). Those 
> folks should understand where the configuration lives and possibly how 
> to change it, but not without consulting developers who wrote the code 
> that uses it.
> - There are configuration that should only be managed by developers 
> and still vary by environment, like cache sizes, thread pools, 
> heuristics, etc. This shouldn't be touched by anyone else, but support 
> staff can make recommendations and then developers can implement.
> - There are configurations that shouldn't change by environment. 
> Usually things like security configuration, kill-switches, etc. These 
> are the same everywhere and you only change them if something goes wrong.
> In all cases, the configuration should be changing per environment and 
> not the code. So, back to the original statements, I think none of 
> this is really about laziness. I think that's a poor wording. I think 
> it is really more about application integrity and making the correct 
> decisions that will ensure the application doesn't get into production 
> and explode. However, the more ability to manage the better. I 
> personally feel that all frameworks, tools, servers, etc, should be 
> environment aware. Be nice to have web-development.xml and 
> web-default.xml. Currently, there are just too many things that need 
> to be wrapped, adapted and proxied because they don't understand 
> environment.
> -bp

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message