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. Yours, John Grange -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jody Garnett Sent: Tuesday, November 15, 2005 5:59 PM To: "P.Rizzi Ag.Mobilità Ambiente" Cc: GeoTools-devel (E-mail) Subject: [Geotools-devel] Re: P.Rizzi Ag.Mobilità Ambiente wrote: > I read the IRC of yesterday and I'd like to add a few opinion about > containers and factories. > You raise a good point, it seems we are all fond of constructor injection. Do you have any suggestions on how we can document at the interface level what "injection" is expected to function? The only advantage setter injection had in my mind was the ability to document these dependencies at the interface level. And this is a development list IMHO is assumed (or ignored) - more splat less chat. Thanks for the examples, I don't get to play with containers much. Jody > They are, obviously, plain IMHOs. > > Bye > Paolo Rizzi > > 1) Constructors should _only_ take immutable parameters. That is values that > cannot change > after the object has been constructed, hence there should be no setter for > them. > If a value has an associated setter, it means it _can_ change during the > life of the object, > so the object has to be prepared for it to change and also for it to become > null or invalid. > So if an object has some parameters it _needs_ to function but those params > have a setter, > than they shouldn't go in the constructor, but the object has to be prepared > to be in a state > of "not ready", or something like that, until all needed params are set. > > 2) IoC containers like Spring have _no_ problems working with factories. > They're able to construct > objects in whatever style: constructor injection, property injection, static > factories, etc. > So I really see no need to modify anything to prepare GeoTools objects to be > instantiated from > a container. You can even call DataStoreFinder.getDataStore(Map) from a IoC. > For example in Spring you can do something like this: > <bean id="mainDataStore" > class="org.geotools.data.DataStoreFinder" > factory-method="getDataStore"> > <constructor-arg> > <map> > <entry > key="dbtype"><value>postgis</value></entry> > <entry > key="host"><value>localhost</value></entry> > <entry key="port"> > <bean class="java.lang.Integer"> > <constructor-arg> > <value>5432</value> > </constructor-arg> > </bean> > > </entry> > <entry > key="database"><value>test</value></entry> > <entry > key="user"><value>uuuuuuu</value></entry> > <entry > key="passwd"><value>ppppppp</value></entry> > </map> > </constructor-arg> > </bean> > > And more or less the same you can do with JBoss Microcontainer: > <bean name="mainDataStore" class="java.lang.Object"> > <constructor > factoryClass="org.geotools.data.DataStoreFinder" > factoryMethod="getDataStore"> > <parameter class="java.util.Map"> > <value class="java.util.Properties"> > dbtype=postgis > host=localhost > port=5432 > database=test > user=uuuuuuu > passwd=ppppppp > </value> > </parameter> > </constructor> > </bean> > > > > > > AVVERTENZE AI SENSI DEL D. LGS. 196/2003 > Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i > file/s allegato/i, sono da considerarsi strettamente riservate. Il loro > utilizzo è consentito esclusivamente al destinatario del messaggio, per le > finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio > senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia > via e-mail e di procedere alla distruzione del messaggio stesso, > cancellandolo dal Vostro sistema; costituisce comportamento contrario ai > principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso, > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od > utilizzarlo per finalità diverse. > ------------------------------------------------------- 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
