Set DB username/password dynamically

I defined the following data source:

<bean id="DBPool" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName"><value>oracle.jdbc.driver.OracleDriver</value></property>
<property name="url"><value>jdbc

racle:thin:@localhost:1521:mydb</value></property>
<property name="username"><value>123</value></property>
<property name="password"><value>123</value></property>
</bean>

The username and password are hard-coded in the XML file. I would like to set this dynamically in my program. Is this possible?

Thanks in advance.

You can create the datasource programmatically instead of using dependency injection.

Jason.

Isn't setting it in code even worse hardcoding? You probably want to set it in some external properties/configuration file. Use the org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
to load these values from a config/props file.

The orignal question was how to set the values dynamically

I would like to set this dynamically in my program, Is this possible?

and I don't see the difference between storing the values in a xml file or a property file, both are static.

I wasn't suggesting harding coding the connection values, rather that it is possible to create a connection programatically i.e by not reading the values from a file.

Jason

[ March 30, 2006: Message edited by: Jason Moors ]
[ March 30, 2006: Message edited by: Jason Moors ]

Originally posted by Jason Moors:

The orignal question was how to set the values dynamically and I don't see the difference between storing the values in a xml file or a property file, both are static.

There is a huge difference. Your Spring configuration file is stored within your application ear/war and is not something you would want the deployer to be modifying. A property file is going to sit external to the application and typically be loaded via the classpath... this is something you would allow the deployer to modify. Regardless, I would suggest using your Application Server's datasource capabilities to manage the connection pool and then just wire it up as a JNDI object in Spring.

Maybe the UserCredentialsDataSourceAdapter is what you're looking for?

Originally posted by Chris Mathews:
Regardless, I would suggest using your Application Server's datasource capabilities to manage the connection pool and then just wire it up as a JNDI object in Spring.

That is, if you're using an Application Server... No need to have an application server just to get a connection pool. There are several open source alternatives out there.
[ April 01, 2006: Message edited by: Mattias Arthursson ]

Originally posted by Mattias Arthursson:
That is, if you're using an Application Server... No need to have an application server just to get a connection pool. There are several open source alternatives out there.

Definitely agree. Since 99% of Java Developers fall into the category of people deploying to an Application Server(Tomcat, Jetty, JBoss, WebLogic, WebSphere, etc.) I find it a safe bet to assume this is the case unless otherwise informed.

[ April 01, 2006: Message edited by: Chris Mathews ]

Originally posted by Chris Mathews:

Definitely agree. Since 99% of Java Developers fall into the category of people deploying to an Application Server(Tomcat, Jetty, JBoss, WebLogic, WebSphere, etc.) I find it a safe bet to assume this is the case unless otherwise informed.

Guess you could call Tomcat an app server, but I would usually refer to it as a web server (even though it does expose more J2EE features than I knew of - e.g. I was not aware that it provided a JNDI server).

Would there be any specific benefit of putting your datasource/db pool in JNDI when using e.g. Tomcat and Spring, in stead of wiring it up in your Spring context file?

The benefit of using the application server's datasource is the configuration and monitoring most application servers provide. If the password needs to be updated (which most organizations require extra X days) then the SA does so through a fairly straight-forward gui. If you want to see how many connections are currently in use or what the connection high stats are, the SA uses the same gui.

Configuring your datasource internal to the application can have some benefits you can't get from using the application server, especially if you are writing a product to sell to others. However, in most cases I don't want to give up ease of use (from an admin perspective) for the encapsulsation this type of solution would provide.