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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
