Hello,
Just to give an update on what I've effectively done with this.
I'm using a variation of the option #1, i.e., passing the PoolConfiguration
(or equivalent) aside the DataSource. I'm doing this because it lets me
define the clients of the base datasource as accepting a
javax.sql.DataSource, instead of the
org.apache.tomcat.jdbc.pool.DataSource, so the code is more general and
somewhat protected to spurious changes to the pool properties.
I'm creating "safe" copies of the PoolConfiguration object using reflection.
Thank you all.
Regards,
Germán
On Wed, Aug 8, 2012 at 4:08 PM, Germán Ferrari <german.ferr...@gmail.com>wrote:
> On Wed, Aug 8, 2012 at 3:11 PM, Martin Gainty <mgai...@hotmail.com> wrote:
>
>>
>> the test\java\org\apache\tomcat\jdbc\test\DefaulCase.java TC
>> builds the properties... then calls
>> BasicDataSourceFactory.createDataSource(p)
>>
>> protected void transferProperties() {
>> try {
>> Properties p = new Properties();
>> for (int i=0; i< ALL_PROPERTIES.length; i++) {
>> String name = "get" +
>> Character.toUpperCase(ALL_PROPERTIES[i].charAt(0)) +
>> ALL_PROPERTIES[i].substring(1);
>> String bname = "is" + name.substring(3);
>> Method get = null;
>> try {
>> get = PoolProperties.class.getMethod(name, new
>> Class[0]);
>> }catch (NoSuchMethodException x) {
>> try {
>> get = PoolProperties.class.getMethod(bname, new
>> Class[0]);
>> }catch (NoSuchMethodException x2) {
>> System.err.println(x2.getMessage());
>> }
>> }
>> if (get!=null) {
>> Object value =
>> get.invoke(datasource.getPoolProperties(), new Object[0]);
>> if (value!=null) {
>> p.setProperty(ALL_PROPERTIES[i],
>> value.toString());
>> }
>> }
>> }
>> tDatasource = (BasicDataSource)
>> BasicDataSourceFactory.createDataSource(p);
>> }catch (Exception x) {
>> x.printStackTrace();
>> }
>> }
>>
>> is there a reason why you would'nt use the available transferProperties
>> method from the Tomcat TestCase?
>> Martin
>>
>>
>
> Thank you for the pointer. The ALL_PROPERTIES array it's hard-coded in the
> test case, so it's not part of the library and I can't re-use it. I could
> copy it, but I would prefer not to do it.
> Anyway this snippet makes me reconsider to use reflection to make the
> copy, I think it's not a bad option for in my case.
>
> I would like to mention that in the tests I've been doing, I found that
> the PoolProperties serialization is not working because
> PoolProperties.InterceptorDefinition is not marked as Serializable. Should
> I report a bug?
>
> Regards,
> Germán
>
>
>>
>> > From: german.ferr...@gmail.com
>> > Date: Wed, 8 Aug 2012 14:20:22 -0300
>> > Subject: Re: tomcat-jdbc: correct way to create a new separated
>> org.apache.tomcat.jdbc.pool.DataSource from another one
>> > To: users@tomcat.apache.org
>> >
>> > On Wed, Aug 8, 2012 at 2:12 PM, Germán Ferrari <
>> german.ferr...@gmail.com>wrote:
>> > >
>> > > (...)
>> > >
>> >
>> > > For the moment I think I have three options:
>> > > 1. Change some interfaces to receive a Properties object with the pool
>> > > configuration and use the suggestion given by Daniel
>> > > 2. Cast the return of DataSource#getPoolProperties() to
>> PoolProperties and
>> > > use it's clone() method.
>> > >
>> > 3. Create a new PoolProperties and set all the properties manually to
>> use
>> > > the ones returned by DataSource#getPoolProperties()
>> > >
>> > > I think #2 is the closest to what I originally thought.
>> > >
>> >
>> > mmm... I misread the signature of PoolProperties#clone(), it's
>> protected...
>> > So I guess #2 is not an option...
>> >
>> >
>> >
>> > >
>> > > Regards,
>> > > Germán
>> > >
>> > >
>> > >> Martin
>> > >> ______________________________________________
>> > >> Verzicht und Vertraulichkeitanmerkung/Note de déni et de
>> confidentialité
>> > >>
>> > >> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
>> > >> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
>> unbefugte
>> > >> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
>> Nachricht
>> > >> dient lediglich dem Austausch von Informationen und entfaltet keine
>> > >> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
>> von
>> > >> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>> > >> Ce message est confidentiel et peut être privilégié. Si vous n'êtes
>> pas
>> > >> le destinataire prévu, nous te demandons avec bonté que pour
>> satisfaire
>> > >> informez l'expéditeur. N'importe quelle diffusion non autorisée ou
>> la copie
>> > >> de ceci est interdite. Ce message sert à l'information seulement et
>> n'aura
>> > >> pas n'importe quel effet légalement obligatoire. Étant donné que les
>> email
>> > >> peuvent facilement être sujets à la manipulation, nous ne pouvons
>> accepter
>> > >> aucune responsabilité pour le contenu fourni.
>> > >>
>> > >>
>> > >> > From: german.ferr...@gmail.com
>> > >> > Date: Wed, 8 Aug 2012 08:20:59 -0300
>> > >> > Subject: Re: tomcat-jdbc: correct way to create a new separated
>> > >> org.apache.tomcat.jdbc.pool.DataSource from another one
>> > >> > To: users@tomcat.apache.org
>> > >> >
>> > >> > Hello,
>> > >> >
>> > >> > On Tue, Aug 7, 2012 at 9:36 PM, Martin Gainty <mgai...@hotmail.com
>> >
>> > >> wrote:
>> > >> >
>> > >> > >
>> > >> > > Germán
>> > >> > >
>> > >> > > Is there a reason why you would not use
>> > >> > > org.apache.commons.dbcp.datasources.SharedPoolDataSource from
>> DBCP 1.4
>> > >> > > http://commons.apache.org/dbcp/apidocs/index.html
>> > >> >
>> > >> > ?
>> > >> >
>> > >> >
>> > >> > For what I've looked in the javadoc of that class, it serves a
>> somewhat
>> > >> > different use case. In my concrete use case, the usename and
>> password
>> > >> would
>> > >> > be the same, the main property I would want to change is the
>> maxActive
>> > >> > connections. I want to have a new data source, which is
>> independent of
>> > >> the
>> > >> > other, son I can potentially close one without affecting the other.
>> > >> >
>> > >> > Also, at this moment I'm not evaluating to change the connection
>> pooling
>> > >> > library.
>> > >> >
>> > >> > Regards,
>> > >> > Germán
>> > >> >
>> > >> >
>> > >> > > Martin
>> > >> > > ______________________________________________
>> > >> > > Verzicht und Vertraulichkeitanmerkung
>> > >> > >
>> > >> > > Diese Nachricht ist vertraulich. Sollten Sie nicht der
>> vorgesehene
>> > >> > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
>> > >> unbefugte
>> > >> > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
>> > >> Nachricht
>> > >> > > dient lediglich dem Austausch von Informationen und entfaltet
>> keine
>> > >> > > rechtliche Bindungswirkung. Aufgrund der leichten
>> Manipulierbarkeit
>> > >> von
>> > >> > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > > From: german.ferr...@gmail.com
>> > >> > > > Date: Tue, 7 Aug 2012 20:06:53 -0300
>> > >> > > > Subject: tomcat-jdbc: correct way to create a new separated
>> > >> > > org.apache.tomcat.jdbc.pool.DataSource from another one
>> > >> > > > To: users@tomcat.apache.org
>> > >> > > >
>> > >> > > > Hello.
>> > >> > > >
>> > >> > > > I have an use case in which I would want to copy an
>> > >> > > > `org.apache.tomcat.jdbc.pool.DataSource`, to have two disjoint
>> > >> connection
>> > >> > > > pools, with some pool properties changed.
>> > >> > > >
>> > >> > > > My first thought was to do something like this:
>> > >> > > >
>> > >> > > > PoolProperties props = new
>> > >> > > > PoolProperties(baseDataSource.getPoolProperties());
>> > >> > > > // set custom props ...
>> > >> > > > DataSource newDataSource = new DataSource(props);
>> > >> > > >
>> > >> > > >
>> > >> > > > The problem is that the PoolProperties class doesn't have such
>> > >> > > constructor.
>> > >> > > > Another option could be to share the PoolProperties object,
>> but,
>> > >> for what
>> > >> > > > I've looked into the code, it doesn't seem safe.
>> > >> > > >
>> > >> > > > The PoolProperties class implements the Cloneable interface,
>> so I
>> > >> guess
>> > >> > > > it's ok to use its clone method. The problem I have with this
>> > >> option is
>> > >> > > > that DataSource#getPoolProperties() returns a PoolConfiguration
>> > >> which
>> > >> > > > doesn't implements Cloneable. In my case I think it would be
>> safe
>> > >> to cast
>> > >> > > > the PoolConfiguration to PoolProperties, but it doesn't seem
>> safe
>> > >> for the
>> > >> > > > general case.
>> > >> > > >
>> > >> > > > What would be the correct way to create a new separated
>> DataSource
>> > >> from
>> > >> > > > another one having some properties changed?
>> > >> > > >
>> > >> > > > I'm using tomcat-jdbc 7.0.29 as a standalone library.
>> > >> > > >
>> > >> > > > Thank you.
>> > >> > > >
>> > >> > > > Regards,
>> > >> > > > Germán
>> > >> > >
>> > >> > >
>> > >>
>> > >>
>> > >
>> > >
>>
>>
>
>
