My current idea would be:
>
> - to have a dedicated, OSGi specific, GeoTools module (say gt-osgi /
> org.geotools.osgi) to deal with all the black magic that will be
> required. This module depends from the OSGi APIs (and hopefully that
> is the only one)
Interesting; I had a slightly related idea (based on NetBeans NLookup). Define
what we need out
of a plugin lookup system; and allow applications to register their preferred
system with the GeoTools
class.
We do the same technique for handling loggers.
For loggers we were able to get away with a compile time dependency; and then
have GeoTools ship out of the box
to work with different logging systems if they are available. If possible I
would like to take the same approach with this
one and avoid a gt-osgi module.
> - gt-osgi registers to the BundleContext the appropriate listeners in
> order to be notified when new bundles are added/removed to/from the
> OSGi runtime
> - when a new bundle is added, gt-osgi scans it, looking for
> META-INF/service/* files and it reads/interprets them
> - this information is then passed to the "core" module where all
> services are registered.
Now one thing we will need to do (in the proposal, and in these emails) is slow
down a little bit for the geotools community. Previous proposal
were "opaque" if the reading audience did not have a background in OSGi. :-)
References:
- http://www.osgi.org/javadoc/r4v42/org/osgi/framework/BundleContext.html
- http://www.knopflerfish.org/osgi_service_tutorial.html
- http://en.wikipedia.org/wiki/OSGi
-
http://confluence.atlassian.com/display/PLUGINFRAMEWORK/OSGi,+Spring+and+the+Plugin+Framework
I was hoping we could register proper bundle service entries in the manifest;
and have the osgi lookup mechanism recognise them? It could be I am saying the
same thing as you; but with my limited knowledge of OSGi there is a gap in my
understanding :-)
I did not really want to read the META-INF/services/* files if we could avoid
it; I would rather use that information at compile time to register the
services in the generated MANIFEST.MF. This way applications could use the
GeoTools jars out of the box?
I looked for an example of how to declare a service in the MANIFEST.MF but
could only find examples of how to use an existing service.
Could you (on the proposal page or email) show an example with a GeoTools
class. Something simple like FunctionFactory would work well; and we could use
it when we write test cases for the integration step.
> The last remaining question is how this information is passed.
> An idea could be to have gt-osgi be a fragment of gt-"core" (sorry, I
> don't remember the precise name of this module).
The module is the lowest implementation on the totem pole - gt-metadata. It
contains the GeoTools class
which currently we can use to add in "FactoryIterators". This is our existing
technique to allow osgi or spring
content to register themselves with the GeoTools library - but near as I can
tell it has not been used.
> It would then simply call an appropriate static method, or any other
> mechanism...
> Something cleaner (without static calls) would be to have the "core"
> module publishing a service, either via an Activator or via a Blueprint
> configuration.
> > We should get an action group together and push for it.
> I'm in. (but I don't have much time nor resources :)
I will try and scare up some interested parties from udig-devel; my next
project is working on wps / process - but I will be
happy to review proposals and code.
Jody
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
