Hi Yu Wang,
My apologies, but I'm not an expert with DBCP.  I just thought I would do a
quick Google search to see what's out there and I found a few hits, one of
which I posted to my previous reply.  Since you seem to be interested in
encrypting the password being sent in to DBCP, you will probably need to do
something specific with the DBCP implementation either by modifying it
directly (like you mentioned in one of your replies) or maybe by extending
the BasicDataSource (my reference).  I don't have any direct experience with
either approach.  You might want to try posting your question to the DBCP
group [1].

Please keep us informed of your progress.  Thanks.

Kevin

[1]  http://commons.apache.org/dbcp/

On Mon, May 18, 2009 at 2:47 AM, wang yu <wangy...@gmail.com> wrote:

> Hi Kevin,
> Thanks.
> The link you gave indicate how to extend BasicDataSourceFactory. But I
> guess this approach isn't feasible for OpenJPA.
> I need to extend BasicDataSource directly, right?
> And you mentioned "there were other instructions on extending the
> BasicDataSource". Can you make it clearer?I found extending
> BasicDataSource isn't very straightforward.
>
> Regards,
> Yu Wang
>
> On Fri, May 15, 2009 at 9:56 PM, Kevin Sutter <kwsut...@gmail.com> wrote:
> > Hi Yu Wang,
> > Or, you could develop an answer for OpenJPA and contribute it back to the
> > project...  :-)  Providing an encryption capability for persistence.xml
> > password values would be a nice feature.  But, this would probably only
> > apply to our openjpa.* properties...
> >
> > In your particular case where you are passing in all of the parameters to
> > dbcp, I don't see how OpenJPA could help in this case.  The URL is just
> > passed through to dbcp, so any decryption of a password field would need
> to
> > be provided by dbcp.
> >
> > I did a quick search on this topic and found a few hits related to
> > encrypting passwords used for dbcp.  One link [1] indicated that using
> > Tomcat 6.0 makes this a bit easier, but there were other instructions on
> > extending the BasicDataSource.  This link was specific to Tomcat's
> > server.xml, but the idea could probably be extended to the
> persistence.xml.
> >
> > Let us know what you come up with.
> >
> > Thanks,
> > Kevin
> >
> > [1]
> >
> http://stackoverflow.com/questions/129160/how-to-avoid-storing-passwords-in-the-clear-for-tomcats-server-xml-resource-defi
> >
> >
> >
> > On Fri, May 15, 2009 at 2:33 AM, wang yu <wangy...@gmail.com> wrote:
> >
> >> Hi Kevin,
> >> Thank you. You had real good solutions but unfortunately neither of
> >> them is feasible for our project.
> >> We use Apache dbcp datasource to leverage DB connection pool and
> >> tomcat 5.5 as app server.
> >> Following is a fragment of our persistence.xml:
> >>                        <property name="openjpa.ConnectionDriverName"
> >> value="org.apache.commons.dbcp.BasicDataSource" />
> >>
> >>                        <property name="openjpa.ConnectionProperties"
> >>
> >>  value="driverClassName=org.apache.derby.jdbc.ClientDriver,
> >> url=jdbc:derby://localhost:1527/TSAM;create=true, username=app,
> >> password=app, maxActive=30, maxWait=10000,
> >> poolPreparedStatements=true" />
> >>
> >> How to encrypt password under  this situation? Or should I adopt
> >> alternative connection pool implementation to make password encryption
> >> easier?
> >>
> >> if no better solution, I guess I only have two choices
> >> 1. Give up apache dbcp.
> >> 2. Modify source code of apache dbcp.
> >>
> >> Regards,
> >> Yu Wang
> >>
> >>
> >>
> >>
> >> On Thu, May 14, 2009 at 10:54 PM, Kevin Sutter <kwsut...@gmail.com>
> wrote:
> >> > Hi,
> >> > JPA does not define this functionality.  You could pass in the
> password
> >> via
> >> > the application instead of hard-coding it in a persistence.xml.  Or,
> if
> >> you
> >> > are in an app server environment, you should use a jndi lookup of a
> >> > datasource.  This would be the most secure.
> >> >
> >> > Kevin
> >> >
> >> > On Tue, May 12, 2009 at 4:31 AM, wang yu <wangy...@gmail.com> wrote:
> >> >
> >> >> As title.
> >> >>
> >> >> Regards,
> >> >> Yu Wang
> >> >>
> >> >
> >>
> >
>

Reply via email to