struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: [OT] Re: environment awareness (project stage in JSF)
Date Sun, 29 Jun 2008 19:03:17 GMT
I'll reply inline quickly.

> 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.

In my experience, this is painful for any application of size. I've  
even written frameworks to ensure configuration setup like this is  
correct. It's not a good way to manage large complex applications from  
my perspective.

> 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.

You appear to aggressively debate things that are de-facto in other  
languages and many situations. Look at Rails, Grails, Turbogears,  
Django, etc. Heck, even Struts2 suggests that for a production system  
you disable caching of FTLs. Most production systems don't check JSPs  
for reloading. If developers want to make assumptions around things  
that are conventions, they need to figure them out on their own or use  
a different system. Assuming your audience aren't going to be good  
citizens is not a good place to start in my opinion.

> 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 configuration?

Defined = Filled out or selected or configured.
Managed = Code against.

They still shouldn't go changing things without asking the developer.  
If I coded an application to expect the configuration they are  
defining to hit an specific type of JMS server or distributed cache  
and then they change it to hit a different cluster or smaller cluster  
I might not be too happy about that.

> 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.

Yep. But I'm not certain this applies for everything. I'd much rather  
be able to dictate certain behavior in some cases. The Inversoft  
Profanity WebService, which customers can purchase and deploy, can be  
set into production mode which dictates certain types of behavior.  
That's really all I'm saying.


> 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 emergency).

Yes and no. I just think it is not very pragmatic to discount certain  
things. I can understand the need for other folks to manage some  
configuration, but this is not always the case. I just feel you are  
being too strict in your analysis. Your situation might call for  
certain things but saying that adding environmental awareness to JSF  
makes people lazy is rather short-sighted in my opinion.

-bp




>
>
> Al.
>
> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message