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
> > >> > >
> > >> > >
> > >>
> > >>
> > >
> > >
>
>
