Also, IMHO, DataStores all require some amount of configuration to point to the actual data - it would be useful to allow developers to use whatever method they find appropriate to set these configurations - programmatically, injection, config files, whatever - it changes for different projects and even different datastores in a particular project.
John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Grange Sent: Friday, November 18, 2005 8:04 AM To: 'Jody Garnett' Cc: '"''\\P .Rizzi Ag. Mobilità Ambiente\\''"'; 'GeoTools-devel (E-mail)' Subject: RE: [Geotools-devel] Re: Factory / Container Article 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=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
