2Paths Team Blog

In every team, there is a dynamic energy that brings it together. We recognize that the individuals in our team are not only critical to our success, but are also motivated by it: the key is simply to enable each of us to most effectively play our part.

As a small shop, we must all play different roles at different times. Our effectiveness is based on adapting to the shifting demands on our team throughout the project lifecycle. Each of our developers is both a specialist and a generalist. Besides constantly enhancing our general abilities, we actively cultivate complementary individual specialization, enhancing our ability to deliver technically distinguished software.

While shifting roles and specialization help us remain interested and committed, effective leadership is required to ensure everyone is playing the right role at the right time. We are oriented to shift roles as needed, and this includes the leadership role. While some team members possess natural leadership skills, others have particular knowledge and insights which are critical at certain points in a project. Smoothly transitioning leadership — sometimes on a daily basis — is a sign that our team is adapting well to the shifting needs of the project.

Such a dynamic culture is only possible with timely open communication. This includes communication between our team and the client, as well as within our team. We need to quickly share information as it becomes available. At a minimum, we have internal daily project meetings, and must be ready to remove impediments as they arise. We require our client to be available throughout the project to provide clarification and direction as needed.

Its not easy to establish and maintain such a dynamic team environment, but it is highly effective. We are able to deliver high quality software more effectively than either a solo developer or a large organization. This is very rewarding for all of us, which galvanizes our commitment to pursue and refine our approach.

Most Java applications will need some context specific configuration when deploying to a certain environment. This configuration could be username, password and JDBC URL for a specific database configuration or the details of an SMTP server for java mail deployments amongst others.

There are many ways to to provide runtime configurations for Java applications. For web applications, two popular mechanisms are the use JNDI configurations managers and using properties files. Both mechanisms have their limitations and caveats.

When using The Spring Framework, we are presented with a few more options to enable configuring web app projects.

The traditional approach involves using property placeholders which are then munged at runtime with a specific properties file to ensure the placeholders have valid values before executing the application. Another approach is using the newer (Spring 2.0) PropertOverrideConfigurer to override pbean definition properties at application startup. This approach allows the default spring config file to be usuable w/out needing a valid property file as no placeholders exist in the config itself but properties are merely overridden at runtime if need be. This is slightly nicer as it means that a default spring context XML config file will run w/out needing any special property merging. This allows for projects to be run within an IDE (like Eclipse) without having to jump through hoops or run special ant/maven targets to stick the correct properties file in the classpath when wanting to run your app embedded in Eclipse.

Essentially, the default Spring context configuration will work out of the box but can be overridden at runtime with other property file based properties to ensure things run properly at deployment. It’s not that dissimilar to the PropertPlaceholderConfigurer but allows for an easier workflow when wishing to work seamlessly with an IDE.

Not sure if any of this makes sense but there is more info out on the InterWeb:

• PropertyOverrideConfigurer
• configuration-management-with-spring