John Grange wrote:
If I may add my two cents worth, here:
I agree with Paulo's comments. In addition, I would very much like to see
The injection of datasources to the datastores, instead of the setting
Of connection parameters in a map. If I am using spring jdbc access, I set
up a datasource (normally in the j2ee container) and inject that into my
spring beans. Why should I need to specify my database connection
parameters separately for geotools?
IMHO, it would be a better idea to refactor the connection pooling in
geotools to use apache dbcp if map parameters are supplied, or a supplied
datasource (poolable if necessary), if that is provided instead. Agreed,
you'd need to know what database you were connecting to, but that would be
possible from the underlying driver, or, if necessary, by adding a hint.
If I've missed the point, please tell me, but I have looked through the jdbc
datasource code (mainly for mysql/oracle) and this seems the best way
forward to me.
You have not missed the point, simply discovered a different one. My
Article was all set up for a conversation about how we should support
multiple versions (of Style, SLD, etc...), but your point is a good one
for improving the use of Factories in GeoTools.
The ability for geotools to make use of "Application" resources is
always a focus. The fact that J2EE applications manage JDBC datasources
on their own is well known. I have not scene a good idea (or patch) on
how this should be done?
With respect to apache dbcp - can you tell me more? GeoTools use outside
of J2EE is important as well ;-) We are not attached to the
DataStoreFactorySpi.PARAM class, it was a quick hack to build a
GeoServer user interface. The fact that most applications duck its use
(and the databases datastores have taken to having magic dbtype
parameters) kind of point to its failure.
Cheers,
Jody
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
