Re: [osgi-dev] SCR API
Because sometimes I will have no influence on what build tools are used by the developers, e.g., when using UI components developed by a third party. However, I already discussed this issue with Jürgen and additionally I think in my case your suggestion might be another sensible way, to what I've discussed with Jürgen. It took me quite some time to understand your arguments. Sometimes it's hard to grasp the concepts after having already a specific (wrong) picture of how things work in mind ;) Thanks for all the input you gave on this topic. Kind regards, Thomas Am Di., 26. Feb. 2019 um 15:59 Uhr schrieb BJ Hargrave : > Why not just do this at tool time? You could author a Bnd plugin which > scans for the Vaadin annotations in the class files and generate DS xml. > This is what we do for the DS annotations. > -- > > 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 > > > > - Original message - > From: Thomas Driessen via osgi-dev > Sent by: osgi-dev-boun...@mail.osgi.org > To: "Jürgen Albert" , OSGi Developer Mail > List > Cc: > Subject: Re: [osgi-dev] SCR API > Date: Tue, Feb 26, 2019 3:31 AM > > Hi Jürgen, > > Thanks for the additional clarification. > > Regarding creating DS component descriptions programmatically: > This could be useful for aliasing DS component annotations at runtime, > e.g., you have third party code (non-osgi) whose structure (e.g., methods > of superclasses or their own annotations or anything else) could be mapped > to (a subset of) the semantic meaning of DS annotations, then you could > write an extender which scans classes for those > annotations/methods/whatever and declares them to be components at runtime. > In my current usecase this would be @Route annotation of Vaadin Flow. > Those classes I always want to be @Component(scope=ServiceScope.PROTOTYPE, > service=HasElement.class) annotated. This could be done programmatically > via such an API. > If such an API would exist I could make existing (non-osgi) classes become > components transparently. In my opinion this would make integration of some > third-party libs easier, but I'm not that experienced, so maybe I'm > completely wrong about this ;) > > Regarding the use of View: > In Vaadin Flow there is a (non-osgi) class Instantiator which is called > (method looks roughly like this: public HasElement > getOrCreate(Class view)) whenever a View has to be created. The > Instantiator then creates an instance of the according View and returns > this instance to the Flow framework. In this usecase I need a reference to > the instance, so Flow can use it for whatever it does. > So basically it's the case where I need a reference to an osgi service > from within a non-osgi class in a synchronous way. > > Kind regards, > Thomas > > > > > > > > > Am Mo., 25. Feb. 2019 um 17:00 Uhr schrieb Jürgen Albert via osgi-dev < > osgi-dev@mail.osgi.org>: > > See my comments inline. > Am 25/02/2019 um 16:24 schrieb Thomas Driessen: > > Hi Tim, hi Jürgen, > > thanks for your detailed answers. > > Just to wrap it up so I didn't get something wrong: > > A service is an object with an interface and properties registered in the > OSGi service registry and can be seen as an OSGi primitive for bundle > interoperation. > SCR is just a DI Framework that takes OSGi's dynamism into account and > additionally registers all its components (declarative services) as > services in the OSGi service registry. > > Yes and no. The Second half of the first sentence is correct, the first > only partial: > > DS creates Components, that follow a lifecycle (activate, update, > deactivate) dependent on the availability of configurations and/or > dependencies. If a Component declares a service class (Which can be a > normal class, abstract class or Interface), then it is registered in the > service un-/registry according to its life cycle. > > > @Tim: I might have expressed myself ambiguously. I didn't want to propose > to change the DS specification which standardizes how services can be > defined declaratively and also describes the behavior of a SCR > implementation. > What I instead intended to do was to ask if it would be possible/sensible > for a SCR implementation (e.g., Apache Felix SCR) to also offer an API as > mentioned before, so that I can write an Extender that takes non-annotated > classes at runtime and tell an SCR implementation which fields/methods have > to be treated as if they were annotated with DS annotations. > > However, if that is what you understood from my last mail anyway then I > st
Re: [osgi-dev] SCR API
riginalnachricht --
Von: "Jürgen Albert via osgi-dev" <osgi-dev@mail.osgi.org>
An: osgi-dev@mail.osgi.org
Gesendet: 22.02.2019 15:34:16
Betreff: Re: [osgi-dev] SCR API
As an Addition to the things already suggested:
Taking your example I would create the MainView as follows:
@Route("")
@Component(name="MainView ", service=HasElement.class, configurationPolicy=Required, scope=PROTOTYPE)
public class MainView extends VerticalLayout{
@Reference //what ever is required here
SomeService someService;
}
You can then use the Configurator or Config Admin to create you component and even your someService target binding. Here is an example for the Configurator would need to be translated to the ConfigAdmin if you want to do this programmatically.
{
":configurator:resource-version": 1, "MainView~instance1": { "someService.target": "(fancy.service.id.prop=fizzbuzz)" }
}
Regards,
Jürgen.
Am 22/02/2019 um 10:29 schrieb Tim Ward via osgi-dev:
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#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&
Re: [osgi-dev] SCR API
Hi Jürgen, Thanks for the additional clarification. Regarding creating DS component descriptions programmatically: This could be useful for aliasing DS component annotations at runtime, e.g., you have third party code (non-osgi) whose structure (e.g., methods of superclasses or their own annotations or anything else) could be mapped to (a subset of) the semantic meaning of DS annotations, then you could write an extender which scans classes for those annotations/methods/whatever and declares them to be components at runtime. In my current usecase this would be @Route annotation of Vaadin Flow. Those classes I always want to be @Component(scope=ServiceScope.PROTOTYPE, service=HasElement.class) annotated. This could be done programmatically via such an API. If such an API would exist I could make existing (non-osgi) classes become components transparently. In my opinion this would make integration of some third-party libs easier, but I'm not that experienced, so maybe I'm completely wrong about this ;) Regarding the use of View: In Vaadin Flow there is a (non-osgi) class Instantiator which is called (method looks roughly like this: public HasElement getOrCreate(Class view)) whenever a View has to be created. The Instantiator then creates an instance of the according View and returns this instance to the Flow framework. In this usecase I need a reference to the instance, so Flow can use it for whatever it does. So basically it's the case where I need a reference to an osgi service from within a non-osgi class in a synchronous way. Kind regards, Thomas Am Mo., 25. Feb. 2019 um 17:00 Uhr schrieb Jürgen Albert via osgi-dev < osgi-dev@mail.osgi.org>: > See my comments inline. > Am 25/02/2019 um 16:24 schrieb Thomas Driessen: > > Hi Tim, hi Jürgen, > > thanks for your detailed answers. > > Just to wrap it up so I didn't get something wrong: > > A service is an object with an interface and properties registered in the > OSGi service registry and can be seen as an OSGi primitive for bundle > interoperation. > SCR is just a DI Framework that takes OSGi's dynamism into account and > additionally registers all its components (declarative services) as > services in the OSGi service registry. > > Yes and no. The Second half of the first sentence is correct, the first > only partial: > > DS creates Components, that follow a lifecycle (activate, update, > deactivate) dependent on the availability of configurations and/or > dependencies. If a Component declares a service class (Which can be a > normal class, abstract class or Interface), then it is registered in the > service un-/registry according to its life cycle. > > > @Tim: I might have expressed myself ambiguously. I didn't want to propose > to change the DS specification which standardizes how services can be > defined declaratively and also describes the behavior of a SCR > implementation. > What I instead intended to do was to ask if it would be possible/sensible > for a SCR implementation (e.g., Apache Felix SCR) to also offer an API as > mentioned before, so that I can write an Extender that takes non-annotated > classes at runtime and tell an SCR implementation which fields/methods have > to be treated as if they were annotated with DS annotations. > > However, if that is what you understood from my last mail anyway then I > still seem to be too dumb to get why such an API would be a request for a > radically different component model, e.g., why it makes such a difference > if the SCR instantiates a component because of an XML it reads or because > another entity commands it to do so. The information that is given for the > instantiation would be the same on the imperative as on the declarative way > I think. > > I can see that creating new DS component descriptions programmatically > might be useful, but I'm not quite sure, when this should be necessary. > > @Jürgen: I don't think this would work in my case, as I need a reference > to the instance created. So when I create an instance via ConfigAdmin then > I usually don't get back a reference to the instance that is created by the > ConfigAdmin, but only have a reference on the configuration I used to > create a new instance. Or am I wrong? > > What do you need to do with the View of your example? If this needs to be > used elsewhere, then this component should await the emergence on the > Service you have just configured via a reference with a target. > > > Kind regards, > Thomas > > > > > -- Originalnachricht -- > Von: "Jürgen Albert via osgi-dev" > An: osgi-dev@mail.osgi.org > Gesendet: 22.02.2019 15:34:16 > Betreff: Re: [osgi-dev] SCR API > > As an Addition to the things already suggested: > > Taking your example I would create the MainView as fo
Re: [osgi-dev] SCR API
See my comments inline.
Am 25/02/2019 um 16:24 schrieb Thomas Driessen:
Hi Tim, hi Jürgen,
thanks for your detailed answers.
Just to wrap it up so I didn't get something wrong:
A service is an object with an interface and properties registered in
the OSGi service registry and can be seen as an OSGi primitive for
bundle interoperation.
SCR is just a DI Framework that takes OSGi's dynamism into account and
additionally registers all its components (declarative services) as
services in the OSGi service registry.
Yes and no. The Second half of the first sentence is correct, the first
only partial:
DS creates Components, that follow a lifecycle (activate, update,
deactivate) dependent on the availability of configurations and/or
dependencies. If a Component declares a service class (Which can be a
normal class, abstract class or Interface), then it is registered in the
service un-/registry according to its life cycle.
@Tim: I might have expressed myself ambiguously. I didn't want to
propose to change the DS specification which standardizes how services
can be defined declaratively and also describes the behavior of a SCR
implementation.
What I instead intended to do was to ask if it would be
possible/sensible for a SCR implementation (e.g., Apache Felix SCR) to
also offer an API as mentioned before, so that I can write an Extender
that takes non-annotated classes at runtime and tell an SCR
implementation which fields/methods have to be treated as if they were
annotated with DS annotations.
However, if that is what you understood from my last mail anyway then
I still seem to be too dumb to get why such an API would be a request
for a radically different component model, e.g., why it makes such a
difference if the SCR instantiates a component because of an XML it
reads or because another entity commands it to do so. The information
that is given for the instantiation would be the same on the
imperative as on the declarative way I think.
I can see that creating new DS component descriptions programmatically
might be useful, but I'm not quite sure, when this should be necessary.
@Jürgen: I don't think this would work in my case, as I need a
reference to the instance created. So when I create an instance via
ConfigAdmin then I usually don't get back a reference to the instance
that is created by the ConfigAdmin, but only have a reference on the
configuration I used to create a new instance. Or am I wrong?
What do you need to do with the View of your example? If this needs to
be used elsewhere, then this component should await the emergence on the
Service you have just configured via a reference with a target.
Kind regards,
Thomas
-- Originalnachricht --
Von: "Jürgen Albert via osgi-dev" <mailto:osgi-dev@mail.osgi.org>>
An: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
Gesendet: 22.02.2019 15:34:16
Betreff: Re: [osgi-dev] SCR API
As an Addition to the things already suggested:
Taking your example I would create the MainView as follows:
@Route("")
@Component(name="MainView ", service=HasElement.class,
configurationPolicy=Required, scope=PROTOTYPE)
public class MainView extends VerticalLayout{
@Reference //what ever is required here
SomeService someService;
}
You can then use the Configurator or Config Admin to create you
component and even your someService target binding. Here is an
example for the Configurator would need to be translated to the
ConfigAdmin if you want to do this programmatically.
{
":configurator:resource-version": 1,
"MainView~instance1":
{
"someService.target": "(fancy.service.id.prop=fizzbuzz)"
}
}
Regards,
Jürgen.
Am 22/02/2019 um 10:29 schrieb Tim Ward via osgi-dev:
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 arou
Re: [osgi-dev] SCR API
Hi Tim, hi Jürgen,
thanks for your detailed answers.
Just to wrap it up so I didn't get something wrong:
A service is an object with an interface and properties registered in
the OSGi service registry and can be seen as an OSGi primitive for
bundle interoperation.
SCR is just a DI Framework that takes OSGi's dynamism into account and
additionally registers all its components (declarative services) as
services in the OSGi service registry.
@Tim: I might have expressed myself ambiguously. I didn't want to
propose to change the DS specification which standardizes how services
can be defined declaratively and also describes the behavior of a SCR
implementation.
What I instead intended to do was to ask if it would be
possible/sensible for a SCR implementation (e.g., Apache Felix SCR) to
also offer an API as mentioned before, so that I can write an Extender
that takes non-annotated classes at runtime and tell an SCR
implementation which fields/methods have to be treated as if they were
annotated with DS annotations.
However, if that is what you understood from my last mail anyway then I
still seem to be too dumb to get why such an API would be a request for
a radically different component model, e.g., why it makes such a
difference if the SCR instantiates a component because of an XML it
reads or because another entity commands it to do so. The information
that is given for the instantiation would be the same on the imperative
as on the declarative way I think.
@Jürgen: I don't think this would work in my case, as I need a reference
to the instance created. So when I create an instance via ConfigAdmin
then I usually don't get back a reference to the instance that is
created by the ConfigAdmin, but only have a reference on the
configuration I used to create a new instance. Or am I wrong?
Kind regards,
Thomas
-- Originalnachricht --
Von: "Jürgen Albert via osgi-dev"
An: osgi-dev@mail.osgi.org
Gesendet: 22.02.2019 15:34:16
Betreff: Re: [osgi-dev] SCR API
As an Addition to the things already suggested:
Taking your example I would create the MainView as follows:
@Route("")
@Component(name="MainView ", service=HasElement.class,
configurationPolicy=Required, scope=PROTOTYPE)
public class MainView extends VerticalLayout{
@Reference //what ever is required here
SomeService someService;
}
You can then use the Configurator or Config Admin to create you
component and even your someService target binding. Here is an example
for the Configurator would need to be translated to the ConfigAdmin if
you want to do this programmatically.
{
":configurator:resource-version": 1,
"MainView~instance1":
{
"someService.target": "(fancy.service.id.prop=fizzbuzz)"
}
}
Regards,
Jürgen.
Am 22/02/2019 um 10:29 schrieb Tim Ward via osgi-dev:
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#getService() to instantiate/register it.
This procedure can be error-prone
Re: [osgi-dev] SCR API
...). 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#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" 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" mailto:thomas.driessen...@gmail.com>>
To: "BJ Hargrave" 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" 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 dependen
Re: [osgi-dev] SCR API
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#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" 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" > <mailto:thomas.driessen...@gmail.com>>
>> To: "BJ Hargrave" 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" 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.
>>> --
>>>
>
Re: [osgi-dev] SCR API
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#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"
An: 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
- Original message -
From: "Thomas Driessen"
To: "BJ Hargrave"
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"
An: thomas.driessen...@gmail.com; osgi-dev@mail.osgi.org
Cc: 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 // o
Re: [osgi-dev] SCR API
Another option is Aries Component DSL [1]. - Ray [1] https://github.com/apache/aries/tree/trunk/component-dsl On Thu, Feb 21, 2019 at 1:21 PM BJ Hargrave via osgi-dev < osgi-dev@mail.osgi.org> wrote: > 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 > > > > - Original message - > From: Thomas Driessen via osgi-dev > Sent by: osgi-dev-boun...@mail.osgi.org > To: "OSGi Developer Mail List" > 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#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 > 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 -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
