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>
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" <thomas.driessen...@gmail.com>
To: "BJ Hargrave" <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>
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 // 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 <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: "OSGi Developer Mail List" <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
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
