Hi Thomas,
I’m not sure that there is a naming issue here, but possibly a different
misunderstanding.
> From my understanding there are two kinds of "services”:
This is not really accurate. There is only one kind of service in OSGi, and
it’s an object which has been registered with the service registry. It is
always registered by a call to context.registerService(...). It doesn’t matter
whether this action is taken directly by your bundle, or on your bundle’s
behalf by an extender bundle. The fact that all services are the same is
important because this is how bundles interoperate. Your bundles can use any
mechanisms that they like internally and they can still interact with other
bundles that may be using the same, or different, internal details.
> 2) "Fancy services" aka DS managed by a SCR. I specify those declaratively
> via annotations, they have a lifecycle and can have references to other
> services/components via annotations like @Activate/@Deactivate (Lifecycle)
> and @Reference. Those I will call components for the rest of this mail.
There are a large number of different component models around in Java. These
provide lifecycle management and injection for your objects. In the case of
OSGi aware component models they also provide support for registering the
object instance as a service (using context.registerService()).
For Declarative Services the programming and configuration model is declarative
- you describe how you want your component’s lifecycle to look using XML (or
annotations to generate the XML). This XML is packaged into your bundle and
used by a Service Component Runtime (an implementation of the DS specification)
at runtime to find and manage your component.
> Components on the other side have references and lifecycle methods, but in
> order to instantiate them programmatically I have to force a developer to
> annotate the class with @Component(scope=ServiceScope.PROTOTYPE) and then use
> ServiceObjects<type>#getService() to instantiate/register it.
>
> This procedure can be error-prone, e.g., when I assume that scope is always
> PROTOTYPE but the developer forgot to set it to this value. This problem came
> up during my discussion with Vaadin for a Flow-OSGi integration.
This is really a decision that needs to be made by the component developer. It
doesn’t always make sense for a component to be PROTOTYPE scoped, and they need
to be aware that there may be multiple instances created
> In this context it would be great if there were a possibility to
> programmatically create components (not services) where I can tell SCR what
> fields/methods have to be treated as @Reference or lifecycle methods and let
> SCR do the heavy lifting.
This is not what SCR does. SCR is a declarative component model, not a
programmatic one. There is no “DS builder API” for creating components. If you
want a builder API for creating a component then you need to use a component
framework that works in this way. As Ray pointed out in a previous mail chain
there is the Apache Aries Component DSL. You could also use Apache Felix
Dependency Manager.
> Would such an API make sense? Or would it even be possible?
> I think in general this would be very useful in order to create OSGi
> integrations for third-party libs that need to interact with DS in OSGi.
This isn’t really a question of third party libraries interacting with DS, it’s
a request for a radically different component model with some DS-like
capabilities. There are already framework implementations in the world that
provide what you’re looking for, just not using DS.
Best Regards,
Tim
> On 21 Feb 2019, at 18:07, Thomas Driessen via osgi-dev
> <osgi-dev@mail.osgi.org> wrote:
>
> Hi BJ,
>
> sorry for being imprecise. I sometimes get confused regarding the proper
> naming in OSGi. I will try to clear things up by defining what my
> understanding is about services:
>
> From my understanding there are two kinds of "services":
> 1) "Old school Services": I usually register those programmatically via
> context.registerService(...). Those services are just POJOs with a little bit
> metadata, i.e., properties, and a well-defined interface. Those I will call
> services for the rest of this mail.
> 2) "Fancy services" aka DS managed by a SCR. I specify those declaratively
> via annotations, they have a lifecycle and can have references to other
> services/components via annotations like @Activate/@Deactivate (Lifecycle)
> and @Reference. Those I will call components for the rest of this mail.
>
> The difference between both (as far as I understand it) is that services can
> be instantiated and registered programmatically, but are not managed by SCR
> and therefore have no references and lifecycle methods.
>
> Components on the other side have references and lifecycle methods, but in
> order to instantiate them programmatically I have to force a developer to
> annotate the class with @Component(scope=ServiceScope.PROTOTYPE) and then use
> ServiceObjects<type>#getService() to instantiate/register it.
>
> This procedure can be error-prone, e.g., when I assume that scope is always
> PROTOTYPE but the developer forgot to set it to this value. This problem came
> up during my discussion with Vaadin for a Flow-OSGi integration.
>
> In this context it would be great if there were a possibility to
> programmatically create components (not services) where I can tell SCR what
> fields/methods have to be treated as @Reference or lifecycle methods and let
> SCR do the heavy lifting.
> In Flow this would enable me to easily instantiate all classes that are
> annotated with Vaadin's @Route annotation and register them as components
> with scope PROTOTYPE and also to encorporate stuff like references and
> lifecycle methods with my own annotations.
>
> So for a class that looks like this:
>
> @Route("")
> public class MainView extends VerticalLayout{
> @OSGiRef
> SomeService someService;
> }
>
> I could call some imaginary API like this:
>
> scr.createCmp(MainView.class)
> .setScope(PROTOTYPE)
> .setService(HasElement.class)
> .addReference(someService);
>
> and SCR would create this comopnent at runtime, inject the service
> someService and then return this instance so that a third-party lib can
> interact with it, while SCR still controls the lifecycle and coming/going of
> referenced services/components.
>
> Would such an API make sense? Or would it even be possible?
>
> I think in general this would be very useful in order to create OSGi
> integrations for third-party libs that need to interact with DS in OSGi.
>
>
> I hope this clarified my former email.
>
> Kind regards,
> Thomas
>
>
>
> ------ Originalnachricht ------
> Von: "BJ Hargrave" <hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>>
> An: thomas.driessen...@gmail.com <mailto:thomas.driessen...@gmail.com>
> Gesendet: 21.02.2019 14:48:18
> Betreff: Re: Re[2]: [osgi-dev] SCR API
>
>> I am not what you mean by a "possiblity to register services in a way to get
>> references injected at runtime". Those are the different sides of a service:
>> The provider of the service and the consumers of a service. Each side can
>> use different models to interact. One can register with the service API and
>> the other can consume with DS, CDI, etc. So service consumers do not need to
>> care how the service provider is implemented. So you can used DS to
>> @Reference services which have been registered by any method.
>>
>> Because everything is a service in the framework's service registry, each
>> side of the service interaction can be written using different models.
>>
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>
>>
>>
>> ----- Original message -----
>> From: "Thomas Driessen" <thomas.driessen...@gmail.com
>> <mailto:thomas.driessen...@gmail.com>>
>> To: "BJ Hargrave" <hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>>
>> Cc:
>> Subject: Re[2]: [osgi-dev] SCR API
>> Date: Thu, Feb 21, 2019 7:37 AM
>>
>> Hi BJ,
>>
>> is there a possiblity to register services in a way to get references
>> injected at runtime, i.e., something like the @Reference funtionality but
>> for services registered programmatically?
>>
>> I think this would be a great enhancement for third-partyy libraries who
>> want to plug in into OSGi's DI framework.
>>
>> Kind regards,
>> Thomas
>>
>> ------ Originalnachricht ------
>> Von: "BJ Hargrave" <hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>>
>> An: thomas.driessen...@gmail.com <mailto:thomas.driessen...@gmail.com>;
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> Cc: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> Gesendet: 21.02.2019 13:21:06
>> Betreff: Re: [osgi-dev] SCR API
>>
>>> There is not plan for Declarative Services to have an API for imperatively
>>> creating components/services. The whole point of Declarative Services is
>>> the declarative nature of it. You can always use the service APIs of the
>>> framework to create services. Or something like felix dependency manager.
>>> --
>>>
>>> BJ Hargrave
>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>>> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>
>>>
>>>
>>> ----- Original message -----
>>> From: Thomas Driessen via osgi-dev <osgi-dev@mail.osgi.org
>>> <mailto:osgi-dev@mail.osgi.org>>
>>> Sent by: osgi-dev-boun...@mail.osgi.org
>>> <mailto:osgi-dev-boun...@mail.osgi.org>
>>> To: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org
>>> <mailto:osgi-dev@mail.osgi.org>>
>>> Cc:
>>> Subject: [osgi-dev] SCR API
>>> Date: Thu, Feb 21, 2019 7:16 AM
>>>
>>> Hi,
>>>
>>> currently I'm debating on a Vaadin FLow issue how to best create components
>>> in OSGi programmatically. The answer of my last question on this mailing
>>> list regarding this topic was to use scope=PROTOTYPE and then
>>> ServiceObjects<Type>#getService(). This is a solution far better than the
>>> approach I used before but still has some flaws, resulting in the following
>>> question:
>>>
>>> Is there (or is it planned to create) an API for SCR to programmatically
>>> create components at runtime?
>>>
>>> I think of something like the Apache Felix DependencyManager where I can
>>> register services but not components (with refrences and stuff).
>>>
>>> What I think of would be something like this:
>>>
>>> scr.createCmp(Class class)
>>> .setActivateMethod(...)
>>> .setReferenceField(...)
>>> .etc...
>>>
>>> Kind regards,
>>> Thomas
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>
>>
>>
>>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
