I've been developing with OSGi for so long that sometimes I forget that not everyone in the Java world can take advantage of all the benefits offerred by it. Recently I have been contemplating the approaches to framework extensibility when you cannot depend on OSGi. Note that I am not looking for other solutions to modularity. I am looking for an extension contribution system that is not specific to OSGi. We'd like to support Sapphire in all Java UI contexts and extensibility for implementing new UI parts, renderers, etc. is key.
Before I start re-inventing the wheel... Have others faced similar requirements? If so, what was the approach that you chose?
Posts
4 comments:
It might help to go into the requirements in a little more detail.
However, you should probably look at some kind of dependency injection system. If you write everything as POJOs then you can use DS or Blueprint inside OSGi and something else (e.g. Spring, Guice?) when running in other contexts.
I am looking for something like the Eclipse extensions registry where I can setup an extension point and have multiple parties contribute extensions.
All examples I've seen of dependency injections systems are centered around 1 implementation for a particular service being available (injected) in a given context. Is it possible to use dependency injection in contexts where you expect multiple concurrent contributions?
Why not just use the extension registry? It does not require OSGi. There is an OSGi strategy that is used to figure out how to load classes in an OSGi environment but the strategy is pluggable.
Jeff,
I didn't figure the extension registry was that flexible. That would be ideal if I can figure out how to set it up. Could you help point me in the right direction? Such as, what interface do I implement to create a new strategy. I imagine that there is a bit more to it than just loading classes as the OSGi strategy of locating the extensions in plugin.xml files in bundle roots wouldn't work either.
Post a Comment