Chapter 7. Setting Up an Application s Infrastructure

I l @ ve RuBoard

Chapter 7. Setting Up an Application's Infrastructure

IN THIS CHAPTER

• Build Management

• Logging and Database Connection Pooling

• Configuring Turbine

• Using Turbine Connection Pooling

• Using Log4J

• Customizing Log4J

• Getting Ready to Code

• Summary

So here you are, ready to start deploying the application. But before you do, you need to get some tools in place to make sure you do things right. Sometimes the tools that you use to build something can make as much difference in the quality of the finished product as your skill in using them, so it pays to pick the right tools to begin with. Just as beautiful houses are built on strong foundations, a well-functioning application depends on a strong infrastructure to support it.

It might seem like we're spending a lot of time setting up an infrastructure instead of working on the problem. There's a good reason for this, as anyone who has worked on a large project with multiple developers can attest.

If you don't set out standard coding practices early, you can spend half your time getting all the code in shape at the end of the project. For example, if everyone simply does their own database connection management, you can end up with too many connections open at once, or one group of developers might be sloppy and leave connections open .

This can be especially critical because connection leaks (and other types of resource leaks in general) are an insidious type of bug. They don't tend to show up during initial testing because a developer probably runs the application only for a few minutes, verifies that it works, and then shuts it down again.

It's not until later, during stress testing (or, worse , in live deployment), that you might find your application mysteriously dying after it has run for a while because some critical resource, such as the database connections, has been exhausted.

Similarly, if everyone does their own logging, it can become difficult to consolidate formats so that automated tools can monitor the logs for problems. You might find that you need to standardize not only the logging tools, but the syntax of the log messages themselves .

Another good candidate for standardization is internationalization of message strings. Essentially, anything that needs to be used site-wide should be standardized.

That said, you can leverage existing technologies for a number of subsystems or tasks . Specifically, they are build management, database connection pooling, and logging.

I l @ ve RuBoard