From: Martin D. <mar...@no...> - 2005-06-29 00:28:51
|
Matthias Basler a =E9crit : > 2. > Logging and showing localized messages to the user must also be consist= ent. I > want to show simple error dialogs, but an application using GeoWidgets = should > be able to use its own, maybe well-styled, dialogs. > My current approach is similar to the one above: Have a common class th= at does > this and allow overriding. (After what I've already learned this is bet= ter than > using strict interfaces.) > Any ideas for this? For the localization part, the usual way is to use=20 java.util.ResourceBundle. Is it the kind of thing you are looking for?=20 Note: ResourceBundle is used for localized string in the vast majority=20 of cases, but it can actually be used for any kind of localized=20 resources, including localized icons for example. Martin. |
From: Chris H. <ch...@op...> - 2005-07-29 10:58:05
|
> So I gather there two problems (?) > 1) dissattisfaction with the geotools geotiff code > 2) Changing of the interfaces > Why not use Gdal for the geotiff (a.o.) part. We build access from > Javato Gdal using JNI based on the geo-api interface. Could read, > write and create gridcoverages from java in there with reasonable > performance. We did not finish it entirely but that has more to do > with the changes that will happen in the geo-api interfaces with > respect to ISO 19123 (we did > not want to spent more time on implementing things that will change > anyhow). > In GeoTiff (internals) itself we have experience, coded our own > conversions from geotiff to (at that moment) our internal ILWIS > format.So the knowledge about Geotiff is ok I guess. > With respect to interfaces I think we could contribute, many years > experience on both the practical use of gridcoverages and the software > side of it (and defining our interfaces for it). So whom should I > contact there to talk with. Hey Martin, I'm bumping this to geotools, as most all the raster guys live there. You just missed a great IRC meeting on this stuff, which is unfortunate, would have been good to have you there. But basically people are just getting started on it. You can read up on the wiki: http://docs.codehaus.org/display/GEOTOOLS/Coverage+Support+Plans has the plans, would be great if you could introduce there and what you're interests are. Notes from the initial meetings are here: http://docs.codehaus.org/display/GEOTOOLS/Kickoff+meeting+notes and the full transcript is here: http://docs.codehaus.org/pages/viewpage.action?pageId=29019 Martin D is looking for volunteers to help out on the GeoAPI interfaces, and it would be just great if you guys could get involved in that. And yes, java based access to gdal is definitely on everyone's minds. Currently sounds like it may come by way of OSSIM first, but more direct access should be nice. It sounds like there's enough interest in having native java support for geotiff, for the cross platform aspect of it. But yes, Simone and Alessio, Martin D, and Bryce are leading the charge on coverage plans, would be great if you could join them. best regards, Chris ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ |
From: V. K. M. R. <vk...@cd...> - 2005-08-11 10:56:22
|
Dear Sir, I like to unsubscribe to this mailing list temporarily. I like to subscribe in another mail account. Kindly unsubscribe me from this forum. Thanking you regards raja |
From: <db...@op...> - 2005-09-12 16:02:26
|
>Dave, theoretically the jdbc datastores shouldn't have to do anything. >Oracle (and others I believe) inherits it's filter capabilities from >the generic SQLEncoder, so if you added it there, then it should add it >in the children. Yes - as per my original message: >For other DB-based datastores, all you should have to do is add: > capabils.addType(AbstractFilter.LIKE); >To the filter capabilities of your DB-based datastore. > >TEST TEST TEST I'm sure this will work for Oracle and DB2. It's currently working in Postgresql. I have no idea what MySQL's "like" implementation is like (no pun intended). dave ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ |
From: <pao...@am...> - 2005-11-15 10:34:23
|
I read the IRC of yesterday and I'd like to add a few opinion about containers and factories. 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=3D"mainDataStore" class=3D"org.geotools.data.DataStoreFinder" factory-method=3D"getDataStore"> <constructor-arg> <map> <entry key=3D"dbtype"><value>postgis</value></entry> <entry key=3D"host"><value>localhost</value></entry> <entry key=3D"port"> <bean class=3D"java.lang.Integer"> <constructor-arg> <value>5432</value> </constructor-arg> </bean> </entry> <entry key=3D"database"><value>test</value></entry> <entry key=3D"user"><value>uuuuuuu</value></entry> <entry key=3D"passwd"><value>ppppppp</value></entry> </map> </constructor-arg> =09 </bean> And more or less the same you can do with JBoss Microcontainer: <bean name=3D"mainDataStore" class=3D"java.lang.Object"> <constructor factoryClass=3D"org.geotools.data.DataStoreFinder" factoryMethod=3D"getDataStore"> <parameter class=3D"java.util.Map"> <value class=3D"java.util.Properties"> dbtype=3Dpostgis host=3Dlocalhost port=3D5432 database=3Dtest user=3Duuuuuuu passwd=3Dppppppp </value> </parameter> </constructor> </bean> AVVERTENZE AI SENSI DEL D. LGS. 196/2003 =20 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 =E8 consentito esclusivamente al destinatario del messaggio, = per le finalit=E0 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=E0 diverse. |
From: Justin D. <jde...@un...> - 2005-11-15 17:47:14
|
Hi Paolo, 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. > 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> > Having objects injectible is only half the battle. And as you say with most containers you can provide enough metadata to be able to so do. However, the problem is that many of the factories dont allow dependencies to be set via a setter or a constructor. The dependency is in essence hardcoded inside the class. Or the dependency is pulled out of a hashmap based on some key. It may be tricky to get spring to inject a dependency in this manner, although probably possible. Also, not all containers support the addition of xml to describe the objects living in the container. PicoContainer for instance doesn't really have this and is one of the more popular containers (its close relative nanocontainer does but that is besides the point). I think what we are shooting for is to allow clients to use any container they wish, and because the geotools factories are "good citizens", everything should gel. Justin > > > > > 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=click > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org |
From: Jody G. <jga...@re...> - 2005-11-15 17:58:38
|
P.Rizzi Ag.Mobilit=E0 Ambiente wrote: > I read the IRC of yesterday and I'd like to add a few opinion about > containers and factories. > =20 You raise a good point, it seems we are all fond of constructor=20 injection. Do you have any suggestions on how we can document at the=20 interface level what "injection" is expected to function? The only=20 advantage setter injection had in my mind was the ability to document=20 these dependencies at the interface level. And this is a development list IMHO is assumed (or ignored) - more splat=20 less chat. Thanks for the examples, I don't get to play with containers=20 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 th= e > life of the object, > so the object has to be prepared for it to change and also for it to be= come > null or invalid. > So if an object has some parameters it _needs_ to function but those pa= rams > have a setter, > than they shouldn't go in the constructor, but the object has to be pre= pared > 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, s= tatic > 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=3D"mainDataStore" > class=3D"org.geotools.data.DataStoreFinder" > factory-method=3D"getDataStore"> > <constructor-arg> > <map> > <entry > key=3D"dbtype"><value>postgis</value></entry> > <entry > key=3D"host"><value>localhost</value></entry> > <entry key=3D"port"> > <bean class=3D"java.lang.Integer"> > <constructor-arg> > <value>5432</value> > </constructor-arg> > </bean> > > </entry> > <entry > key=3D"database"><value>test</value></entry> > <entry > key=3D"user"><value>uuuuuuu</value></entry> > <entry > key=3D"passwd"><value>ppppppp</value></entry> > </map> > </constructor-arg> =09 > </bean> > > And more or less the same you can do with JBoss Microcontainer: > <bean name=3D"mainDataStore" class=3D"java.lang.Object"> > <constructor > factoryClass=3D"org.geotools.data.DataStoreFinder" > factoryMethod=3D"getDataStore"> > <parameter class=3D"java.util.Map"> > <value class=3D"java.util.Properties"> > dbtype=3Dpostgis > host=3Dlocalhost > port=3D5432 > database=3Dtest > user=3Duuuuuuu > passwd=3Dppppppp > </value> > </parameter> > </constructor> > </bean> > > > > > > AVVERTENZE AI SENSI DEL D. LGS. 196/2003 =20 > 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 =E8 consentito esclusivamente al destinatario del messaggio, p= er le > finalit=E0 indicate nel messaggio stesso. Qualora riceveste questo mess= aggio > senza esserne il destinatario, Vi preghiamo cortesemente di darcene not= izia > via e-mail e di procedere alla distruzione del messaggio stesso, > cancellandolo dal Vostro sistema; costituisce comportamento contrario a= i > 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=E0 diverse. > =20 |
From: John G. <jo...@th...> - 2005-11-17 08:10:17
|
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? =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 = jdbc datasource code (mainly for mysql/oracle) and this seems the best way forward to me. Yours, John Grange -----Original Message----- From: geo...@li... [mailto:geo...@li...] On Behalf Of Jody Garnett Sent: Tuesday, November 15, 2005 5:59 PM To: "P.Rizzi Ag.Mobilit=E0 Ambiente" Cc: GeoTools-devel (E-mail) Subject: [Geotools-devel] Re: P.Rizzi Ag.Mobilit=E0 Ambiente wrote: > I read the IRC of yesterday and I'd like to add a few opinion about > containers and factories. > =20 You raise a good point, it seems we are all fond of constructor=20 injection. Do you have any suggestions on how we can document at the=20 interface level what "injection" is expected to function? The only=20 advantage setter injection had in my mind was the ability to document=20 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=20 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=3D"mainDataStore" > class=3D"org.geotools.data.DataStoreFinder" > factory-method=3D"getDataStore"> > <constructor-arg> > <map> > <entry > key=3D"dbtype"><value>postgis</value></entry> > <entry > key=3D"host"><value>localhost</value></entry> > <entry key=3D"port"> > <bean class=3D"java.lang.Integer"> > <constructor-arg> > <value>5432</value> > </constructor-arg> > </bean> > > </entry> > <entry > key=3D"database"><value>test</value></entry> > <entry > key=3D"user"><value>uuuuuuu</value></entry> > <entry > key=3D"passwd"><value>ppppppp</value></entry> > </map> > </constructor-arg> =09 > </bean> > > And more or less the same you can do with JBoss Microcontainer: > <bean name=3D"mainDataStore" class=3D"java.lang.Object"> > <constructor > factoryClass=3D"org.geotools.data.DataStoreFinder" > factoryMethod=3D"getDataStore"> > <parameter class=3D"java.util.Map"> > <value class=3D"java.util.Properties"> > dbtype=3Dpostgis > host=3Dlocalhost > port=3D5432 > database=3Dtest > user=3Duuuuuuu > passwd=3Dppppppp > </value> > </parameter> > </constructor> > </bean> > > > > > > AVVERTENZE AI SENSI DEL D. LGS. 196/2003 =20 > 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 =E8 consentito esclusivamente al destinatario del messaggio, = per le > finalit=E0 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=E0 diverse. > =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 |
From: Jody G. <jga...@re...> - 2005-11-17 00:52:32
|
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 |
From: John G. <jo...@th...> - 2005-11-17 20:03:19
|
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: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: > 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? =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 jdbc > datasource code (mainly for mysql/oracle) and this seems the best way > forward to me. > =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 = on their own is well known. I have not scene a good idea (or patch) on=20 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=20 DataStoreFactorySpi.PARAM class, it was a quick hack to build a=20 GeoServer user interface. The fact that most applications duck its use=20 (and the databases datastores have taken to having magic dbtype=20 parameters) kind of point to its failure. Cheers, Jody |
From: Jody G. <jga...@re...> - 2005-11-17 22:33:14
|
John Grange wrote: > The use of dbcp would then allow exactly the same constructor to be use= d 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 transpare= ntly. > > Having looked at the code, there would be a reasonable amount of legwor= k > 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=20 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/result= sets > - 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=20 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=20 any thoughts on the "point" of that article (aka how we should allow for=20 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 suppl= ied >> datasource (poolable if necessary), if that is provided instead. Agre= ed, >> you'd need to know what database you were connecting to, but that woul= d be >> possible from the underlying driver, or, if necessary, by adding a hin= t. >> >> If I've missed the point, please tell me, but I have looked through th= e >> =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 datasource= s=20 > on their own is well known. I have not scene a good idea (or patch) on=20 > how this should be done? > > With respect to apache dbcp - can you tell me more? GeoTools use outsid= e=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=20 > (and the databases datastores have taken to having magic dbtype=20 > parameters) kind of point to its failure. > > Cheers, > Jody > > > > > > =20 |
From: John G. <jo...@th...> - 2005-11-18 08:04:18
|
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 |
From: John G. <jo...@th...> - 2005-11-18 08:14:41
|
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: geo...@li... [mailto:geo...@li...] On Behalf Of John = Grange Sent: Friday, November 18, 2005 8:04 AM To: 'Jody Garnett' Cc: '"''\\P .Rizzi Ag. Mobilit=E0 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: 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 ------------------------------------------------------- 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 |
From: Chris H. <ch...@op...> - 2005-11-18 11:34:50
|
Quoting John Grange <jo...@th...>: > 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: geo...@li... > [mailto:geo...@li...] On Behalf Of John > Grange > Sent: Friday, November 18, 2005 8:04 AM > To: 'Jody Garnett' > Cc: '"''\\P .Rizzi Ag. Mobilit=E0 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: 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. > > > 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:jga...@re...] > > 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: > > > >> 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_id=16845&op=3Dick > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > 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_id=16845&op=3Dick > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > 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_id=16845&op=3Dclick > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ |
From: <db...@op...> - 2006-04-25 15:45:32
|
Martin Desruisseaux wrote: > gt/module/render/src/org/geotools/renderer/lite/LiteShape2.java:[62,16] cannot find symbol > symbol : class LineIterator2 > location: class org.geotools.renderer.lite.LiteShape2 > Okay, its there now. I had awful problem moving the changes from 2.2.x to trunk. dave ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ |
From: Martin D. <mar...@no...> - 2006-04-25 21:51:26
|
db...@op... a =E9crit : > Okay, its there now. I had awful problem moving the changes from 2.2.x > to trunk. Thanks, it seems to compile file now. I noticed the addition of the following dependency: import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; Is it appropriate if I had the following comment? // TODO: replace by java.util.concurrent.ConcurrentHashMap // when we will be allowed to target J2SE 1.5. Martin. |
From: <db...@op...> - 2006-04-27 14:49:36
|
Alessio Fabiani wrote: >Hi all, >this would be nice for me: > >http://timeanddate.com/worldclock/fixedtime.html?day=1&month=5&year=2006&hour=22&min=0&sec=0&p1=37 > This sounds like a good time for me (monday 1:00pm). I'll be back in vancouver. If its easier for martin to attend, we could move it forward or back by 1/2 (or a whole) hour. dave ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ |
From: <db...@li...> - 2006-04-26 14:04:50
|
Martin Desruisseaux wrote: > db...@op... a =E9crit : > >> Okay, its there now. I had awful problem moving the changes from 2.2.x >> to trunk. > > > Thanks, it seems to compile file now. > > I noticed the addition of the following dependency: > > import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; > > Is it appropriate if I had the following comment? > > // TODO: replace by java.util.concurrent.ConcurrentHashMap > // when we will be allowed to target J2SE 1.5. I dont know anything about this -- where is it used? dave ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ |
From: Martin D. <mar...@no...> - 2006-04-26 22:41:51
|
db...@li... a =E9crit : >> I noticed the addition of the following dependency: >> >> import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; >=20 >=20 > I dont know anything about this -- where is it used? In module/main/src/org/geotools/data/Diff.java This introduces a dependency of main toward an ESRI library (namely jsde_= concurrent-9.0.jar). Is it=20 really okay to have such a dependency? Martin. |
From: <ale...@ge...> - 2008-02-20 15:28:13
|
Hi all, the GeoTools Raster Symbolizer support proposal page is ready. Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support We should now open a Jira to track progresses, start voting and finish the remaining tasks. Regards, Alessio. ------------------------------------------------------- Eng. Alessio Fabiani Vice-President /CTO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 349 8227000 http://www.geo-solutions.it ------------------------------------------------------- |
From: Jesse E. <je...@re...> - 2008-02-21 20:04:49
|
I've been looking at this proposal and am pretty excited. I'd like to do a shout out to all the Geotoolers that can vote to take a look at this. I'm waiting on the proposal to do some funded work. Thanks, Jesse Le 20-Feb-08 à 7:28 AM, ale...@ge... a écrit : > Hi all, > > the GeoTools Raster Symbolizer support proposal page is > ready. > Please take a look and review at > http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support > We should now open a Jira to track progresses, start voting > and finish the remaining tasks. > > Regards, > Alessio. > > ------------------------------------------------------- > Eng. Alessio Fabiani > Vice-President /CTO GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 349 8227000 > > > http://www.geo-solutions.it > > ------------------------------------------------------- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |
From: Gabriel R. <gr...@op...> - 2008-02-21 20:29:36
|
May be a dumb question, but I wonder if a proposal were needed at all? Developers guide says proposals are for API changes [1]. The proposal[2] says it adds API: "The structure of the proposed API allows a developer to chain nodes as desired." and no API change is needed: "It is worth to point out that the proposed solution does not face GeoTools API change". :/ Gabriel. [1]http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal [2]http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support On Thursday 21 February 2008 09:04:47 pm Jesse Eichar wrote: > I've been looking at this proposal and am pretty excited. > > I'd like to do a shout out to all the Geotoolers that can vote to take > a look at this. I'm waiting on the proposal to do some funded work. > > Thanks, > > Jesse > > Le 20-Feb-08 à 7:28 AM, ale...@ge... a écrit : > > Hi all, > > > > the GeoTools Raster Symbolizer support proposal page is > > ready. > > Please take a look and review at > > http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support > > We should now open a Jira to track progresses, start voting > > and finish the remaining tasks. > > > > Regards, > > Alessio. > > > > ------------------------------------------------------- > > Eng. Alessio Fabiani > > Vice-President /CTO GeoSolutions S.A.S. > > Via Carignoni 51 > > 55041 Camaiore (LU) > > Italy > > > > phone: +39 0584983027 > > fax: +39 0584983027 > > mob: +39 349 8227000 > > > > > > http://www.geo-solutions.it > > > > ------------------------------------------------------- > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Geotools-devel mailing list > > Geo...@li... > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4045,47bdd96d147051961014482! |
From: Jesse E. <je...@re...> - 2008-02-21 20:43:21
|
Its all a mystery to me. Can we get a confirmation about this? Jesse Le 21-Feb-08 à 12:29 PM, Gabriel Roldán a écrit : > May be a dumb question, but I wonder if a proposal were needed at > all? > Developers guide says proposals are for API changes [1]. > The proposal[2] says it adds API: "The structure of the proposed API > allows a > developer to chain nodes as desired." > and no API change is needed: "It is worth to point out that the > proposed > solution does not face GeoTools API change". > > :/ > > Gabriel. > > [1]http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal > [2]http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support > > > On Thursday 21 February 2008 09:04:47 pm Jesse Eichar wrote: >> I've been looking at this proposal and am pretty excited. >> >> I'd like to do a shout out to all the Geotoolers that can vote to >> take >> a look at this. I'm waiting on the proposal to do some funded work. >> >> Thanks, >> >> Jesse >> >> Le 20-Feb-08 à 7:28 AM, ale...@ge... a écrit : >>> Hi all, >>> >>> the GeoTools Raster Symbolizer support proposal page is >>> ready. >>> Please take a look and review at >>> http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support >>> We should now open a Jira to track progresses, start voting >>> and finish the remaining tasks. >>> >>> Regards, >>> Alessio. >>> >>> ------------------------------------------------------- >>> Eng. Alessio Fabiani >>> Vice-President /CTO GeoSolutions S.A.S. >>> Via Carignoni 51 >>> 55041 Camaiore (LU) >>> Italy >>> >>> phone: +39 0584983027 >>> fax: +39 0584983027 >>> mob: +39 349 8227000 >>> >>> >>> http://www.geo-solutions.it >>> >>> ------------------------------------------------------- >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Geotools-devel mailing list >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> !DSPAM:4045,47bdd96d147051961014482! > > |
From: Martin D. <mar...@ge...> - 2008-02-22 15:17:23
|
ale...@ge... a écrit : > Please take a look and review at > http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support I had a quick look to the interfaces at: http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/ I noticed that those interfaces are pretty close to the API that I created in org.geotools.coverage, except that they are interfaces rather than classes, and: * CategoryList has been made public, while it was package-privated in my implementation. Which CategoryList's service are required that can not be assured by SampleDimension (extending the later if needed)? And does CategoryUtilities really needs to be public? * Category (and CategoryList) has been splitted in some subinterfaces: TransformCategory, VizualizationCategory. Each of them contains a single method. Why this extra-level of complexity? Why not just keep the extra-method in a single Category class, like I did, and just returns null if there is no transform? Is it for type-safety? Furthermore TransformCategory.getTransform() is confusing. Is it a "sample to geophysics" transform? If not, which kind of transform is it, for what purpose? And why TransformCategory extends MathTransform1D in addition of having a getTransform() method? Is it the same transform? If so why this duplication? Why Category.getRange() has been renamed getInputRange() in your flavor, given that a category is not a transformer with input and output (the "sample to geophysics" transform is, but not the category itself). Martin |
From: Simone G. <sim...@gm...> - 2008-02-22 16:26:54
|
Thanks for taking some time to review martin... On Fri, Feb 22, 2008 at 4:17 PM, Martin Desruisseaux <mar...@ge...> wrote: > ale...@ge... a écrit : > > Please take a look and review at > > http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support > > I had a quick look to the interfaces at: > > http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/ > > I noticed that those interfaces are pretty close to the API that I created in > org.geotools.coverage, except that they are interfaces rather than classes, and: > Yes, they are. I do not remember if Alessio mentioned that in the proposal, but if yuo remember when we talked at FOSS4g back in october I mentioned that I had a few weeks to revisit the category and geophysics thing and this is what I have been able to do using that time. As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. > * CategoryList has been made public, while it was package-privated in my > implementation. Which CategoryList's service are required that can not > be assured by SampleDimension (extending the later if needed)? I was not 100% sure about this, so for the moment I just tried to underline basic behavior using interfaces. The point for this is that you can create new categorylists reusing the provided implementation and feed an agnostic sampledimension which would simply rely on the interface and add behavior as/if needed. > And does > CategoryUtilities really needs to be public? It could be in the package scope, but then people extending this code in the future would have to stick with this package naming in order to reuse these methods. I would have to check again those methods to give a final answer. > > * Category (and CategoryList) has been splitted in some subinterfaces: > TransformCategory, VizualizationCategory. Each of them contains a single > method. Why this extra-level of complexity? Why not just keep the extra-method > in a single Category class, like I did, and just returns null if there is no > transform? I am not a fan of null values even though I have used them a lot in the past :-). I tried to make these classes easy to understand for people. If I just need a simple category I do not want to specify a transformation and a color. > Is it for type-safety? That was another reason. > Furthermore TransformCategory.getTransform() > is confusing. Is it a "sample to geophysics" transform? > If not, which kind of > transform is it, for what purpose? And why TransformCategory extends > MathTransform1D in addition of having a getTransform() method? Is it the same > transform? If so why this duplication? I quickly checked the code and i agree with you that the getTransform method should not be part of the interface because it is an implementation detail. I am going to move it to the DefaultTransformCategory implementation. Let me point out that the transform is a generic transform, so it can be a sample to geophysics as it could be a custom transformation to implement custom contrast enhancement on rgb images (like for example a piecewise that actually works, not like th JAI one, or it could be a logarihmic one, etc. etc.). > Why Category.getRange() has been > renamed getInputRange() in your flavor, given that a category is not a > transformer with input and output (the "sample to geophysics" transform > is, but not the category itself). > You are right, going to apply this change. I am going to share more thoughts during the weekend on this since I think it could be a good starting point to improve the geophysics non gephysics duality. Simone. > > > Martin > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it ------------------------------------------------------- |