OK... i went around on this one a couple of times... decided in the end to
just do the bare minimum to get JDBCDataStoreFactory to delegate to
DataSourceFactorySpi. Here is a first cut.
https://github.com/jdeolive/geotools/commit/ac06cb8edf8715ac33cc97d50da8f0ae81f38637
I still need to test it on a few more databases but h2 and postgis show no
problems.
On Thu, Nov 15, 2012 at 6:28 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Wed, Nov 14, 2012 at 6:02 AM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> Hi all,
>>
>> I am experimenting with a way to supply my own customized DataSource
>> wrapper to a jdbc datastore. Basically my use case is playing with a
>> connection proxy library like log4jdbc to log some more extended
>> information about connections, monitor possible connection leaks, etc...
>>
>> Now, I know that I can pass in a direct DataSource implementation into a
>> datastore via the JDBCDAtaStoreFactory.DATASOURCE parameter but that isn't
>> ideal for my case as I want to use this in situations like GeoServer where
>> data stores are created from serialized connection parameters, and I want
>> something that will be or less transparent to that process. I looked at the
>> ConnectionLifecycleListener stuff, which while very nice and gets me part
>> of what i want, doesn't do it all since i actually need to wrap
>> connections.
>>
>> So... looking around I actually see something that fits the bill in the
>> shape of DataSourceFactorySpi. As far as i can tell though this api isn't
>> really used at all by the jdbc datastore subsystem, well for creation of a
>> data source at least. The only usage from jdbc itself seems to be the
>> UnWrapper interface which is used by oracle to access the native oracle
>> connection. The api does seem to be used in coverage land by imagemosaic
>> for creating a jdbc datasource for the tile index (or so i assume).
>>
>> Basically what I was thinking was something like adding
>> a DataSourceFactorySpi member to JDBCDataStoreFactory, the default value of
>> which being a factory that creates a dbcp data source like is done today.
>> By making the member settable it should be easy enough to specify your own
>> custom DataSource. It would look something like:
>>
>> Map connectionParams = ...
>> JDBCDAtaStoreFactory factory = getFactoryFromParams(connectionParams);
>> factory.setDataSourceFactory(new MyCustomDataSourceFactory());
>>
>>
>> Long story short I can think of two approaches (and alternatives very
>> welcome).
>>
>> 1. Try to utilize DataStoreFactorySpi
>> 2. Roll a more specific interface for this case
>>
>> I spent some time exploring option (1), but there are a couple of
>> obstacles with it. The main one is that DataStoreFactorySpi implementations
>> use different parameters than JDBCDataStoreFactory does. The parameters are
>> similar, but different enough. For instance the DBCPDataSourceFactory uses
>> "username"/"password" rather than "user"/"passwd".
>> The DBCPDataSourceFactory also misses a number of parameters such as
>> prepared statement pooling options, connection timeout, validation, etc...
>>
>> I couldn't come up with a great solution for this. I experimented with a
>> sub interface named DataStoreFactorySpi2 that added the following method:
>>
>> Map convertDataStoreParameters(Map params, JDBCDataStoreFactory
>> dataStoreFactory, SQLDialect dialect)
>>
>>
>> Which basically transformed the dataStore factory parameters to the ones
>> needed by the data source. This kind of worked but was pretty messy as much
>> of the data source configuration logic is dependent on the dialect itself,
>> whether its prepared statement or not, etc... This option also requires
>> more or less duplicating all the connection parameters from the data store,
>> etc...
>>
>> So... (1) is probably doable, but far from trivial and could get messy.
>>
>>
>> Approach (2) would really just be the simplest thing I can think of.
>> Basically the interface would be the
>> JDBCDataStoreFactory.createDataStore(Map, SQLDialect) method factored out
>> into an interace:
>>
>> interface JDBCDataSource[Factory|Builder|Creator|WWW] {
>>
>> DataSource createDataSource(Map params, SQLDialect dialect);
>>
>> }
>>
>>
>> With the default implementation doing exactly what the existing method
>> does today, and that is return a BasicDataSource, wrapped in the manageable
>> DBCPDataSource wrapper. An alternative implementation would be used by
>> the JDBCJNDIDataStoreFactory.
>>
>>
>> Any thoughts or suggestions?
>>
>
> The DataSourceFactorySpi was though to give the possibility of creating
> new connection pools,
> but the initial attempt of using C3P0 did not provide the expected
> results, so it was left
> there to languish.
>
> I'd say, please revive it. Make the necessary changes, as you said it's
> not used much anyways,
> so there is little harm in changing some param names.
> It's going to be less confusing than rolling a sibling interface
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
