I got a couple of ideas; but the first one is "low stress"... 1. Reduce FatorySPI use to *just* service discovery ... so an AuthorityFactoryServiceProvider 2. Have create methods on AuthorityFactoryServiceProvider to create the existing AuthorityFactory instances 3. The AuthorityFactoryServiceProvider can cache and recycle instances if needed
This is to simplify the problem so we can explore the various plug-in models with out tearing our hair out (I don't think either of us have much left?). Martin Desruisseaux wrote: > Hello Jody > > Jody Garnett a écrit : >> Martin are you still interested in breaking apart the "service >> discovery" use of factory spi form the management of factory instances? > It is a good time to revisit the factory system since I'm in cleaning > stage right now. I'm sorry that it caused you so much pain with > Eclipse classloading. I don't think it was you; I think it is just us pushing the envelope of what Java is capable of years before really good systems were set up. > However I don't know yet what a replacement would look like. Do you > have any idea? I have several thoughts we can explore... In the "library should not force a technological direction on a client application" corner: - We may be able to trade some of the "auto wiring" we currently enjoy; for some configuration steps similar to GeoTools.init - a bold decision but one that may be worthwhile - There are a bazillion containers that can handle the wiring (and even the auto wiring) given nice clean factories with their dependencies advertised - this may just allow automation of the configuration step mentioned above In the "library needs a plug-in system" corner: - OSGi is the obvious one; there are two competing JSRs in the pipe right now and they are already working on compromise. Whatever solution emerges will need to deal with a growing body of OSGi based applications. - Spring has gotten *very very* good at being used inside a library and not inflicting unwanted interfaces and so on into client code (it was one of their funded technical directions for Spring 2.5). Those two may amount to the same thing: - Spring has seen the writing on the wall and is supporting OSGi at some level - Spring is good about isolating your code from subsystems like OSGi (or whatever that othe JSR is) - Spring is just another one of those bazillion containers that handle wiring In anycase let us get 2.5.x safely branched and we can work on this together. Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
