I think the concept is an idea which will appeal to lazy developers.
Why on earth would you want to put conditionals into your code that you
know will only evaluate to a set value in the environment they run in?
If anything it makes problems harder to track down because if someone
takes a copy of the app from a production machine to a dev machine to
further investigate a problem it will behave differently, which is just
a hiding to nowhere in multi-threaded apps such as S2 webapps.
An example of one of the "joys" that can come from this type of idea
came from a project I worked on where a coder used log4j and isDebug to
conditionally build a log string and log some extra data. This might be
seen as a good idea, except the code within the conditional block didn't
properly check all the objects were not null and under certain
functionally valid conditions an NPE was thrown, so when a problem arose
in production at a customers site they were asked to turn debug logging
on and all that they sent back was a log with an number of NPEs which
didn't relate to the original problem.
Ohhh the fun we had explaining that a new release had to go through
their change (long) control procedure just so we could find out what the
original problem was and until that we we're kind of stuffed finding out
what in their environment triggered the problem.
Yes in an ideal world it shouldn't have happened. Yes it probably should
have been picked up by some QA test somewhere. But don't we all live in
the real world?
Al.
Chris Pratt wrote:
We use something similar in our system. The system uses a bunch of
resource bundles that are separated into logical domains, and each
entry can be overridden by a local file on each machine. Plus each
entry can be scoped by environment (production, test, development),
machine, or application name (in case multiple applications are
sharing a library component). We have log4j and spring configurers so
that it is tightly integrated into the tools we use. It's saved us an
eternity of time tracking down bugs from one environment to the next
since we deploy the same WAR file that was accepted by the quality
assurance group into production and let the configuration take care of
itself.
I've often thought of creating a Google Code project to open source
it, but wasn't sure if there would be enough interest.
(*Chris*)
On Fri, Jun 27, 2008 at 1:38 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Yeah, I found that environment resolution was a key feature for any large
application. At Orbitz we could deploy the same bundle to any server and the
bundle would figure out where it was and configure itself for that
environment. Worked really well.
I have also provided this type of feature in JCatapult using an API that can
be implemented however developers need. The default implementation uses
JNDI, but it is simple to change it. The nice thing about that is you can
assume at all times that the environment is available and make assumptions
around that.
-bp
On Jun 27, 2008, at 1:53 PM, Frank W. Zammetti wrote:
We d something similar as well, but we decided to use a simple env var in
all environments... So the exact same EAR can deploy to any environment and
the code within simply looks for that var and acts accordingly. Simple but
highly effective.
Frank
-----Original Message-----
From: Ian Roughley <[EMAIL PROTECTED]>
Sent: Friday, June 27, 2008 2:59 PM
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: environment awareness (project stage in JSF)
I've actually had to implement this type of feature in multiple
enterprise applications. However, I would say that it's not knowing the
environment, but being able to change configuration elements per
environment that is important (for what I did, and in rails I think this
is the most important elements). i.e. change the SMTP, temp file dir,
admin user email address, etc. depending on whether you are testing
locally vs. production.
If developers are using spring, there is a way to load property files
with a hostname extension (which is one solution) - but should we always
expect users to be using Spring? The other question is being able to
modify struts.property properties depending on env (i.e. devMode=true in
development and never in production).
/Ian
Antonio Petrelli wrote:
2008/6/27 James Holmes <[EMAIL PROTECTED]>:
http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2
I like it. This is one of the features of RoR that I really found useful
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
