Quoting John Grange <[EMAIL PROTECTED]>: > 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. Yeah, that would be quite nice. I think if we pull off the 'catalog' construct well, which is focused on access to the FeatureTypes, the actual data contained in the datastore, instead of just configuring the datastore, it could go a long way towards that.
Justin is working on RnD for the next generation of GeoServer, which will likely end up as a lot of these types of improvements in GeoTools. We want a tight catalog with a great api for web services to be able to grab on to, but having that catalog decoupled from web services and in GeoTools is likely the best way to go. He can probably point you at and write up some of his initial thinking and requirements. But I think the biggest one is what you say, allow people lots of different ways in to configure and access their data, a GeoTools construct that focuses on the common interface for the geospatial part. Also, there is scope for JDBC only helpers, we do have a JDBC child of DataStore, so if it makes sense to use it there then we should. best regards, Chris > > 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 > ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ ------------------------------------------------------- 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
