Jody,
Completely agree with concentrating on geospatial stuff here and using best
of breed for non core functionality.
Yes, DBCP is for JDBC only, sorry it doesn't solve wider problem.
I would be quite happy to look at some more general connection/resource
management methods, but could really do with a little guidance on the
requirement first. Am I correct in assuming that it is desirable that one
calls something like (new DataStoreFactory()).getDataSource("schema name");
??? Could this be done with pluggable DataStoreFactories (I like spring,
I'll set mine up that way - Jo Bloggs likes JMX, so he'll use that or
picocontainer etc....) You could even use multiple ones..
Regards,
John Grange
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jody
Garnett
Sent: Thursday, November 17, 2005 10:33 PM
To: John Grange
Cc: "''\\P.Rizzi Ag.Mobilità Ambiente\\''"; 'GeoTools-devel (E-mail)'
Subject: [Geotools-devel] Re: Factory / Container Article
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=ick
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
-------------------------------------------------------
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
