>> Where is (are) this code located? > > I think we will have to go look ... I would open up FactoryRegister and then > look for references in the current workspace. > There is a picture in the wiki but that is down for me right now.
Are you referring to: http://docs.codehaus.org/display/GEOTDOC/How+to+Find+a+Factory ? >>> So perhaps: >>> - we could try generating additional entries for the MANIFEST.MF based on >>> the services/ directory >>> - we could process these additional entries of the MANIFEST.MF and >>> "register" these additional factories with the appropriate register I start to understand... Since I usually develop with Spring, I do not face such issues (one of the purpose of Spring is to ease the injection of interface implementations) Hopefully we will be able to avoid such a programmatic approach and keep what currently exists mostly unchanged at the Java code level. > It could be what the fragments are doing to wire things up? I am not sure I > understood what the fragments intended to do perfectly. The problem, when in OSGi, is to know which class is loading the implementation: the bundle containing the class which loads needs to "see" the class which is being loaded. In the case of interface/SPI implementations this is self-contradictory, since the bundle providing the interface to implement is also the one loading the third-party implementations: it cannot know about them in advance! Hence the conundrum... In a previous mail, I assumed that it was the "core" library (the one defining the SPI) which was loading, and that we should enrich what this library can "see" by using fragments. (fragments extend the content of a given OSGi bundle as well as its MANIFEST meta-data, with Import-Package etc.) In our example that would have meant defining a fragment with geoapi as its host bundle (for, say, SPI org.opengis.referencing.*.*) But with the GeoTools custom mechanism, it seems to me that this implementation search is performed in: org.geotools.factory.FactoryRegistry.scanForPlugins(Collection<ClassLoader>, Class<T>) , line 762 using classloaders gathered in: org.geotools.factory.FactoryRegistry.getClassLoaders(), line 692 This make thing a bit complicated, but on the other hand we have a place to look at and where we can hack. > I should be clear that registering factories by hand is a complete fallback > position that is only needed if we cannot get FactorySPI to connect on its > own. I'm currently setting up a small project using only gt-referencing and gt-epsg-hsql, and I will study in more details this custom loading mechanism. Thanks for pointing this out, this is probably what I was lacking to get started! ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
