Thanks Justin, I also do not want to deprecate factory finder (except in how Martin already suggested we deprecate StyleFactoryFinder, FilterFactoryFinder and replace them with a single FactoryFinder that does them all for use by users).
Here are my points of reference: #1 Discovery - look up available Factory implementations via SPI, Spring, Equinox #2 DEVELOPER - need to allow for user control (injection), second concern is determining a suitable default (possibly consulting hints) #3 USER - need to be able to create an instance of a GeoAPI interface (or GeoTools interface) I would like us to consider these three uses as different APIs. Cheers, Jody > Hi all, > > I think there is some confusion about peoples intentions here. I would > like to clarify. I do *not* want to deprecate or change anything to do > with factory finder. It works fine as the geotools plugin system. > > What I would like to change is the way some code uses it. Looking up > factories is equivalent to processing an extension point. But some code > uses it to just look up a single extension. This begs the question why > have an extension point if you only want one. The answer could be "to > set a library wide default". Well what happens when you accidentley plug > in another extension, you might just lose your default. > > The constructor and setter stuff can be used in *conjunction* with > factory finder, is not a replacement for it. That is why I like it so > much, it is very not intrusive. It is a very simple notion which can to > lead to ( and this is just my opinion ) code that is better designed and > easier to test. > > So I don't think there is any action that needs to take place. Martin > can go ahead and do his refactoring to factory finder, etc... Jody, and > other datastore implementors, set up your datastore to work with > injection falling back to factory finder for defaults. > > One thing we did talk about at foss with martin was that factory finder > the way it is now falls down in some environments, such as eclipse ( > udig ). So the ability to add additional iterators for looking up > factories I believe is needed. Martin agreed that this would be a good idea? > > Hopefully that clears some things up. > > -Justin > > > Jody Garnett wrote: > >> It seems we are going around in circles here a bit ... I am sorry I do >> not have time to participate more fully right now. I agree that both >> approaches can live together (we produced a sample code example at >> FOSS4G that I emailed the list), and hope to take a more active roll >> when I get near code again. >> >> We seem to have slightly needs (or users) in mind resulting in a bit of >> confusion. Lets agree on terms first: >> - developers - developers contributing to (or working on) a geotools >> plugin like a datastore >> - users - someone using the tool kit in an application >> >> #1 Functionality and Consistency >> >> USERS >> I would like to see users be able to set up a Datastore on a per query >> basis to do what they want to. For any factory used by geotools I want >> them to be able to supply their own. >> The test: producing plain old java objects (implementing Feature >> interface) from a shapefile datastore >> >> DEVELOPERS >> I would like to ensure they support constructor (and against everyones >> wishes setter) injection for every factory they make use of. Since >> factories "cascade" this is not usually a large amount of work, I just >> want the code to be honest about what it does. As an example many Style >> transformations also produce expressions, as such they need to take an >> FilterFactory - but during the 2.2.x QA checks I found that they mostly >> cheated the system. >> >> This is what is needed to make the library function, and be consistent. >> Until we have this I cannot really start on step number two.... >> >> #2 Usability >> >> The next question is how to make this easy to use for users, and easy to >> develop for developers? >> >> USERS >> Setting up some global switches so users can change some basic defaults >> (use of a feature factory by default, or default use of a specific epsg >> authority). This lets us handle the default problem fairly well, and >> will work fine. >> For injection (if the user actually does that, which geoserver and udig >> are wanting to) they can use a third party solution like Pico Container >> or Spring. Being able to use a third party solution, and behave in the >> way users expect, is why go with injection. >> >> DEVELOPERS >> Being able to look up a default implementation that meets their needs >> (the CRS factory enforcing longitude/latitude order is a fine example). >> >> So we have several tools on the table: >> - Factory / Interface split - we need to ensure GeoTools always does this >> - Factory Injection >> - Hints >> - Ability to look up Factory instances - we need to break out the lookup >> system for SPI / Spring / Equinox >> - FactoryFinder >> >> So here is my question - how do we define the relationship between Map >> hints, looking up defaults, and factory finder. Do we have two different >> APIs? One for Users and one for Developers? This is the section where I >> think our communication is getting lost, ... >> >> So let me try a list (I was hoping for Justin's help on this): >> - I would like to ensure that we move the factory finder interfaces we >> have now out into an extension (I think justin already started?) >> - And that our developers do not make use of them at all >> - I would like to make sure our factories work with injection >> >> We then have a trade off: >> >> One big FactoryFinder for "defaults": >> - visible to client code giving them one stop shoping for any geotools >> construct >> - with new FactoryFinder( Map hints ).create( Class factory ) >> - would process the extension >> - this really just looks like a poor mans container which is why I am >> worried we are reinventing a computer science wheel rather then focusing >> on geospatial stuff >> - has the advantage that Factory instances are still straightforward to >> develop (either with hints or injection) >> >> Factory supplied "defaults": >> - process is not user visible, they get geotools constructs via "new" or >> via their container >> - the factory knows what it is setting up and can be sure to find the >> appropriate content (can make use of user supplied defaults if needed) >> - developer is responsible >> - user can use injection to override and take control >> >> Later, >> Jody >> >>> Jody Garnett a écrit : >>> >>>> - deprecate *all* factory finder methods and place them in an ext/ so >>>> that our code is forced to use injection >>>> >>> Deprecating factory finders was not my plan... Style and Filter >>> factory finders are not implemented as they should be. But referencing >>> factory finder (for example) should fit the needs - it already cover >>> non-trivial hints cases. >>> >>> "FactoryFinder.getFooFactory(hints)" or "new FooFactory(hints)" can be >>> see as kinds of constructor injection. Factory dependencies are >>> specified as a map of hints instead of explicit argument, but in both >>> cases they are processed at construction time. >>> >>> Cons: >>> * Supported hints are not visible from an API point of view. >>> User needs to read the javadoc. >>> >>> * Hints are not supported by picocontainer and similar. >>> >>> Pros: >>> * User specifies all the hints he care about (and only the hints he >>> care >>> about), no matter if it is supported by the Factory or not. The >>> factory >>> will pickup the relevant hints from the map. For example the user >>> may set >>> a COVERAGE_PROCESSOR hint. CRSFactory will ignores this hint, but >>> other >>> factories may use it. User can just specify all his need once >>> without the >>> need to adapt his request on a factory-by-factory basis. >>> >>> * A Map is extensible, while constructor arguments are not >>> extensible without >>> a compatibility break. If a new dependency is introduced in future >>> factory >>> version, adding an argument to the constructor requires at least a >>> deprecate >>> - remove release cycle and requires updating every methods that >>> invoke this >>> constructor. Using a Map, we can process with no API change. >>> >>> * Hints provide some flexibility not available with constructor or >>> method >>> injection. Again, how can we said "any CRS factory enforcing >>> (longitude, >>> latitude) axis order" with constructor/method injection? >>> >>> >>> Actually both approachs: >>> >>> - Constructor(Hints) >>> - Constructor(Factory1, Factory2...) >>> >>> can probably live together in most cases. So doing one approach do not >>> exclude the other. >>> >>> Martin >>> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> !DSPAM:1004,452d6172125321702038478! >> >> > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
