> Are you referring to:
> http://docs.codehaus.org/display/GEOTDOC/How+to+Find+a+Factory ?
Not even that nice :-)
A picture of how that "factory registery" stuff is used by the referencing
module to wire itself up.
- http://docs.codehaus.org/display/GEOTDOC/Referencing+Developers+Guide
- http://docs.codehaus.org/display/GEOTDOC/1+Referencing+Configuration+and+Tool
The useful test will be the command line provided:
java org.geotools.referencing.CRS -dependencies -encoding=437
It can be used to verify we have the factories wired up correctly.
> 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)
And that would be fine; if every project used Spring. As it is our a library
like ours tried to go with the bare bones java way of doing things - and then
got punished by OSGi. Sigh!
> 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.
Also if the above approach is not good; we can change it to meet our needs.
>> 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!
You may need a few more dependences to get going (gt-metadata is used to
describe the referencing systems!) But yes that is the core value proposition
right there :-)
I dug up a bunch of other stuff today; including a reference to a JBoss
resolution of the problem - it amounted to a custom classloader that allowed
access to the services directory so ServiceLocator could continue to work in an
OSGi environment.
-
http://planet.jboss.org/view/post.seam?post=serviceloader_and_how_it_relates_to_osgi
My final fallback idea is to make a GeoTools.createRegistery( Class ) method;
which we can configure before hand to use FactorySPI by default; or something
OSGi specific in an OSGi environment. We were forced to do something similar
for logging and the technique can work.
Bleck - thanks for your help on this one (it makes me tired).
Jody
------------------------------------------------------------------------------
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
