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! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
