On 10/3/06, Mark Barnes <[EMAIL PROTECTED]> wrote:
Hi, All -
I originally submitted this to Commons User some time ago, but no reply.
I know that method org.apache.commons.dbcp.BasicDataSource.getConnection(String
username, String password) winds up throwing an UnsuppoterdOperationException
via its delegate, org.apache.commons.dbcp.PoolingDataSource.
My question is, can anyone who knows why this was done please let me know?
I can't speak for the original designers, but it makes sense to me
that a connection pool wrapper such as BasicDataSource would not
support this. BasicDataSource provides access to a pool of
connections that with a common set of connection properties when it is
initialized. To support getConnection(username, password), the pool
would have to be recreated if the actual parameters were different. I
suppose that is possible and the same thing should be possible using
setUsername, setPassword, getConnection; but the latter actually does
not work. If you (or anyone else) feels strongly enough about the
need to be able to regen the pool with different user, pass
credentials, then pls open a ticket. It looks like support for doing
this after the setXxx above was planned at some point, but never
implemented (cf restartNeeded instance variable).
I've googled and googled for an answer, but have not been able to find one.
Why the non-standard API?
Why methods getUsername() and getPassword()?
All config properties are exposed via javabeans properties. Is your
concern about this security-related?
Why store the username and password as plain text?
I don't know what you mean here. These parameters are passed to the
connection factory used to open the actual connections. They are not
"stored" anywhere other than in memory.
On my current project, placing the database username and password in a file on
disk is not allowed, due to security concerns, so using a Container-managed
DataSource is not possible.
Do you mean stored in the code? If you want to store the credentials
encypted somewheret and have a component decrypt and pass them to
BasicDataSource at initialization time, you can do that, but there is
no facility built in to [dbcp] to support the crypto, and I don't
think that we be good separation of concerns. The [dbcp] component
just needs the unencrypted parameters to store in memory and pass on
to the driver. If having these credentials in memory as properties is
a concern, that will be difficutl to address.
Phil
My thanks to anyone who can provide information and insight.
---Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
