Strategies for managing resources/credentials?

[gemini929]

All,

When using an application server, it is easy for us to externalize how we obtain our resources and the credentials used to obtain them. When using Spring Batch in a stand-alone configuration, we don't have that functionality out of the box.

Can you provide some insight into how resources and the credentials used to obtain them are managed across different environments? I know that this is something that could be externallized into a properties file. I am hoping that there might be a better solution.

[Dave Syer]

I don't really understand why this is a Spring Batch question. Wouldn't the same question apply to any Spring application running in an app server? Properties files are one solution, but most people probably use the container resources via JNDI. Of course it depends on what kind of resource you are talking about, and whether your container manages them, but typically we are talking about things like JDBC DataSource and JMS ConnectionFactory, and those are usually available.

[gemini929]

Dave,

Your absolutely right. I suspect that many Spring Batch deployments are not run within an application server (I certainly could be wrong here). We are looking to do something similar, but need to figure out how to manage/externalize the credentials/configuration needed to connect to other resources.

In our current environment, the credentials/configuration is managed within the app server. The developer/deployer currently does not have access to this information in a production environment. Our operations team would like to keep it this way.

I was hoping to reach out to the community to see if there was a way to do something similar without using the app server. The closest I have come to is encrypting credentials in a text file.

[michael.lange]

can't you externalize the properties files and use a staging concept ?

- developer runs batch local with local/team-environment credentials (which he should know anyway)
- team creates batch.jar (or whatever) and sends it to production deployment team/guy
- production deployment team runs batch with production credentials
- production credentials could be encrypted, but the production deployers normally know the credentials, someone has to