John Grange wrote:
The use of dbcp would then allow exactly the same constructor to be used in
and outside of a J2EE container (if the developer sets up their own
javax.sql.DataSource), or allow the existing model to be used transparently.
Having looked at the code, there would be a reasonable amount of legwork
involved, but it does not look difficult.
Any more questions I'll try to help.
Thanks for the detail, my focus here is on keeping GeoTools general (and
getting rid of non geospatial "Cruft" that is better served by other
projects). What I was interested in was your impressions/enthusiasm for
DBCP. If I can be blunt, is this technique specific to Databases and
JDBC Connections? We need to use a facility that allows us to manage a
wide range of
resources/connections in one fell swoop.
<evangelize>Oh, just as another plug for spring - go take a look at the JDBC
stuff they've got - makes JDBC code like it should have been!!! Takes
datasource directly and no need to manage closure of connections/resultsets
- never write a finally {connection.close();} again.
http://static.springframework.org/spring/docs/1.2.x/reference/jdbc.html
</evangelize>
Lol - it does look like Justin made a good decision with Spring. I will
try and catch up. I am tempted to test geotools against Spring and
PicoContainer just to keep
the toolkit "honest". As for SPI it is simply a technique for finding
plugins, my understanding is NanoContainer may offer a replacement?
Eclipse Equinox also looks like a more mature OSGi based replacement
(also as it is involved with the JCP it may end up being Java the
replacement for SPI). SPI is not pushed as a "the" formal Java extension
mechanism, we just adopted it as far as I can tell.
Cheers (and thanks for the feedback). As long as I am asking do you have
any thoughts on the "point" of that article (aka how we should allow for
multiple versions of a specification?).
Jody
Regards,
John Grange
-----Original Message-----
From: Jody Garnett [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 12:52 AM
To: John Grange
Cc: "'\"P.Rizzi Ag.Mobilità Ambiente\"'"; 'GeoTools-devel (E-mail)'
Subject: Factory / Container Article
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_idv28&alloc_id845&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
