When I'm using the database datastore, I have to use the map parameters which I set up using an adapter class to allow it to be setup up using setter methods.
Regarding apache dbcp, it is part of the apache commons project - details can be found at http://jakarta.apache.org/commons/dbcp/index.html You perhaps want to look at the BasicDataSource initially - this gives you connection pooling out of the box - create your BasicDataSource, set the setters for username/password, etc, etc, and then call getConnection() whenever you need one - no need to worry about writing pooling code. - Oh, and BTW, it implements javax.sql.DataSource. I use this extensively along with spring to inject datasources into my unit tests (on deployment, a different spring config injects the JNDI datasource (the interface is the same one, though). If somebody creates a database datastore with the map parameters, a BasicDataSource could be created behind the scenes. The JDBC datastore should then only use methods belonging to javax.sql.DataStore to manage it's connections. If you also add a constructor taking a javax.sql.DataStore, then the database datastore would use this directly (without making it's own). I suppose, you could decide which database datastore to use based on the underlying jdbc driver being used in your datasource providing the possibility of getting rid of the magic dbtype parameter. I'm afraid I don't know enough about the SPI architecture/intentions to provide more help here... - Perhaps a static datasource registration method somewhere? Dunno... 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. <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> 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
