OSGi services as extension point mechanism

[Dmitry Skavish <sk...@gmail.com>]

Hello all,
We are developing a desktop application based on Felix and thinking about
the best approach to support plugins and extension points. My goal at the
moment is to try to use only OSGi configuration for this, that is without
any additional plugin/extensions descriptors. Another important goal is to
load lazily, i.e. extensions are loaded only when they are requested, not
when bundle which uses them is loaded.

If you look at Eclipse they have plugins as OSGi bundles. A plugin could
define its own extension points and provide extensions to the other
extension points.
The extension point mechanism Eclipse uses is NOT based on OSGi, that is
they have a plugin descriptor in plugin.xml, eclipse framework code reads
those descriptors at startup and keeps all the wiring between extension
points and their extensions ready in memory.
When an extension point requests all its extensions the framework will
traverse the wiring and will load and activate the required plugins (if they
have not been activated yet) and then it will create the extensions.

Basically to create an extension in Eclipse one needs to provide an
implementation (key1) and specify which extension point it extends (key2).
Two keys here.

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.

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. 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.

Anybody has any thoughts/ideas on that? Are we reinventing a wheel?
Thanks!

-- 
Dmitry Skavish

Re: OSGi services as extension point mechanism

[Dmitry Skavish <sk...@gmail.com>]

Thanks Christopher. I am also thinking along these lines.

On Thu, Jun 11, 2009 at 10:08 PM, Christopher Armstrong <
carmstrong@fastmail.com.au> wrote:

>
> On 12/06/2009, at 10:59 AM, Dmitry Skavish wrote:
>
>> yes of course I can do it this way. I was just curious if there is a
>> "better", more structured way in DS or OSGi itself. something similar to
>> those extension points, like specifying a "target" for my services
>>
>>
> I think you should take a look at the "target" filtering mechanism in DS (I
> believe this is what Richard was referring to). It lets you filter based on
> service properties in your component definition. IIRC, if you were to a
> define a component reference that behaved like an extension point you might
> do something like this:
>
> <component ....>
>        <reference id="ref1" interface="org.something.else.MyInterface"
> target="(&(extensionpoint=org.something.else.featurepoint1))"/>
> </component>
>
> In this way, your component would be "wired" to the service that has the
> "extensionpoint" property equal to "org.something.else.featurepoint1". Of
> course, the property name I chose here is completely arbitrary, you can use
> whatever you like. You could also filter on service.pid properties I guess,
> which are supposed to be unique.
>
> The added advantage of that method is that if you use Config Admin to
> configure your DS components, you can make the "target" filter property
> specified above configurable in the CM configuration.
>
> Cheers
> Chris
>
> carmstrong@fastmail.com.au
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Dmitry Skavish

Re: OSGi services as extension point mechanism

[Christopher Armstrong <ca...@fastmail.com.au>]

On 12/06/2009, at 10:59 AM, Dmitry Skavish wrote:
> yes of course I can do it this way. I was just curious if there is a
> "better", more structured way in DS or OSGi itself. something  
> similar to
> those extension points, like specifying a "target" for my services
>

I think you should take a look at the "target" filtering mechanism in  
DS (I believe this is what Richard was referring to). It lets you  
filter based on service properties in your component definition. IIRC,  
if you were to a define a component reference that behaved like an  
extension point you might do something like this:

<component ....>
	<reference id="ref1" interface="org.something.else.MyInterface"  
target="(&(extensionpoint=org.something.else.featurepoint1))"/>
</component>

In this way, your component would be "wired" to the service that has  
the "extensionpoint" property equal to  
"org.something.else.featurepoint1". Of course, the property name I  
chose here is completely arbitrary, you can use whatever you like. You  
could also filter on service.pid properties I guess, which are  
supposed to be unique.

The added advantage of that method is that if you use Config Admin to  
configure your DS components, you can make the "target" filter  
property specified above configurable in the CM configuration.

Cheers
Chris

carmstrong@fastmail.com.au






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: OSGi services as extension point mechanism

["Richard S. Hall" <he...@ungoverned.org>]

On 6/12/09 11:53 AM, Dmitry Skavish wrote:
> it's the same thing and IMHO it's worse than specifying it all in a special
> file, like plugin.xml or something. because when you tell users they need to
> create a plugin.xml file which has such and such structure it's less prone
> to errors than specifying service parameters. basically there is no dtd for
> service parameters, but you can have dtd for your own plugin.xml files.
>    

True, but you get some of this sort of structure if you are using DS or 
iPOJO or whatever.

-> richard

