On 27/07/2011 9:43 AM, Daniel Serodio (lists) wrote:
Ansgar Konermann wrote:
Am 25.07.2011 22:13, schrieb Daniel Serodio (lists):
Do you think using a classifier to differentiate artifacts built for
development and production is "hacky", is is this an appropriate
solution?
Use the same *artifacts* for all stages and allow for *configuring* the
relevant properties of your application at runtime/startup time, as much
as possible.
A common mechanism to configure things at runtime is using JNDI
parameters.
I'mconsidering changing our build process. Setting up the DB using
JNDI is easy enough, but how do you suggest we deal with different
logging configurations, which differ not only on some values, but
structure (ie log4j Loggers and Appenders with different classes, file
paths and severity thresholds) ?
In our view, the production logging ( also log4j ) is an operations
function and not an application development issue and should be fixed
for all versions running in production and not vary from release to
release except for major changes where new logs are required or some
horrible intermittent problem in production where custom logging is
required.
These are setup as separate projects in our source control (Subversion)
and are installed as part of the servlet engine configuration by someone
acting as an Operations system manager.
The test (customer acceptance) server is similar.
Individual test servers (PCs or shared virtual machines) are left to the
programmers to sort out.
Having the logging and other server dependent configurations treated as
operational issues makes it less likely that something creeps from a
developer's environment into production.
We are a small shop so it is more of a question of what hat you are
wearing when you do something, rather than dedicated jobs but we try to
be as professional as the bigger shops.
Our customers expect our production servers to run as well as the big
guys' and our updates to go in cleanly.
I hope that this helps.
Ron
Regards,
Daniel Serodio
---------------------------------------------------------------------
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]
