@talawahdotnet actually, there was an undocumented feature that allows the file database.properties to be called anything and reside anywhere. I just documented it here: http://javalite.io/database_connection_management#location-of-property-file

I think it solves this issue by large without any environment variables.

@talawahdotnet , ultimately I think this is not that important because in production you do not really use this file, but rather configure database connection pool using standard container tools, so for instance on our production, the configuration looks like this:

java:comp/env/jdbc/proj1

Then, the Java container is used to configure this to point to a DB using a pool. In the end, the passwords end up in container configuration files, but... if a hacker got a hold of your box, a property file with DB access is least of your concerns :)

I agree that if a hacker compromises the box then it is game over, I am just more interested in keeping all passwords (including the ones for test/qa and dev) outside of source control.

The alternate property file location is interesting, but I was hoping for something that worked a little more smoothly with the default mechanisms provided by the Heroku and AWS i.e. env vars and sys properties.

I didn't realize I could mix and match url/user/pass and jndi for different environments in the same properties file. I guess I can use that as a workaround since I can use system properties in JNDI definition in Tomcat's context.xml. I guess can settle for dev passwords under source control as long as QA/PROD ones aren't. It still makes me feel a little dirty though lol

@talawahdotnet I do not see this as a workaround and it does not make me feel dirty :).
Adding code to manage env vars and system properties will add confusion for people. Also, the mantra of this framework: as little configuration as possible.
If you are paranoid to add dev passwords to sources, you can use the file configuration in dev. env. too, and this will allow different developers to manage different passwords on their dev. boxes.
Ultimately your passwords will be in some files on QA/Prod, just not under source control.

@talawahdotnet, I want to close this as a non-issue. Have you solved your problem?

Sure, this can be closed. I am able to use system properties to configure JNDI for QA and PROD and I can live with hard coding the username and password in database.properties for the DEV environment.

Actually I just ran into another related issue, not sure if I need to open a separate ticket or perhaps you can clarify.

When org/junit/Test.class is on the classpath, DB.java has a hack in place that forces the environment to be "test" even if another value was specified in the environment variable.

I am not sure I understand the original intention, but it seems to have the side-effect of forcing tests run on my development environment and tests run on my QA environment to both use the same set of credentials since Junit is present in both cases.

@talawahdotnet yes, this is kind of a hack. In development environment you have two databases: test and development, so this is more of a "mode" in dev. env. This is how it picks up correct DB connection parameters. You should not be including JUnit in your build anywhere other than dev.

You should not be including JUnit in your build anywhere other than dev.

What about using a CI server like Jenkins to execute automated unit tests in a QA environment. Seems like a legitimate use case to me.

@talawahdotnet , this is totally fine, as this is exactly how we run these projects in Jenkins. You do need a test database on Jenkins, correct?

Yes, I need to connect to a database on Jenkins, but it is a different database from what I use to execute unit tests in development.

All I am saying is that I just don't think the hack should override the environment variable. The environment variable should give you full control.

Right now the hack forces you to use the same credentials for running tests in development and QA/CI

@talawahdotnet you might be right. Let me think about for a couple of days. What you are proposing would be correct, but will require explicit configuration for every environment. The current hack is.. a hack, but it is quite convenient because it requires less configuration.

@talawahdotnet , you are right on both accounts (what was I thinking - lol!).
I removed the hack and added a capability to configure from environment variables as well as from system properties, please see here: http://javalite.io/database_connection_management#environment-variables-override

Please, give it a try see if it works for you. I'd like to cut a new release (long over due), so that this change gets into it.

Great. Haven't tested it yet, but taking a look at the commit it looks like you have a copy/paste typo in Configuration.java.

In overrideFromSystemProperties() you call System.getProperty on "activejdbc.user" 2 extra times where you should be referencing "activejdbc.password" and "activejdbc.driver".

Funnily enough the documentation has the same error as well. At least it is consistent :)

@talawahdotnet thanks for catching this. However, our Jenkins instance is down, and in the process of rebuilding. At the earliest the new snapshot will be available close to end of this week. If you want to try this sooner, you can pull code and build from sources.

Funnily enough the documentation has the same error as well. At least it is consistent :)

you cannot underestimate the power of copy/paste! At least you can see the process: code becomes docs :)

re-opening to add override for jndi as well

@talawahtech are you using this feature? It is possible that a slight change will be coming soon, it will require a single line of code.

@ipolevoy, no I am not working with that codebase at all anymore, but thanks for checking.