> On Fri, Jun 12, 2009 at 9:34 AM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>    
>> On 06/11/2009 08:59 PM, Dmitry Skavish wrote:
>>
>>      
>>>>> Either way, you need some bits specified by someone somewhere to
>>>>>
>>>>>
>>>>>            
>>>> differentiate who should be getting what. I am not sure why using service
>>>> properties for such a purpose would be any more or less artificial than
>>>> any
>>>> other approach.
>>>>
>>>> In your example here, extension A could say, "I will only consume Command
>>>> services with service proprty 'foo'," while B would do something similar
>>>> for
>>>> service property 'bar'. Either way, someone has to declare this info if
>>>> you
>>>> want to filter on it.
>>>>
>>>>
>>>>          
>>> yes of course I can do it this way. I was just curious if there is a
>>> "better", more structured way in DS or OSGi itself. something similar to
>>> those extension points, like specifying a "target" for my services
>>>
>>>
>>>        
>> I don't see why specifying a "target" is any more or less structured than
>> using service properties to specify a target. Seems like it is just a
>> different name for the same thing.
>>
>> ->  richard
>>
>>
>>      
>
>
>    

Re: OSGi services as extension point mechanism

[Dmitry Skavish <sk...@gmail.com>]

it's the same thing and IMHO it's worse than specifying it all in a special
file, like plugin.xml or something. because when you tell users they need to
create a plugin.xml file which has such and such structure it's less prone
to errors than specifying service parameters. basically there is no dtd for
service parameters, but you can have dtd for your own plugin.xml files.

On Fri, Jun 12, 2009 at 9:34 AM, Richard S. Hall <he...@ungoverned.org>wrote:

> On 06/11/2009 08:59 PM, Dmitry Skavish wrote:
>
>>
>>>
>>>> Either way, you need some bits specified by someone somewhere to
>>>>
>>>>
>>> differentiate who should be getting what. I am not sure why using service
>>> properties for such a purpose would be any more or less artificial than
>>> any
>>> other approach.
>>>
>>> In your example here, extension A could say, "I will only consume Command
>>> services with service proprty 'foo'," while B would do something similar
>>> for
>>> service property 'bar'. Either way, someone has to declare this info if
>>> you
>>> want to filter on it.
>>>
>>>
>>
>>
>> yes of course I can do it this way. I was just curious if there is a
>> "better", more structured way in DS or OSGi itself. something similar to
>> those extension points, like specifying a "target" for my services
>>
>>
>
> I don't see why specifying a "target" is any more or less structured than
> using service properties to specify a target. Seems like it is just a
> different name for the same thing.
>
> -> richard
>
>


-- 
Dmitry Skavish

Re: OSGi services as extension point mechanism

["Richard S. Hall" <he...@ungoverned.org>]

On 06/11/2009 08:59 PM, Dmitry Skavish wrote:
>>      
>>> Either way, you need some bits specified by someone somewhere to
>>>        
>> differentiate who should be getting what. I am not sure why using service
>> properties for such a purpose would be any more or less artificial than any
>> other approach.
>>
>> In your example here, extension A could say, "I will only consume Command
>> services with service proprty 'foo'," while B would do something similar for
>> service property 'bar'. Either way, someone has to declare this info if you
>> want to filter on it.
>>      
>
>
> yes of course I can do it this way. I was just curious if there is a
> "better", more structured way in DS or OSGi itself. something similar to
> those extension points, like specifying a "target" for my services
>    

I don't see why specifying a "target" is any more or less structured 
than using service properties to specify a target. Seems like it is just 
a different name for the same thing.

-> richard

Re: OSGi services as extension point mechanism

[Dmitry Skavish <sk...@gmail.com>]

>
>
>> Either way, you need some bits specified by someone somewhere to
> differentiate who should be getting what. I am not sure why using service
> properties for such a purpose would be any more or less artificial than any
> other approach.
>
> In your example here, extension A could say, "I will only consume Command
> services with service proprty 'foo'," while B would do something similar for
> service property 'bar'. Either way, someone has to declare this info if you
> want to filter on it.


yes of course I can do it this way. I was just curious if there is a
"better", more structured way in DS or OSGi itself. something similar to
those extension points, like specifying a "target" for my services

-- 
Dmitry Skavish

Re: OSGi services as extension point mechanism

["Richard S. Hall" <he...@ungoverned.org>]

