On Sun, Feb 27, 2011 at 2:48 PM, Jody Garnett <[email protected]>wrote:
> In reviewing docs for the user guide I have looked over the various factory > finders currently in play and found some duplication. > > CommonFactoryFinder has a register with FileDataStore > (which FileDataStoreFinder uses which is nice). However it would be better > to do the same thing as DataStoreFinder, and go through the single registery > of all DataAccessFactory and do determine what is available without > dupication? > > I have to admit I never use file data stores so I don't have a good grip on the matter. But generally speaking +1 for removing duplication provided we're not introducing bugs or significantly slowing down store lookups. > The second inconsistency is between CommonDataStoreFactory holding a > registery of FeatureLockFactory. FeatureLockFactory is another case like > DefaultQuery where we have over engineered things. There is only one > implementation of FeatureLock, and we have yet to have an application need > to configure GeoTools to make use of its own locking mechanism. This idea > was put in place for J2EE apps so they could use their current session to > control GeoTools. > > So what is a good thing to do here? > - Use DataStoreFinder as a guide for fixing up FileDataStoreFinder, common > factory finder can make use of the same fix. > - deprecate out the FeatureLockFactory, and turn FeatureLock into a class. > This probably should of been done as part of DefaultQuery since they are > part of the same solution; it is just I use them so little that I did not > think of it. > Neither did I. However we're already in RC2 so it seems to me is too late for API changes. It can be done on trunk however? > > Ideally I would like to see these changes made before 2.7.0 (so the > CommonFactoryFinder methods can be correctly deprecated). > > I also note we had a discussion about making 2.7.0 recently; and did not do > our traditional check for deprecation that can now be removed etc. Do we > need to set up a work part on this one? > > +1 on removing deprecated stuff. Again, worried it might be too late in the game, deprecated api are likely to be used by both GeoServer and uDig, they should have been removed before getting into RC state. Again, I don't have a good grip on this one either but it seems to me we're so close to a final release that we should avoid making any change that goes much beyond bug fixing and tuning. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -------------------------------------------------------
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
