RE: [Geotools-devel] Re: Factory / Container Article

[John G. <jo...@th...>]

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: geo...@li...
[mailto:geo...@li...] On Behalf Of Jody
Garnett
Sent: Thursday, November 17, 2005 10:33 PM
To: John Grange
Cc: "''\\P.Rizzi Ag.Mobilit=E0 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.
>  =20
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=20
projects). What I was interested in was your impressions/enthusiasm for=20
DBCP. If I can be blunt, is this technique specific to Databases and=20
JDBC Connections? We need to use a facility that allows us to manage a=20
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>
>  =20
Lol - it does look like Justin made a good decision with Spring. I will=20
try and catch up. I am tempted to test geotools against Spring and=20
PicoContainer just to keep
the toolkit "honest". As for SPI it is simply a technique for finding=20
plugins, my understanding is NanoContainer may offer a replacement?=20
Eclipse Equinox also looks like a more mature OSGi based replacement=20
(also as it is involved with the JCP it may end up being Java the=20
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:jga...@re...]=20
> Sent: Thursday, November 17, 2005 12:52 AM
> To: John Grange
> Cc: "'\"P.Rizzi Ag.Mobilit=E0 Ambiente\"'"; 'GeoTools-devel (E-mail)'
> Subject: Factory / Container Article
>
> John Grange wrote:
>  =20
>> 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
>>    =20
> set
>  =20
>> 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? =20
>>
>> 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
>>    =20
> jdbc
>  =20
>> datasource code (mainly for mysql/oracle) and this seems the best way
>> forward to me.
>>  =20
>>    =20
> You have not missed the point, simply discovered a different one. My=20
> Article was all set up for a conversation about how we should support=20
> multiple versions (of Style, SLD, etc...), but your point is a good =
one=20
> for improving the use of Factories in GeoTools.
>
> The ability for geotools to make use of "Application" resources is=20
> always a focus. The fact that J2EE  applications manage JDBC =
datasources=20
> 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=20
> of J2EE is important as well ;-) We are not attached to the=20
> DataStoreFactorySpi.PARAM class, it was a quick hack to build a=20
> GeoServer user interface. The fact that most applications duck its use =

> (and the databases datastores have taken to having magic dbtype=20
> parameters) kind of point to its failure.
>
> Cheers,
> Jody
>
>
>
>
>
>  =20



-------------------------------------------------------
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_id=16845&op=3Dick
_______________________________________________
Geotools-devel mailing list
Geo...@li...
https://lists.sourceforge.net/lists/listinfo/geotools-devel