On 06/11/2009 06:10 PM, Dmitry Skavish wrote:
> It's an advantage if you need a service, but extension point is not 
> exactly
> a service. For example you have an interface Command and there are two
> different extension points (A and B) which could be extended by those
> commands. I am creating a plugin to extend A, I don't want to extend B
> because my commands are for A only. And there is some other plugin which
> extends B using its own commands. The problem here is that my plugin which
> extend A and this other plugin which extend B they both use this very
> convenient interface Command. So they cannot just declare that they provide
> services Command because A and B will try to consume commands from both of
> them.
>
> Of course I can create unique interfaces for A and B and extend them through
> those unique interfaces, but in many cases it's artificial. Basically I am
> forced to create those unique interfaces because interface is the only key
> here.
>    

Either way, you need some bits specified by someone somewhere to 
differentiate who should be getting what. I am not sure why using 
service properties for such a purpose would be any more or less 
artificial than any other approach.

In your example here, extension A could say, "I will only consume 
Command services with service proprty 'foo'," while B would do something 
similar for service property 'bar'. Either way, someone has to declare 
this info if you want to filter on it.

-> richard


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: OSGi services as extension point mechanism

[Dmitry Skavish <sk...@gmail.com>]

Thanks Neil! I see the issues now. Basically all the problems in that
particular eclipse implementation, not in the idea of extension points.
BTW which would you go with DS or iPOJO to implement plugins?

On Fri, Jun 12, 2009 at 5:27 PM, Neil Bartlett <nj...@gmail.com> wrote:

> Hi Dmitry,
>
> Since you ask, here are the top three issues I have with Eclipse
> Extensions:
>
> 1) Bundles offering either extensions or extension points must be
> singletons, i.e. you can only have one version installed, and there is
> no support for checking the compatibility of an extension with the API
> of the extension point by version.
>
> 2) Lack of control. Extensions are read from any bundle that has a
> plugin.xml and is at least RESOLVED. But we have little control over
> the RESOLVED state, and in particular there is no way to request that
> a bundle be "unresolved" except by fully uninstalling it. DS on the
> other hand works with ACTIVE state, which means we have explicit
> control of the visibility of bundles through activating and
> deactivating them.
>
> 3) Bolted-on dynamics. The Extension Registry APIs were designed
> before Eclipse used OSGi as its underlying module system, and thus
> before it was possible to dynamically install and uninstall bundles at
> runtime. They have since been extended with dynamic capabilities but
> the extensions are difficult to use, and in practice very few Eclipse
> plug-in developers pay any attention to dynamics. This is why Eclipse
> *still* insists that you restart after installing new plug-ins, four
> years after adopting OSGi.
>
> Since DS offers the same laziness benefits as extensions, the one
> remaining advantage of extensions versus DS is their support for
> richer and more structured metadata, in the form of an XML tree versus
> the name/value pairs used with services/DS.
>
> Regards,
> Neil
>
> On Thu, Jun 11, 2009 at 11:10 PM, Dmitry Skavish<sk...@gmail.com> wrote:
> > Neil,
> >
> >> > 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.
> >
> >
> > Could you please elaborate a bit how it is based on OSGi? I mean I
> > understand that Eclipse is based on OSGi itself and the plugins are OSGi
> > bundles, I mean how Eclipse extension points mechanism is based on OSGi?
> If
> > you have some link that would be great!
> >
> >
> >> > 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.
> >
> >
> > It's an advantage if you need a service, but extension point is not
> exactly
> > a service. For example you have an interface Command and there are two
> > different extension points (A and B) which could be extended by those
> > commands. I am creating a plugin to extend A, I don't want to extend B
> > because my commands are for A only. And there is some other plugin which
> > extends B using its own commands. The problem here is that my plugin
> which
> > extend A and this other plugin which extend B they both use this very
> > convenient interface Command. So they cannot just declare that they
> provide
> > services Command because A and B will try to consume commands from both
> of
> > them.
> >
> > Of course I can create unique interfaces for A and B and extend them
> through
> > those unique interfaces, but in many cases it's artificial. Basically I
> am
> > forced to create those unique interfaces because interface is the only
> key
> > here.
> >
> >
> >> > 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?
> >
> >
> > because those are not services. they are extensions. a service provides
> some
> > service and does not know about how it is used. an extension in many
> cases
> > extends a very specific functionality and very often aware what it
> extends
> > and how it is used.
> >
> >> 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).
> >
> >
> > What are numerous and significant disadvantages of Eclipse Extensions? I
> > guess I can think of some disadvantages, but I would not call them
> > significant :)
> >
> > Thanks!
> >
> > --
> > Dmitry Skavish
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Dmitry Skavish

Re: OSGi services as extension point mechanism

