Hello Dmitry, Some points inline below.
On Thu, Jun 11, 2009 at 10:06 PM, Dmitry Skavish<[email protected]> wrote: > Hello all, > ... > The extension point mechanism Eclipse uses is NOT based on OSGi It IS based on OSGi. It is an example of the extender pattern which is common in OSGi. But it is not based on Services. > If I want to use say declarative services (or simply services) as extension > points mechanism it seems I have only one key: service interface, that is > when I declare my service I just announce to the framework that I have a > service, I don't specify which extension point this service is intended to > extend. Correct, this an advantage of services -- they do not need advance knowledge of which bundles will consume them. > I guess I can add some parameter to the service (i.e. extension point name) > and have the framework code filter out services by this parameter when > requested. It could work, but I don't really like this approach because > these parameters are somewhat soft constraints and not enforced by OSGi in > any way. It sounds like you want to ensure that services can only be consumed by certain bundles, like Eclipse Extensions. Why? > Another reason I don't like it is because I suspect that the > service (extension) will be loaded when a component requesting this service > is loaded, but I want it to be loaded only when I specifically requested > this service. If you use Declarative Services then the implementation object for the service will be loaded lazily, i.e. only when a consumer actually attempts to use it. Because of this, in my opinion, DS has most of the advantages of Eclipse's Extensions, and none of the disadvantages (and the disadvantages of Eclipse Extensions are numerous and significant). > Anybody has any thoughts/ideas on that? Are we reinventing a wheel? > Thanks! > > -- > Dmitry Skavish > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