[Neil Bartlett <nj...@gmail.com>]

Hi Dmitry,

Since you ask, here are the top three issues I have with Eclipse Extensions:

1) Bundles offering either extensions or extension points must be
singletons, i.e. you can only have one version installed, and there is
no support for checking the compatibility of an extension with the API
of the extension point by version.

2) Lack of control. Extensions are read from any bundle that has a
plugin.xml and is at least RESOLVED. But we have little control over
the RESOLVED state, and in particular there is no way to request that
a bundle be "unresolved" except by fully uninstalling it. DS on the
other hand works with ACTIVE state, which means we have explicit
control of the visibility of bundles through activating and
deactivating them.

3) Bolted-on dynamics. The Extension Registry APIs were designed
before Eclipse used OSGi as its underlying module system, and thus
before it was possible to dynamically install and uninstall bundles at
runtime. They have since been extended with dynamic capabilities but
the extensions are difficult to use, and in practice very few Eclipse
plug-in developers pay any attention to dynamics. This is why Eclipse
*still* insists that you restart after installing new plug-ins, four
years after adopting OSGi.

Since DS offers the same laziness benefits as extensions, the one
remaining advantage of extensions versus DS is their support for
richer and more structured metadata, in the form of an XML tree versus
the name/value pairs used with services/DS.

Regards,
Neil

On Thu, Jun 11, 2009 at 11:10 PM, Dmitry Skavish<sk...@gmail.com> wrote:
> Neil,
>
>> > 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.
>
>
> Could you please elaborate a bit how it is based on OSGi? I mean I
> understand that Eclipse is based on OSGi itself and the plugins are OSGi
> bundles, I mean how Eclipse extension points mechanism is based on OSGi? If
> you have some link that would be great!
>
>
>> > 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.
>
>
> It's an advantage if you need a service, but extension point is not exactly
> a service. For example you have an interface Command and there are two
> different extension points (A and B) which could be extended by those
> commands. I am creating a plugin to extend A, I don't want to extend B
> because my commands are for A only. And there is some other plugin which
> extends B using its own commands. The problem here is that my plugin which
> extend A and this other plugin which extend B they both use this very
> convenient interface Command. So they cannot just declare that they provide
> services Command because A and B will try to consume commands from both of
> them.
>
> Of course I can create unique interfaces for A and B and extend them through
> those unique interfaces, but in many cases it's artificial. Basically I am
> forced to create those unique interfaces because interface is the only key
> here.
>
>
>> > 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?
>
>
> because those are not services. they are extensions. a service provides some
> service and does not know about how it is used. an extension in many cases
> extends a very specific functionality and very often aware what it extends
> and how it is used.
>
>> 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).
>
>
> What are numerous and significant disadvantages of Eclipse Extensions? I
> guess I can think of some disadvantages, but I would not call them
> significant :)
>
> Thanks!
>
> --
> Dmitry Skavish
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: OSGi services as extension point mechanism

[Dmitry Skavish <sk...@gmail.com>]

Neil,

> > 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.


Could you please elaborate a bit how it is based on OSGi? I mean I
understand that Eclipse is based on OSGi itself and the plugins are OSGi
bundles, I mean how Eclipse extension points mechanism is based on OSGi? If
you have some link that would be great!


> > 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.


It's an advantage if you need a service, but extension point is not exactly
a service. For example you have an interface Command and there are two
different extension points (A and B) which could be extended by those
commands. I am creating a plugin to extend A, I don't want to extend B
because my commands are for A only. And there is some other plugin which
extends B using its own commands. The problem here is that my plugin which
extend A and this other plugin which extend B they both use this very
convenient interface Command. So they cannot just declare that they provide
services Command because A and B will try to consume commands from both of
them.

Of course I can create unique interfaces for A and B and extend them through
those unique interfaces, but in many cases it's artificial. Basically I am
forced to create those unique interfaces because interface is the only key
here.


> > 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?


because those are not services. they are extensions. a service provides some
service and does not know about how it is used. an extension in many cases
extends a very specific functionality and very often aware what it extends
and how it is used.

> 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).


What are numerous and significant disadvantages of Eclipse Extensions? I
guess I can think of some disadvantages, but I would not call them
significant :)

Thanks!

-- 
Dmitry Skavish

Re: OSGi services as extension point mechanism

[Neil Bartlett <nj...@gmail.com>]

Hello Dmitry,

Some points inline below.

On Thu, Jun 11, 2009 at 10:06 PM, Dmitry Skavish<sk...@gmail.com> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org