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] Mave archetype repository not reachable
Thanks! Am Di., 26. Feb. 2019 um 15:30 Uhr schrieb BJ Hargrave : > See > https://github.com/osgi/osgi.enroute/commit/32c54eb654a86e4cd79a80b2e7c5dd659962c44a > -- > > 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] Mave archetype repository not reachable > Date: Tue, Feb 26, 2019 9:24 AM > > Hi, > > currently the repository for enroute maven archetypes, i.e., > https://oss.sonatype.org/content/groups/osgi > is returning 404. > > I assume this is not intended. > > 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
[osgi-dev] Mave archetype repository not reachable
Hi, currently the repository for enroute maven archetypes, i.e., https://oss.sonatype.org/content/groups/osgi is returning 404. I assume this is not intended. Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
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
, 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
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#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 ca
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] ComponentServiceObjects vs ServiceObjects
Hi Tim, as always this is super informative :) Thanks. Should I then use ComponentServiceObjects too when I'm not in the context of a @Component annotated class? In my last sketch for the OSGi integration in Vaadin Flow I used ServiceObjects instead. Would ComponentServiceObjects be better here? This is the class I'm talking about: https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/v2/OSGiInstantiatorV2.java Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 19.02.2019 14:02:21 Betreff: Re: [osgi-dev] ComponentServiceObjects vs ServiceObjects As I get it ComponentServiceObjects are just for use within Components and are obtained vie @Reference? Yes - you should *always* use ComponentServiceObjects if you want to get on-demand instances of a prototype scope service inside your DS component. But why are not ServiceObjects used for this? ServiceObjects is a low-level API. You are responsible for ensuring that *every* call to get is balanced by a call to unget. This gives your component a big tidy-up job in its deactivate method (and other places as necessary). If you use ComponentServiceObjects then DS is able to track all of the instances that you’ve created and make sure that they all get released automatically if your component is deactivated or the reference is rebound (for example with a greedy dynamic mandatory reference). ComponentServiceObjects is therefore much safer to use than ServiceObjects as you don’t need to be worried about the mess that could be ongoing when your component stops. Note that if your component can create a potentially unlimited number of service instances from the ComponentServiceObjects you must still make sure to release instances that you create. If you fail to do this you will run out of memory. I hope this helps. Tim On 19 Feb 2019, at 13:53, Thomas Driessen via osgi-dev wrote: Hi, can someone explain to me the difference between ComponentServiceObjects and ServiceObjects and when to use which? As I get it ComponentServiceObjects are just for use within Components and are obtained vie @Reference? But why are not ServiceObjects used for this? 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
[osgi-dev] ComponentServiceObjects vs ServiceObjects
Hi, can someone explain to me the difference between ComponentServiceObjects and ServiceObjects and when to use which? As I get it ComponentServiceObjects are just for use within Components and are obtained vie @Reference? But why are not ServiceObjects used for this? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Clarification on reference behavior regarding field injection
Hi Tim, you're right. Now the build succeeds :/ Don't know what went wrong during the last build. The error message seems to have been introduced by bnd 4.2? This is a great aid :) In 4.1. the build suceeded also when I'm did not declare the field volatile. Thanks for your patience. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" Cc: "Neil Bartlett" ; "OSGi Developer Mail List" Gesendet: 18.02.2019 13:54:20 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection Hi, The build works fine for me in GitPod. You probably have corrupt things in your local repo, either delete them or force an update of snapshots (-U on the command line). Note that you also get a nice error message for the case that you claim didn’t work: [ERROR] Failed to execute goal biz.aQute.bnd:bnd-maven-plugin:4.2.0-SNAPSHOT:bnd-process (default) on project impl: In component io.jatoms.osgi.refs.ComponentImpl, field tests policy is 'dynamic' and field is not volatile. -> [Help 1] Best Regards, Tim On 18 Feb 2019, at 13:45, Thomas Driessen wrote: Hi Tim, I added this plugin repository and change the bnd.version property to 4.2.0-SNAPSHOT, but still get errors during the build with eroor message "No plugin found for prefix 'bnd-indexer' ..." Maven complains about several metadata being invalid, e.g.: The metadata /home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd Snapshots.xml is invalid The metadata /home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd Snapshots.xml is invalid The POM for biz.aQute.bnd:bnd-maven-plugin:jar:4.2.0-20190215.224729-106 is invalid ... You can have a look at the workspace and try it for yourself if you want: https://gitpod.io#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f <https://gitpod.io/#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f> Just type "resolve app" in the command line. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" Cc: "Neil Bartlett" ; "OSGi Developer Mail List" Gesendet: 18.02.2019 10:53:23 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection When I change the version number of bnd to 4.2.0 in the standard enRoute setup, then some of the bnd-plugins can not be found by maven. That’s because and 4.2.0 isn’t released yet - you need to add a plugin repository containing 4.2.0-SNAPSHOT (which is also the version you should be using. If you look at the readme for the bnd repo on GitHub you can see the repo url is https://bndtools.jfrog.io/bndtools/libs-snapshot/ Tim On 18 Feb 2019, at 10:51, Thomas Driessen wrote: Hi Neil, thanks for this small history lesson on OSGi. You live, you learn. The why is in most cases so much more interesting than the what :) I will open an issue on Github then for bnd. Kind regards, Thomas -- Originalnachricht -- Von: "Neil Bartlett" An: "Thomas Driessen" ; "OSGi Developer Mail List" Cc: "Tim Ward" Gesendet: 18.02.2019 10:44:14 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev wrote: Hi Tim, as always thanks for your super detailed answer! Just two more questions on this topic: 1) Out of curiosity: do you know why the decision was made to make the default for @Reference List static, reluctant? For 0/1..1 this makes sense to me, but for me an expected default behavior for 0/1..n references would have been dynamic, greedy, so that I end up with some services isntead of probably none. The default is reluctant because "greedy" did not exist until DS 1.2. If the default had been made greedy at that time, components coded before DS 1.2 would have seen a substantial change in behaviour that could be considered non-backwards-compatible. Static has *always* been the default over dynamic, because dynamic forces the developer to understand thread safety and to code the component much more cautiously. Static is simple and safe. 2) The observed Exception for optional/dynamic/reluctant: Is it intended? I tried to switch to bnd 4.2.0 to see if this exxception occurs there too, but was unable to do so. When I change the version number of bnd to 4.2.0 in the standard enRoute setup, then some of the bnd-plugins can not be found by maven. Probably not expected, this smells like a bug. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Cc: "Raymond Auge" Gesendet: 18.02.2019 10:15:54 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field inject
Re: [osgi-dev] Clarification on reference behavior regarding field injection
Hi Tim, I added this plugin repository and change the bnd.version property to 4.2.0-SNAPSHOT, but still get errors during the build with eroor message "No plugin found for prefix 'bnd-indexer' ..." Maven complains about several metadata being invalid, e.g.: The metadata /home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd Snapshots.xml is invalid The metadata /home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd Snapshots.xml is invalid The POM for biz.aQute.bnd:bnd-maven-plugin:jar:4.2.0-20190215.224729-106 is invalid ... You can have a look at the workspace and try it for yourself if you want: https://gitpod.io#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f Just type "resolve app" in the command line. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" Cc: "Neil Bartlett" ; "OSGi Developer Mail List" Gesendet: 18.02.2019 10:53:23 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection When I change the version number of bnd to 4.2.0 in the standard enRoute setup, then some of the bnd-plugins can not be found by maven. That’s because and 4.2.0 isn’t released yet - you need to add a plugin repository containing 4.2.0-SNAPSHOT (which is also the version you should be using. If you look at the readme for the bnd repo on GitHub you can see the repo url is https://bndtools.jfrog.io/bndtools/libs-snapshot/ Tim On 18 Feb 2019, at 10:51, Thomas Driessen wrote: Hi Neil, thanks for this small history lesson on OSGi. You live, you learn. The why is in most cases so much more interesting than the what :) I will open an issue on Github then for bnd. Kind regards, Thomas -- Originalnachricht -- Von: "Neil Bartlett" An: "Thomas Driessen" ; "OSGi Developer Mail List" Cc: "Tim Ward" Gesendet: 18.02.2019 10:44:14 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev wrote: Hi Tim, as always thanks for your super detailed answer! Just two more questions on this topic: 1) Out of curiosity: do you know why the decision was made to make the default for @Reference List static, reluctant? For 0/1..1 this makes sense to me, but for me an expected default behavior for 0/1..n references would have been dynamic, greedy, so that I end up with some services isntead of probably none. The default is reluctant because "greedy" did not exist until DS 1.2. If the default had been made greedy at that time, components coded before DS 1.2 would have seen a substantial change in behaviour that could be considered non-backwards-compatible. Static has *always* been the default over dynamic, because dynamic forces the developer to understand thread safety and to code the component much more cautiously. Static is simple and safe. 2) The observed Exception for optional/dynamic/reluctant: Is it intended? I tried to switch to bnd 4.2.0 to see if this exxception occurs there too, but was unable to do so. When I change the version number of bnd to 4.2.0 in the standard enRoute setup, then some of the bnd-plugins can not be found by maven. Probably not expected, this smells like a bug. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Cc: "Raymond Auge" Gesendet: 18.02.2019 10:15:54 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection Hi Thomas, Just to clarify, the behaviour that you see with static reluctant services will always look “odd” for cardinalities other than mandatory, and what you’ve recorded is 100% correct behaviour. Static references force the component to be re-created if the value of the reference changesReluctant references avoid rebinding the service unless it is required Therefore: An optional reference bound to nothing will never bind to anything again (unless the component is re-created for another reason) because having zero references is valid and you are reluctant to re-create the component instanceAn optional reference bound to a service will not change until that service is unregistered (ignoring all new services), at which point it will either:Pick up the highest ranked of any matching registered servicesBind to nothing if no matching services are availableA multiple reference bound to nothing will behave exactly like an optional componentA multiple reference bound to one or more services will not change until any of the bound services are unregistered (ignoring all new services), at which point it will either:Pick up all the available registered servicesBind to nothing if no matching services are availableA
Re: [osgi-dev] Clarification on reference behavior regarding field injection
Hi Neil, thanks for this small history lesson on OSGi. You live, you learn. The why is in most cases so much more interesting than the what :) I will open an issue on Github then for bnd. Kind regards, Thomas -- Originalnachricht -- Von: "Neil Bartlett" An: "Thomas Driessen" ; "OSGi Developer Mail List" Cc: "Tim Ward" Gesendet: 18.02.2019 10:44:14 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev wrote: Hi Tim, as always thanks for your super detailed answer! Just two more questions on this topic: 1) Out of curiosity: do you know why the decision was made to make the default for @Reference List static, reluctant? For 0/1..1 this makes sense to me, but for me an expected default behavior for 0/1..n references would have been dynamic, greedy, so that I end up with some services isntead of probably none. The default is reluctant because "greedy" did not exist until DS 1.2. If the default had been made greedy at that time, components coded before DS 1.2 would have seen a substantial change in behaviour that could be considered non-backwards-compatible. Static has *always* been the default over dynamic, because dynamic forces the developer to understand thread safety and to code the component much more cautiously. Static is simple and safe. 2) The observed Exception for optional/dynamic/reluctant: Is it intended? I tried to switch to bnd 4.2.0 to see if this exxception occurs there too, but was unable to do so. When I change the version number of bnd to 4.2.0 in the standard enRoute setup, then some of the bnd-plugins can not be found by maven. Probably not expected, this smells like a bug. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Cc: "Raymond Auge" Gesendet: 18.02.2019 10:15:54 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection Hi Thomas, Just to clarify, the behaviour that you see with static reluctant services will always look “odd” for cardinalities other than mandatory, and what you’ve recorded is 100% correct behaviour. Static references force the component to be re-created if the value of the reference changesReluctant references avoid rebinding the service unless it is required Therefore: An optional reference bound to nothing will never bind to anything again (unless the component is re-created for another reason) because having zero references is valid and you are reluctant to re-create the component instanceAn optional reference bound to a service will not change until that service is unregistered (ignoring all new services), at which point it will either:Pick up the highest ranked of any matching registered servicesBind to nothing if no matching services are availableA multiple reference bound to nothing will behave exactly like an optional componentA multiple reference bound to one or more services will not change until any of the bound services are unregistered (ignoring all new services), at which point it will either:Pick up all the available registered servicesBind to nothing if no matching services are availableAn “at least one" reference bound to one or more services will not change until any of the bound services are unregistered (ignoring all new services), at which point it will either:Pick up all the available registered servicesMake the component unsatisfied The end result of this is that references that can accept zero will tend to zero over time, and then tend to stay with zero bound references. At least one references will tend to a small number of “stable” services with new services ignored. In general references of these types should be dynamic or greedy (or both). Best Regards, Tim On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev wrote: Oh Sorry :/ Those combinations with cardinalities optional/mandatory have been assigned to ITest, those with multiple/at_least_one have been assigned to List. I didn't think it makes sense to assign them vice versa, e.g., ITest with multiple or List with mandatory? Or am I wrong? If so, in what case would you use such a combination? Kind regards, Thomas -- Originalnachricht -- Von: "Raymond Auge" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 16.02.2019 17:42:19 Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field injection You're chart doesn't appear to list _which_ field (Reference) was associated with any given line (collection vs. scalar). It makes a difference. - Ray On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev wrote: Hi, I'm trying to get an overview over the effects of different combinations of cardinality
Re: [osgi-dev] Clarification on reference behavior regarding field injection
Hi Tim,
as always thanks for your super detailed answer!
Just two more questions on this topic:
1) Out of curiosity: do you know why the decision was made to make the
default for @Reference List static, reluctant? For 0/1..1 this
makes sense to me, but for me an expected default behavior for 0/1..n
references would have been dynamic, greedy, so that I end up with some
services isntead of probably none.
2) The observed Exception for optional/dynamic/reluctant: Is it
intended? I tried to switch to bnd 4.2.0 to see if this exxception
occurs there too, but was unable to do so. When I change the version
number of bnd to 4.2.0 in the standard enRoute setup, then some of the
bnd-plugins can not be found by maven.
Kind regards,
Thomas
-- Originalnachricht --
Von: "Tim Ward"
An: "Thomas Driessen" ; "OSGi Developer
Mail List"
Cc: "Raymond Auge"
Gesendet: 18.02.2019 10:15:54
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
field injection
Hi Thomas,
Just to clarify, the behaviour that you see with static reluctant
services will always look “odd” for cardinalities other than mandatory,
and what you’ve recorded is 100% correct behaviour.
Static references force the component to be re-created if the value of
the reference changesReluctant references avoid rebinding the service
unless it is required
Therefore:
An optional reference bound to nothing will never bind to anything
again (unless the component is re-created for another reason) because
having zero references is valid and you are reluctant to re-create the
component instanceAn optional reference bound to a service will not
change until that service is unregistered (ignoring all new services),
at which point it will either:Pick up the highest ranked of any
matching registered servicesBind to nothing if no matching services are
availableA multiple reference bound to nothing will behave exactly like
an optional componentA multiple reference bound to one or more services
will not change until any of the bound services are unregistered
(ignoring all new services), at which point it will either:Pick up all
the available registered servicesBind to nothing if no matching
services are availableAn “at least one" reference bound to one or more
services will not change until any of the bound services are
unregistered (ignoring all new services), at which point it will
either:Pick up all the available registered servicesMake the component
unsatisfied
The end result of this is that references that can accept zero will
tend to zero over time, and then tend to stay with zero bound
references. At least one references will tend to a small number of
“stable” services with new services ignored.
In general references of these types should be dynamic or greedy (or
both).
Best Regards,
Tim
On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev
wrote:
Oh Sorry :/
Those combinations with cardinalities optional/mandatory have been
assigned to ITest, those with multiple/at_least_one have been assigned
to List.
I didn't think it makes sense to assign them vice versa, e.g., ITest
with multiple or List with mandatory? Or am I wrong? If so, in
what case would you use such a combination?
Kind regards,
Thomas
-- Originalnachricht ------
Von: "Raymond Auge"
An: "Thomas Driessen" ; "OSGi Developer
Mail List"
Gesendet: 16.02.2019 17:42:19
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
field injection
You're chart doesn't appear to list _which_ field (Reference) was
associated with any given line (collection vs. scalar). It makes a
difference.
- Ray
On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev
wrote:
Hi,
I'm trying to get an overview over the effects of different
combinations of cardinality, policy and policyOption within a
@Reference annotation for a field.
My Example looks like this:
@Component
public class MyComp{
@Reference(...)
ITest myTest;
@Reference(...)
List myTests;
}
and the observed behavior for this setup with different combinations
of the above named properties is:
I'm especially interested in the yellow marked cases: Is this an
intended behavior?
Kind regards,
Thomas
___
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
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Clarification on reference behavior regarding field injection
Oh Sorry :/
Those combinations with cardinalities optional/mandatory have been
assigned to ITest, those with multiple/at_least_one have been assigned
to List.
I didn't think it makes sense to assign them vice versa, e.g., ITest
with multiple or List with mandatory? Or am I wrong? If so, in
what case would you use such a combination?
Kind regards,
Thomas
-- Originalnachricht --
Von: "Raymond Auge"
An: "Thomas Driessen" ; "OSGi Developer
Mail List"
Gesendet: 16.02.2019 17:42:19
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
field injection
You're chart doesn't appear to list _which_ field (Reference) was
associated with any given line (collection vs. scalar). It makes a
difference.
- Ray
On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev
wrote:
Hi,
I'm trying to get an overview over the effects of different
combinations of cardinality, policy and policyOption within a
@Reference annotation for a field.
My Example looks like this:
@Component
public class MyComp{
@Reference(...)
ITest myTest;
@Reference(...)
List myTests;
}
and the observed behavior for this setup with different combinations
of the above named properties is:
I'm especially interested in the yellow marked cases: Is this an
intended behavior?
Kind regards,
Thomas
___
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
[osgi-dev] Clarification on reference behavior regarding field injection
Hi,
I'm trying to get an overview over the effects of different combinations of
cardinality, policy and policyOption within a @Reference annotation for a
field.
My Example looks like this:
@Component
public class MyComp{
@Reference(...)
ITest myTest;
@Reference(...)
List myTests;
}
and the observed behavior for this setup with different combinations of the
above named properties is:
[image: image.png]
I'm especially interested in the yellow marked cases: Is this an intended
behavior?
Kind regards,
Thomas
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Aliasing OSGi DS annotations
Hi Toni, hi Tim, thanks for this information :) Your're probably right. This is too much effort for a simple name clash. Kind regards, Thomas Am Do., 14. Feb. 2019, 12:08 hat Toni Menzel geschrieben: > Keep in mind that DS Annotations are compile-time only annotations where > the tooling produces the (relevant) xml spec at build-time. > You of cause can your own annotations and either add the DS annotations > underneath before tooling kicks-in or generate the xml fully yourself. The > benefit of the second approach might be that your annotations can be more > specific than the DS annotations. The downside is that you lose IDE support > like Bndtools (if this is desired). > > Its been one of the things we where looking into some time ago. Direct > aliasing (or even extension) support what be awesome. But you would end up > doing a large mile by yourself. > In your case - you only wanting to go around the name-clash - its probably > way too much. > > Toni Menzel > > *Developer Ergonomist* > rebaze consultancy > Alleestrasse 25 / 30167 Hannover / Germany > M +49 171 6520284 > www.rebaze.com > > rebaze GmbH, Zollstrasse 6, 39114 Hannover, Germany > Managing Director: Toni Menzel > Phone: +49 <+49%2030%2054909582> 171 6520284 / E-Mail: h...@rebaze.com > Registration Court: District Court of Stendal > Registration Number: HRB 17993 > Sales Tax (VAT) Registration Number: DE282233792 > > > > On Thu, Feb 14, 2019 at 11:48 AM Tim Ward via osgi-dev < > osgi-dev@mail.osgi.org> wrote: > >> Hi, >> >> There isn’t any sort of Aliasing for DS annotations. >> >> Best Regards, >> >> Tim >> >> On 14 Feb 2019, at 09:10, Thomas Driessen via osgi-dev < >> osgi-dev@mail.osgi.org> wrote: >> >> Hi, >> >> is there a mechanism in OSGi that allows to alias specific (DS) >> annotations? (Seems to be possible in Spring according to Vaadin) >> >> Currently Vaadin tries to implement an integration for OSGi and there is >> the case where Users will need to annotate the class with OSGi's @Component >> annotation that declares the service to be Vaadin's Component class. So one >> of them would have to be written with the fqcn. >> >> It's just an inconvenience, but if there's a way to work around that this >> would be great :) >> >> 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 > > ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Programmatically creating DS components
Hi Todor, thank you so much for your detailed explanation and the additional links. That helped me a lot to simplify my implementation for Vaadin. Hopefully this will lead to a seamless integration between Vaadin and OSGi. Kind regards, Thomas Am Di., 12. Feb. 2019 um 11:05 Uhr schrieb Boev, Todor < todor.b...@softwareag.com>: > Hi Thomas, > > A better design would be to implement a whiteboard pattern rather than an > extender. > Rather than to track and scan bundles it is better to track OSGi services > that extend Component and > plug those into Vaadin directly. > > To make sure Vaadin gets a fresh object every time it needs you can > recommend to your users to > register their services with a property "service.scope=prototype". This > property instructs the OSGi > framework to create a new object every time an attempt is made to grab the > service. Your > OSGiInstantiator will then just grab the service every time it is asked to > create an object. > The users may still choose to use a singleton object if it is stateless > for example. > > In this design you abstract away how the users choose to create and > register their service. > In the case when they choose Declarative Services they will create a > regular DS component > with "service.scope=prototype". No need of a component factory. > > The OSGiInstantiator has to hold on to objects of this type: > > https://osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/ServiceObjects.html > Which are obtained like this: > > > https://osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleContext.html#getServiceObjects-org.osgi.framework.ServiceReference > - > It has to store the service instances it creates and release them when > appropriate. > > The principles of this design are tried and tested in OSGi specifications > like the > Http integration - where the core gathers Servlet and Filter services or > the JAX-RS integration > where the core gathers resources. > > In my opinion the major technical issues you face are: > 1. You likely have to pass to Vaadin all classes that it needs to plug > into the web app ahead of > time. This means you need to inspect each Component service when it > arrives to get it's concrete > class. Basically probe the service by getting one instance then getting > it's class then releasing > the instance. Then you may need to reboot the Vaadin application with the > new class added. > > 2. The OSGiInstantiator is created through ServiceLoader. This means you > can not initialize it with > the concrete OSGi service object. It may have to pass through static > fields that are populated with > the Component services by other parts of your whiteboard. This can also > introduce lifecycle issues > since the OSGiIntantiator may be created before a service it needs is > added so it may need to block > for a period of time. If you can pass a ready made OSGiInstantiator to > Vaadin it will be ideal. > > These implementation complications are well worth the power/simplicity you > give the users to > completely control the lifecycle and implementation style of their > components. > > > P.S. With all that said I think there is a real issue with DS and > programmatic creation of > components. Since component factories are frowned upon the next best thing > is to register > "service.scope=prototype" services that may need setters or initializtion > methods. The party > that needs to make programmatically the component can grab a fresh > instance and the customize it. > Another pattern I have used is to just add configurations to ConfigAdmin. > > Hope this helps, > Todor > > > On Mon, 2019-02-11 at 09:12 +, Thomas Driessen via osgi-dev wrote: > > Hi Ray, > > > > thanks for your time and advice. > > > > Regarding your question: > > > > The classes are annotated by whoever wants to register a @Route in > Vaadin. Routes in Vaadin are > > usually a specific location within a web application. Classes that are > annotated with @Route are > > extending Vaadin's Component class and are instantiated by Vaadin > whenever a new client requests > > the respective part of the web application. Vaadin delegates the > instantiation of the class to an > > Instantiator, this is usually the DefaultInstantiator class in Vaadin. > > > > I try to delegate this instantiation to OSGi by extending Vaadins > DefaultInstantiator and > > registering the new OSGiInstantiator via ServiceLoader mechanism which > is internally used by > > Vaadin to find its Instantiators. > > Whenever Vaadin calls an Instantiator it passes a class that has to be > instantiat
Re: [osgi-dev] Programmatically creating DS components
Hi Ray,
thanks for your time and advice.
Regarding your question:
The classes are annotated by whoever wants to register a @Route in
Vaadin. Routes in Vaadin are usually a specific location within a web
application. Classes that are annotated with @Route are extending
Vaadin's Component class and are instantiated by Vaadin whenever a new
client requests the respective part of the web application. Vaadin
delegates the instantiation of the class to an Instantiator, this is
usually the DefaultInstantiator class in Vaadin.
I try to delegate this instantiation to OSGi by extending Vaadins
DefaultInstantiator and registering the new OSGiInstantiator via
ServiceLoader mechanism which is internally used by Vaadin to find its
Instantiators.
Whenever Vaadin calls an Instantiator it passes a class that has to be
instantiated.
This is the place where I'm using ComponentFactory to create instances
of those classes.
You can also have a look on all of these classes and additional
information about the intended logic flow at my repository:
https://github.com/Sandared/flow-osgi
Kind regards,
Thomas
-- Originalnachricht --
Von: "Raymond Auge"
An: "Thomas Driessen"
Cc: "OSGi Developer Mail List"
Gesendet: 10.02.2019 18:05:56
Betreff: Re: [osgi-dev] Programmatically creating DS components
On Sun, Feb 10, 2019 at 11:20 AM Thomas Driessen
wrote:
Hi Ray,
I'm not defining any additional manifest header if that's what you
mean. I have no real control over the bundles I need to scan.
What I do is registering a BundleTracker that scans a bundle's classes
if its wiring states it is importing the package of the annotation I'm
looking for.
(Can be seen here:
https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiRouteTracker.java)
This is precisely the "extender pattern" [1].
Those classes usually look something like this:
@Route("")
@Component(factory="fqcn")
public class MyFancyUI extends Component {
@Reference
SomeService service;
...
}
So I'm looking into the wiring of the bundle if it has imported the
package "com.vaadin.flow.router" . If so I then scan the bundle's
classes for the @Route annotation (and @RouteAlias).
Classes that have this annotation can later on be instantiated via
ComponentFactory.
Can I instantiate such a component with the Apache Aries approach and
if so will its reference be injected? I'm not sure if this is done if
I'm registering the instance just as a service.
Let's start with how the classes came to be annotated with @Component,
and why that isn't already enough.
- Ray
[1] https://blog.osgi.org/2007/02/osgi-extender-model.html
Kind regards,
Thomas
Am So., 10. Feb. 2019 um 15:38 Uhr schrieb Raymond Auge
:
Are you implementing this using the extender pattern? If so, I would
not use DS. I would use something lower level.
There are plenty of good alternatives for doing this, but I would
suggest looking at Apache Aries Component DSL [1] (it's what is used
to implement Aries JAXRS Whiteboard).
- Ray
[1] https://github.com/apache/aries/tree/trunk/component-dsl
On Sun, Feb 10, 2019 at 8:01 AM Thomas Driessen via osgi-dev
wrote:
Hi,
I'm currently trying to sketch out a possible better OSGi
integration for Vaadin 10+.
For this I need to programmatically create DS components in order to
make @Route/@RouteAlias annotated classes also DS components.
Right now I'm doing this via ComponentFactory and the assumption
that all @Route annotated classes are also annotated with
@Component(factory="fully qualified class name")
I don't think this is the best way to do this. Having to type the
fqcn seems rather errorprone to me and therefore I wanted to ask if
there is a better way (maybe even a typesafe way) to do this?
The code instantiating a component can be seen here:
https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiInstantiator.java
The class that shall be instantiated can be seen here:
https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.simpleui/src/main/java/io/jatoms/flow/osgi/simpleui/MainView.java
Any advice is highly appreciated.
Kind regards,
Thomas
___
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)
--
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://
Re: [osgi-dev] Programmatically creating DS components
Hi Ray,
I'm not defining any additional manifest header if that's what you mean. I
have no real control over the bundles I need to scan.
What I do is registering a BundleTracker that scans a bundle's classes if
its wiring states it is importing the package of the annotation I'm looking
for.
(Can be seen here:
https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiRouteTracker.java
)
Those classes usually look something like this:
@Route("")
@Component(factory="fqcn")
public class MyFancyUI extends Component {
@Reference
SomeService service;
...
}
So I'm looking into the wiring of the bundle if it has imported the package
"com.vaadin.flow.router" . If so I then scan the bundle's classes for
the @Route annotation (and @RouteAlias).
Classes that have this annotation can later on be instantiated via
ComponentFactory.
Can I instantiate such a component with the Apache Aries approach and if so
will its reference be injected? I'm not sure if this is done if I'm
registering the instance just as a service.
Kind regards,
Thomas
Am So., 10. Feb. 2019 um 15:38 Uhr schrieb Raymond Auge <
raymond.a...@liferay.com>:
> Are you implementing this using the extender pattern? If so, I would not
> use DS. I would use something lower level.
>
> There are plenty of good alternatives for doing this, but I would suggest
> looking at Apache Aries Component DSL [1] (it's what is used to implement
> Aries JAXRS Whiteboard).
>
> - Ray
>
> [1] https://github.com/apache/aries/tree/trunk/component-dsl
>
> On Sun, Feb 10, 2019 at 8:01 AM Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi,
>>
>> I'm currently trying to sketch out a possible better OSGi integration for
>> Vaadin 10+.
>>
>> For this I need to programmatically create DS components in order to
>> make @Route/@RouteAlias annotated classes also DS components.
>>
>> Right now I'm doing this via ComponentFactory and the assumption that
>> all @Route annotated classes are also annotated with
>> @Component(factory="fully qualified class name")
>>
>> I don't think this is the best way to do this. Having to type the fqcn
>> seems rather errorprone to me and therefore I wanted to ask if there is a
>> better way (maybe even a typesafe way) to do this?
>>
>> The code instantiating a component can be seen here:
>> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiInstantiator.java
>> The class that shall be instantiated can be seen here:
>> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.simpleui/src/main/java/io/jatoms/flow/osgi/simpleui/MainView.java
>>
>> Any advice is highly appreciated.
>>
>> Kind regards,
>> Thomas
>> ___
>> 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
[osgi-dev] Programmatically creating DS components
Hi, I'm currently trying to sketch out a possible better OSGi integration for Vaadin 10+. For this I need to programmatically create DS components in order to make @Route/@RouteAlias annotated classes also DS components. Right now I'm doing this via ComponentFactory and the assumption that all @Route annotated classes are also annotated with @Component(factory="fully qualified class name") I don't think this is the best way to do this. Having to type the fqcn seems rather errorprone to me and therefore I wanted to ask if there is a better way (maybe even a typesafe way) to do this? The code instantiating a component can be seen here: https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiInstantiator.java The class that shall be instantiated can be seen here: https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.simpleui/src/main/java/io/jatoms/flow/osgi/simpleui/MainView.java Any advice is highly appreciated. Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] enRoute Project archetype not working correctly?
Hi Tim, you're probably right. When using the archetype command of the quickstart tutorial on a linux machine, then everything works as expected. The error only occurs when I create the project via Eclipse, i.e., New -> Maven Project -> enroute project archetype. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 05.02.2019 17:19:15 Betreff: Re: [osgi-dev] enRoute Project archetype not working correctly? Hi Thomas, What was the command that you used to generate the folders? The Maven Archetype Plugin is useful, but the default version used by Maven is pretty old. The OSGi enRoute recommendation is that you use version 3.0.1 of the archetype plugin, as described in https://enroute.osgi.org/tutorial/020-tutorial_qs.html#project-setup It’s possible that if you used an old version of the archetype plugin that it failed to correctly rename the folder based on the template variable value. Best Regards, Tim On 4 Feb 2019, at 12:13, Thomas Driessen via osgi-dev wrote: Hi, I just used the enRoute project archetype and this one does generate two subfolders named __app-artifactId__ and __impl-artifactId__. When I now import this project from git in another Eclipse Instance, Eclipse complains about missing child modules example.app/example.impl which are the artifactIds I used for app and impl during project creation. Shouldn't the folders be named according to the artifactIds instead of __app-artifactId__ and __impl-artifactId__ ? 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
[osgi-dev] OSGi Vaadin 10+ Integration
Hi, this is just an information for those of you who are interested in using Vaadin and OSGi together. Although Vaadin is making V10+ OSGi compatible (adding manifests, using BundleTracker instead of ServletContainerInitializer, etc.) they do not yet have integrated Declarative Services as they did for V8-. The former integration of V8- enabled a developer to declare a Vaadin UI to be a component in OSGi, thus being able to reference other services. This is not yet possible in V10+ where UIs are replaced by @Route annotated classes. I'm trying to add such an integration and if anyone on this mailinglist is interested in such a support (I think at least Paul will be ;) ) then don't hesitate to comment/vote up the respective issue at Vaadin (https://github.com/vaadin/flow/issues/5017) or comment/contribute on/to the implementation sketch (not working yet) at Github (https://github.com/Sandared/flow-osgi) As I'm fiddling around with (at least for me) advanced DS stuff, please let me know if I do not adhere to some known best practises/am messing up the implementation/did an awfully bad design or anything else (You live and learn ;) ). Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] enRoute Project archetype not working correctly?
Hi, I just used the enRoute project archetype and this one does generate two subfolders named __app-artifactId__ and __impl-artifactId__. When I now import this project from git in another Eclipse Instance, Eclipse complains about missing child modules example.app/example.impl which are the artifactIds I used for app and impl during project creation. Shouldn't the folders be named according to the artifactIds instead of __app-artifactId__ and __impl-artifactId__ ? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] ServletContextListener not working?
Hi Dirk,
I've read all of your great blog post. By the way thank you for those .
Unfortunately, in those you do exact the same things as I did in my example.
The servlet looks like this:
@Component(service = Servlet.class, scope = ServiceScope.PROTOTYPE)
public class MyServlet extends HttpServlet{
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
resp.setContentType("text/plain");
resp.getWriter().println("Hello World!");
}
}
and the ServletContextListener like this:
@Component
@HttpWhiteboardListener
public class MySCL implements ServletContextListener {
@Override
public void contextDestroyed(ServletContextEvent arg0) {
System.out.println("Destroyed");
}
@Override
public void contextInitialized(ServletContextEvent arg0) {
System.out.println("Initialized");
}
}
I think by using the new annotations everything should be set up right. The
Servlet works as expected, but the SCL is never called.
In contrast to your blog post examples I didn't use any specific
ServletContext(Helper), but I thought this would lead to using the default
ServletContext. I think in most of my cases I do not need to use a specific
ServletContext,, so the default would be sufficient.
Kind regards,
Thomas
Am Sa., 2. Feb. 2019 um 16:50 Uhr schrieb Dirk Fauth :
> Hi,
>
> Not sure if this helps, but I wrote a blog post a while ago where I also
> used a ServletContextListener in my example.
>
> http://blog.vogella.com/2017/04/20/access-osgi-services-via-web-interface/
>
> Maybe it helps in finding the cause.
>
> Are you using the http whiteboard pattern and did you set the required
> component property?
>
> Greez,
> Dirk
>
> Am Sa., 2. Feb. 2019, 16:07 hat Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> geschrieben:
>
>> Hi,
>>
>> I just tried to get a ServletContextListener to work, but did not
>> succeed, although everything is done as defined by the spec.
>>
>> Here you can find a minimal example of my setup
>> https://github.com/Sandared/io.jatoms.osgi.possiblebugs.scl
>>
>> The Servlet I'm registering is working fine, but the
>> ServletContextListener that I registered too is never called.
>> Even if I call getServletContext() from within the Servlet, my Listener
>> is never called.
>>
>> I would have expected the ServletContextListener to be called at least
>> once, after a DefaultServletContext has been created by the
>> ServletContainer, or am I wrong with this assumption?
>>
>> 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
[osgi-dev] ServletContextListener not working?
Hi, I just tried to get a ServletContextListener to work, but did not succeed, although everything is done as defined by the spec. Here you can find a minimal example of my setup https://github.com/Sandared/io.jatoms.osgi.possiblebugs.scl The Servlet I'm registering is working fine, but the ServletContextListener that I registered too is never called. Even if I call getServletContext() from within the Servlet, my Listener is never called. I would have expected the ServletContextListener to be called at least once, after a DefaultServletContext has been created by the ServletContainer, or am I wrong with this assumption? Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] enRoute workspace debugging
It seems those are the .java files within the OSGI-OPT folder of the generated bundle/.jar. But I have no idea why Eclipse picks those up when it is debugging. I used the enroute archetypes and didn't change anything. Maybe it's just a setting somewhere in Eclipse that has to be changed or within the pom files, I don't know :( Am Sa., 2. Feb. 2019 um 03:55 Uhr schrieb Raymond Auge via osgi-dev < osgi-dev@mail.osgi.org>: > The bigger question is why I'm the world are there java files in target? > target is the build directory. We are there source files in there? > > - Ray > > On Fri, Feb 1, 2019, 13:47 Paul F Fraser via osgi-dev < > osgi-dev@mail.osgi.org wrote: > >> Thomas, >> Thank goodness someone else has experienced this. I thought it was my >> problem only. >> I mentioned this on this list previously but so far no response. >> Paul >> >> >> On 2/02/2019 3:54 am, Thomas Driessen via osgi-dev wrote: >> >> Hi, >> >> now that I'm using the enroute maven workspace I stumbled upon another >> issue. >> >> When I'm debugging and a breakpoint is hit, then Eclipse does not open >> the respective .java file in my project, >> but the java file from the target folder. >> Now each time I want to change breakpoints/code/etc. I have to go back to >> the workspace .java file. >> Is there a way to tell Eclipse to use the workspace .java file instead of >> the target folder .java file for debugging? >> >> Kind regards, >> Thomas >> >> ___ >> OSGi Developer Mail >> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> ___ >> 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 ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] enRoute workspace debugging
Hi, now that I'm using the enroute maven workspace I stumbled upon another issue. When I'm debugging and a breakpoint is hit, then Eclipse does not open the respective .java file in my project, but the java file from the target folder. Now each time I want to change breakpoints/code/etc. I have to go back to the workspace .java file. Is there a way to tell Eclipse to use the workspace .java file instead of the target folder .java file for debugging? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Scanning classes at runtime
Hi Tim, just an update to this issue: I've implemented the BundleTracker as indicated by you. Now I just wanted to know, if that's the way you meant it to be or if there is a more elegant way to do this? The implementation scanning all bundles for a specific import package that contains the annotation I'm looking for can be found here: https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOSGiTracker.java Kind regards, Thomas -- Originalnachricht -- Von: "Thomas Driessen" An: "Tim Ward" Gesendet: 23.01.2019 17:56:49 Betreff: Re[2]: [osgi-dev] Scanning classes at runtime Unfortunatly I don't have any control over the bundles that I have to inspect. However, I could offer a second scanning implementation that uses the req-cap strategy if a developer wants to use that. Thanks again :) -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 23.01.2019 17:51:25 Betreff: Re: [osgi-dev] Scanning classes at runtime Depending on how much control you have over the bundles providing the types you could also look at providing your own extender capabiltiy/requirement model which would further restrict your search space, and potentially allow further optimisations. You should take a look at the OSGi CDI specification from the enterprise R7 release (currently in draft) which does something very much like this. Tim On 23 Jan 2019, at 16:48, Tim Ward wrote: Hi, You can optimise this pretty heavily by using the bundle wirings to look for bundles which are wired to the same API packages as you (the one(s) that contain the relevant interface/supertype/annotation). This way you can avoid scanning bundles which can’t possibly contain relevant types. Best Regards, Tim On 23 Jan 2019, at 16:10, Thomas Driessen via osgi-dev wrote: Hi, for a project of mine I need to mimic the behavior of a ServletContainerInitializer [1], but with the dynamism of OSGi in mind. Therefore, I need to be able to find all classes that implement/extend a specific class or are annotated with a specific annotation at runtime. Is there a better way to do so that I'm not aware of than to scan each class of every bundle? Are there maybe framework hooks that would help me accomplish this? I'm thankful for every hint you can provide. Kind regards, Thomas [1] https://docs.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html ___ 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
Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace
Hi Paul, yes you're right with respect to Vaadin :) Actually, the reason I'm exploring the new enRoute maven setup is because of Vaadin10+. Do you actually use OSGi and Vaadin10+ in combination? If so, is there a possibility to declare @Routes to be also @Components? As I get it, the guys at Vaadin are doing their best to make Vaadin OSGi compatible. Until now it seems that the only thing that is possible is to run Vaadin within an OSGi container, but not to declare @Routes as @Components, which would be the actual benefit, IMHO. In Vaadin8 this was possible either to my own integration or later on through their adaptation of it. Kind regards, Thomas -- Originalnachricht -- Von: "Paul F Fraser via osgi-dev" An: osgi-dev@mail.osgi.org Gesendet: 31.01.2019 23:45:35 Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace Hi Thomas, I have been going through the same trauma as you with a fond attachment to the bnd workspace and a dislike of maven. I think you also have an interest in Vaadin. Vaadin has been the catalyst for me having to get to know and use the new enRoute. The ease of using Vaadin addons and the new Vaadin flow when using maven has made the journey to date worthwhile. Without a solid maven background it is bloody difficult and time consuming. I am now finding that the maven process can be as convenient as the bnd workspace approach but still with a few hiccups. Stick with it, I am. Note : R7 makes the whole OSGi process much better. DS forever, obliterate all previous internet OSGi history :-) Regards Paul Fraser On 1/02/2019 8:43 am, Thomas Driessen via osgi-dev wrote: Hi Christian, thanks for the advice. I've done this already and it works, but is obviously not as convenient as using bndtools ;) I thought that I could maybe use another IDE than Eclipse but without bndtools the development is rather cumbersome :/ Bndtools adds so many awesome features that once you've used them you don't want to miss them in another IDE ;) But anyway, thanks for all your advices :) Kind regards, Thomas Am Do., 31. Jan. 2019 um 18:17 Uhr schrieb Christian Schneider : What you can do is to export your project into a runnable jar using maven: https://github.com/cschneider/osgi-ds-hello-world/blob/master/starter/pom.xml#L117-L169 So you simply do mvn clean package. After that you can start it using: java -jar This is not as convenient as bndtools but still not bad. Christian Am Do., 31. Jan. 2019 um 18:03 Uhr schrieb Thomas Driessen via osgi-dev : Hi Tim, thanks for your answer and the link. I will have a look into it :) Is there any chance that something like a mvn bnd:run/debug command (like mvn jetty:run) will be implemented in the future? This would be great if a user doesn't want to use Eclipse as IDE :) Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" Cc: "OSGi Developer Mail List" Gesendet: 31.01.2019 17:58:45 Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace Hi Thomas, The simple answer to your question is yes, however the more involved answer is that you probably shouldn’t. If you want to read up on ways to handle Maven dependency management then I can suggest looking at: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html This will talk you through how dependencies can be inherited from the parent directly (not usually a good idea), how versions of common dependencies can be managed centrally in a parent (usually a good idea), and how to construct a Bill Of Materials (BOM) which you can use as an easy way to grab a bunch of dependencies in one go (much like OSGi enRoute does with its indexes). As for running directly from the command line. There isn’t an enRoute or bnd plugin for that, the smarts are all in Bndtools I’m afraid. Best Regards, Tim On 31 Jan 2019, at 16:09, Thomas Driessen wrote: Hi Tim, just to clarify (I'm not really used to maven yet): If I want to define a dependency that is used by multiple sub modules, then I MAY put this dependency in the root/parent pom. I also COULD put this dependency in each of the sub module's poms which would have the same effect as the aforementioned approach. I don't need to define the dependecnies in both places. Is this correct? Regarding the running and reloading of applications in bndtools: I don't use Eclipse, therefore I asked if there are maven commands that mimc bndtools' behavior ;) Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 31.01.2019 16:48:54 Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace Hi On 31 Jan 2019, at 15:22, Thomas Driessen via osgi-dev wrote: Hi, I'm currently trying to get used to the new enroute maven w
Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace
Hi Christian, thanks for the advice. I've done this already and it works, but is obviously not as convenient as using bndtools ;) I thought that I could maybe use another IDE than Eclipse but without bndtools the development is rather cumbersome :/ Bndtools adds so many awesome features that once you've used them you don't want to miss them in another IDE ;) But anyway, thanks for all your advices :) Kind regards, Thomas Am Do., 31. Jan. 2019 um 18:17 Uhr schrieb Christian Schneider < ch...@die-schneider.net>: > What you can do is to export your project into a runnable jar using maven: > > https://github.com/cschneider/osgi-ds-hello-world/blob/master/starter/pom.xml#L117-L169 > > So you simply do mvn clean package. > After that you can start it using: > java -jar > > This is not as convenient as bndtools but still not bad. > > Christian > > > Am Do., 31. Jan. 2019 um 18:03 Uhr schrieb Thomas Driessen via osgi-dev < > osgi-dev@mail.osgi.org>: > >> Hi Tim, >> >> thanks for your answer and the link. I will have a look into it :) >> >> Is there any chance that something like a mvn bnd:run/debug command (like >> mvn jetty:run) will be implemented in the future? >> This would be great if a user doesn't want to use Eclipse as IDE :) >> >> Kind regards, >> Thomas >> >> -- Originalnachricht -- >> Von: "Tim Ward" >> An: "Thomas Driessen" >> Cc: "OSGi Developer Mail List" >> Gesendet: 31.01.2019 17:58:45 >> Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) >> workspace >> >> Hi Thomas, >> >> The simple answer to your question is yes, however the more involved >> answer is that you probably shouldn’t. If you want to read up on ways to >> handle Maven dependency management then I can suggest looking at: >> >> >> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html >> >> This will talk you through how dependencies can be inherited from the >> parent directly (not usually a good idea), how versions of common >> dependencies can be managed centrally in a parent (usually a good idea), >> and how to construct a Bill Of Materials (BOM) which you can use as an easy >> way to grab a bunch of dependencies in one go (much like OSGi enRoute does >> with its indexes). >> >> As for running directly from the command line. There isn’t an enRoute or >> bnd plugin for that, the smarts are all in Bndtools I’m afraid. >> >> Best Regards, >> >> Tim >> >> On 31 Jan 2019, at 16:09, Thomas Driessen >> wrote: >> >> Hi Tim, >> >> just to clarify (I'm not really used to maven yet): >> >> If I want to define a dependency that is used by multiple sub modules, >> then I MAY put this dependency in the root/parent pom. I also COULD put >> this dependency in each of the sub module's poms which would have the same >> effect as the aforementioned approach. I don't need to define the >> dependecnies in both places. >> >> Is this correct? >> >> >> Regarding the running and reloading of applications in bndtools: I don't >> use Eclipse, therefore I asked if there are maven commands that mimc >> bndtools' behavior ;) >> >> >> Kind regards, >> Thomas >> >> -- Originalnachricht -- >> Von: "Tim Ward" >> An: "Thomas Driessen" ; "OSGi Developer >> Mail List" >> Gesendet: 31.01.2019 16:48:54 >> Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) >> workspace >> >> Hi >> >> On 31 Jan 2019, at 15:22, Thomas Driessen via osgi-dev < >> osgi-dev@mail.osgi.org> wrote: >> >> Hi, >> >> I'm currently trying to get used to the new enroute maven workspace >> layout and now have some questions :) >> >> 1) >> In a bnd workspace I had the central.xml file where I put all the >> dependencies I wanted in my local maven bnd worspace repository. Where do I >> put those dependencies now in the maven project workspace? In the >> dependencies section of the root pom or rather in the dependencies section >> of a specific module pom? >> >> >> In this case you treat your dependencies just like you would in Maven. If >> the dependency is used across many modules then you might add it to the >> dependencyManagement section of the parent pom (to manage the version in a >> single place), but you will always reference a dependency in the module >> using it. There is nothing special about this (it really
Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace
Hi Tim, thanks for your answer and the link. I will have a look into it :) Is there any chance that something like a mvn bnd:run/debug command (like mvn jetty:run) will be implemented in the future? This would be great if a user doesn't want to use Eclipse as IDE :) Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" Cc: "OSGi Developer Mail List" Gesendet: 31.01.2019 17:58:45 Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace Hi Thomas, The simple answer to your question is yes, however the more involved answer is that you probably shouldn’t. If you want to read up on ways to handle Maven dependency management then I can suggest looking at: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html This will talk you through how dependencies can be inherited from the parent directly (not usually a good idea), how versions of common dependencies can be managed centrally in a parent (usually a good idea), and how to construct a Bill Of Materials (BOM) which you can use as an easy way to grab a bunch of dependencies in one go (much like OSGi enRoute does with its indexes). As for running directly from the command line. There isn’t an enRoute or bnd plugin for that, the smarts are all in Bndtools I’m afraid. Best Regards, Tim On 31 Jan 2019, at 16:09, Thomas Driessen wrote: Hi Tim, just to clarify (I'm not really used to maven yet): If I want to define a dependency that is used by multiple sub modules, then I MAY put this dependency in the root/parent pom. I also COULD put this dependency in each of the sub module's poms which would have the same effect as the aforementioned approach. I don't need to define the dependecnies in both places. Is this correct? Regarding the running and reloading of applications in bndtools: I don't use Eclipse, therefore I asked if there are maven commands that mimc bndtools' behavior ;) Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 31.01.2019 16:48:54 Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace Hi On 31 Jan 2019, at 15:22, Thomas Driessen via osgi-dev wrote: Hi, I'm currently trying to get used to the new enroute maven workspace layout and now have some questions :) 1) In a bnd workspace I had the central.xml file where I put all the dependencies I wanted in my local maven bnd worspace repository. Where do I put those dependencies now in the maven project workspace? In the dependencies section of the root pom or rather in the dependencies section of a specific module pom? In this case you treat your dependencies just like you would in Maven. If the dependency is used across many modules then you might add it to the dependencyManagement section of the parent pom (to manage the version in a single place), but you will always reference a dependency in the module using it. There is nothing special about this (it really is just vanilla Maven). 2) In a bnd workspace I added the buildtime dependencies of a bundle to its bnd file. What's the best practice now in a maven workspace? Do I add those build time dependencies in the module pom? Again, this is a normal Maven build that follows the same rules as all the Maven examples you can find on the internet. Your module’s compile time and runtime dependencies should be included in its pom, with the appropriate scope. 3) In Eclipse with bndtools installed and when using a bnd workspace layout I am able to press the debug button of a bndrun file and everything is perfectly integrated in the IDE. Additionally, when I change code of bundles that are currently running in an osgi framework, then those are rebuilt and redeployed on the fly. If you do the same thing in your enRoute workspace you’ll get the same behaviour. Is there a way to reproduce a similar behavior only with maven commands and a remote debugger? You can start your application with remote debug enabled (just using the normal JVM debug arguments as you describe below) but I would recommend that you just do the same launching that you’ve been doing from a bad workspace. Right now I'm following the enroute tutorial and every time I changed something in the code I type the following commands: 1 mvn -pl app -am bnd-indexer:index bnd-indexer:index@test-index bnd-resolver:resolve package 2 java -jar -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y .\app\target\app.jar 3 Then I start my remote debugger to attach to the jvm Are there other maven commands that would me allow to skip step 2 and 3? Something like mvn jetty:run for web apps? There isn’t a Maven command for it, but if you look at the Eclipse version of the Running the Application <https://enroute.osgi.org/
Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace
Hi Tim, just to clarify (I'm not really used to maven yet): If I want to define a dependency that is used by multiple sub modules, then I MAY put this dependency in the root/parent pom. I also COULD put this dependency in each of the sub module's poms which would have the same effect as the aforementioned approach. I don't need to define the dependecnies in both places. Is this correct? Regarding the running and reloading of applications in bndtools: I don't use Eclipse, therefore I asked if there are maven commands that mimc bndtools' behavior ;) Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 31.01.2019 16:48:54 Betreff: Re: [osgi-dev] Move from bnd workspace to maven (enroute) workspace Hi On 31 Jan 2019, at 15:22, Thomas Driessen via osgi-dev wrote: Hi, I'm currently trying to get used to the new enroute maven workspace layout and now have some questions :) 1) In a bnd workspace I had the central.xml file where I put all the dependencies I wanted in my local maven bnd worspace repository. Where do I put those dependencies now in the maven project workspace? In the dependencies section of the root pom or rather in the dependencies section of a specific module pom? In this case you treat your dependencies just like you would in Maven. If the dependency is used across many modules then you might add it to the dependencyManagement section of the parent pom (to manage the version in a single place), but you will always reference a dependency in the module using it. There is nothing special about this (it really is just vanilla Maven). 2) In a bnd workspace I added the buildtime dependencies of a bundle to its bnd file. What's the best practice now in a maven workspace? Do I add those build time dependencies in the module pom? Again, this is a normal Maven build that follows the same rules as all the Maven examples you can find on the internet. Your module’s compile time and runtime dependencies should be included in its pom, with the appropriate scope. 3) In Eclipse with bndtools installed and when using a bnd workspace layout I am able to press the debug button of a bndrun file and everything is perfectly integrated in the IDE. Additionally, when I change code of bundles that are currently running in an osgi framework, then those are rebuilt and redeployed on the fly. If you do the same thing in your enRoute workspace you’ll get the same behaviour. Is there a way to reproduce a similar behavior only with maven commands and a remote debugger? You can start your application with remote debug enabled (just using the normal JVM debug arguments as you describe below) but I would recommend that you just do the same launching that you’ve been doing from a bad workspace. Right now I'm following the enroute tutorial and every time I changed something in the code I type the following commands: 1 mvn -pl app -am bnd-indexer:index bnd-indexer:index@test-index bnd-resolver:resolve package 2 java -jar -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y .\app\target\app.jar 3 Then I start my remote debugger to attach to the jvm Are there other maven commands that would me allow to skip step 2 and 3? Something like mvn jetty:run for web apps? There isn’t a Maven command for it, but if you look at the Eclipse version of the Running the Application <https://enroute.osgi.org/tutorial/020-tutorial_qs.html#running-the-application> section in the enRoute tutorials you can see how to run inside the IDE. Best Regards, Tim 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
[osgi-dev] Move from bnd workspace to maven (enroute) workspace
Hi, I'm currently trying to get used to the new enroute maven workspace layout and now have some questions :) 1) In a bnd workspace I had the central.xml file where I put all the dependencies I wanted in my local maven bnd worspace repository. Where do I put those dependencies now in the maven project workspace? In the dependencies section of the root pom or rather in the dependencies section of a specific module pom? 2) In a bnd workspace I added the buildtime dependencies of a bundle to its bnd file. What's the best practice now in a maven workspace? Do I add those build time dependencies in the module pom? 3) In Eclipse with bndtools installed and when using a bnd workspace layout I am able to press the debug button of a bndrun file and everything is perfectly integrated in the IDE. Additionally, when I change code of bundles that are currently running in an osgi framework, then those are rebuilt and redeployed on the fly. Is there a way to reproduce a similar behavior only with maven commands and a remote debugger? Right now I'm following the enroute tutorial and every time I changed something in the code I type the following commands: 1 mvn -pl app -am bnd-indexer:index bnd-indexer:index@test-index bnd-resolver:resolve package 2 java -jar -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y .\app\target\app.jar 3 Then I start my remote debugger to attach to the jvm Are there other maven commands that would me allow to skip step 2 and 3? Something like mvn jetty:run for web apps? Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Scanning classes at runtime
Thanks Tim! That's exactly what I hoped for :) Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" ; "OSGi Developer Mail List" Gesendet: 23.01.2019 17:48:43 Betreff: Re: [osgi-dev] Scanning classes at runtime Hi, You can optimise this pretty heavily by using the bundle wirings to look for bundles which are wired to the same API packages as you (the one(s) that contain the relevant interface/supertype/annotation). This way you can avoid scanning bundles which can’t possibly contain relevant types. Best Regards, Tim On 23 Jan 2019, at 16:10, Thomas Driessen via osgi-dev wrote: Hi, for a project of mine I need to mimic the behavior of a ServletContainerInitializer [1], but with the dynamism of OSGi in mind. Therefore, I need to be able to find all classes that implement/extend a specific class or are annotated with a specific annotation at runtime. Is there a better way to do so that I'm not aware of than to scan each class of every bundle? Are there maybe framework hooks that would help me accomplish this? I'm thankful for every hint you can provide. Kind regards, Thomas [1] https://docs.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html ___ 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
[osgi-dev] Scanning classes at runtime
Hi, for a project of mine I need to mimic the behavior of a ServletContainerInitializer [1], but with the dynamism of OSGi in mind. Therefore, I need to be able to find all classes that implement/extend a specific class or are annotated with a specific annotation at runtime. Is there a better way to do so that I'm not aware of than to scan each class of every bundle? Are there maybe framework hooks that would help me accomplish this? I'm thankful for every hint you can provide. Kind regards, Thomas [1] https://docs.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Vaadin flow works in bnd workspace, fails in enRoute project
Hi Tim, thanks for the feedback and opening the issue :) Thomas -- Originalnachricht -- Von: "Tim Ward" An: "Thomas Driessen" Cc: "Paul F Fraser" ; "OSGi Developer Mail List" Gesendet: 16.01.2019 12:51:24 Betreff: Re: [osgi-dev] Vaadin flow works in bnd workspace, fails in enRoute project Hi Thomas, I'm not sure if this can be done in a better way. The resource registration could definitely be changed to use the Http Service Whiteboard relatively easily. The effective result is that Vaadin would offer a service advertising the resources at the correct locations with the relevant mappings provided by a ServletContextHelper (much like the current “Delegate” does). Overall it may be the case that Vaadin wishes to migrate away from this model as it does seem to mirror the resource registration model from the Http Service Whiteboard. The only other place that would need to change is in the tests <https://github.com/vaadin/flow/blob/031d9fe8b7fe951658e0369f2a382a67198e3bef/flow-tests/test-root-context/src/main/java/com/vaadin/flow/osgi/Activator.java> and that seems to be a relatively simple swap to register the servlets as services rather than using a service tracker. Regarding the packaging bug of felix.jetty: Is there an older version of the bundle where this bug is not included, because I remember successfully using felix.jetty for Vaadin once? The requirement from Vaadin is “effective active” and so won’t prevent the bundles from resolving in an OSGi framework (i.e. this would probably work fine at runtime). The requirement is almost certainly generated automatically by bnd because there is a DS component injected with the service. Is there a bug repot filed for this bug? Otherwise we should do that. https://issues.apache.org/jira/browse/FELIX-6029 Tim On 16 Jan 2019, at 11:34, Thomas Driessen wrote: Hi Tim, hi Paul, I think they had some trouble with resources in Vaadin in OSGi (Vaadin makes some specific assumptions oabout the file layout I think) and therefore implemented their own ResourceTracker (https://github.com/vaadin/flow/blob/master/flow-osgi/src/main/java/com/vaadin/flow/osgi/support/VaadinResourceTrackerComponent.java). I'm not sure if this can be done in a better way. Regarding the packaging bug of felix.jetty: Is there an older version of the bundle where this bug is not included, because I remember successfully using felix.jetty for Vaadin once? Is there a bug repot filed for this bug? Otherwise we should do that. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward via osgi-dev" An: "Paul F Fraser" ; "OSGi Developer Mail List" Gesendet: 16.01.2019 12:20:46 Betreff: Re: [osgi-dev] Vaadin flow works in bnd workspace, fails in enRoute project Hi Paul, The error you’re seeing is a resolution failure because the "com.vaadin.flow.osgi version=1.2.3” bundle has a requirement in the “osgi.service” namespace for the service with interface “org.osgi.service.http.HttpService”. This basically says that the Vaadin flow bundle is trying to use the HttpService in some way, and therefore the exported application needs to include a bundle which provides the HttpService. Now in fact the Felix Http Jetty implementation used in OSGi enRoute *does* provide this service, however it is missing the metadata from the manifest saying that it provides this service. This is a packaging bug in the Felix Jetty bundle, and is why the resolve fails. There is a further question, which is why on earth the Vaadin Flow bundle is using the HttpService? It would be better and easier for them to use the Http Whiteboard than to use the old HttpService to provide content… Best Regards, Tim On 16 Jan 2019, at 04:45, Paul F Fraser via osgi-dev wrote: Hi, Following the process below I have sucessfully managed to run a vaadin flow bundle in OSGi. Create vaadin flow bundle in enroute maven project. https://github.com/QNENet/enRouteQNEFlow-0.0.1Use flow bundle in bnd workspace and export as jar, which of course contains all necessary dependencies.java -jar flow.jar works at localhost:8080 https://s3-ap-southeast-2.amazonaws.com/qnenet/vaadinFlow/flow.jar create application from enRoute archetypeAdd all dependencies as used in exported bnd workspace flow.jarenRoute app fails. [ERROR] Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:4.1.0:export (default) on project flow-app: Unable to resolve <>: missing requirement osgi.identity;filter:='(osgi.identity=com.vaadin.flow.osgi)' [caused by: Unable to resolve com.vaadin.flow.osgi version=1.2.3: missing requirement osgi.service;filter:='(objectClass=org.osgi.service.http.HttpService)';effective:='active'] -> [Help 1] Any assistance to solve this last (?) hurdle to having an OSGi work environment for vaadin flow development would be most appreciated.
Re: [osgi-dev] Vaadin flow works in bnd workspace, fails in enRoute project
Hi Tim, hi Paul, I think they had some trouble with resources in Vaadin in OSGi (Vaadin makes some specific assumptions oabout the file layout I think) and therefore implemented their own ResourceTracker (https://github.com/vaadin/flow/blob/master/flow-osgi/src/main/java/com/vaadin/flow/osgi/support/VaadinResourceTrackerComponent.java). I'm not sure if this can be done in a better way. Regarding the packaging bug of felix.jetty: Is there an older version of the bundle where this bug is not included, because I remember successfully using felix.jetty for Vaadin once? Is there a bug repot filed for this bug? Otherwise we should do that. Kind regards, Thomas -- Originalnachricht -- Von: "Tim Ward via osgi-dev" An: "Paul F Fraser" ; "OSGi Developer Mail List" Gesendet: 16.01.2019 12:20:46 Betreff: Re: [osgi-dev] Vaadin flow works in bnd workspace, fails in enRoute project Hi Paul, The error you’re seeing is a resolution failure because the "com.vaadin.flow.osgi version=1.2.3” bundle has a requirement in the “osgi.service” namespace for the service with interface “org.osgi.service.http.HttpService”. This basically says that the Vaadin flow bundle is trying to use the HttpService in some way, and therefore the exported application needs to include a bundle which provides the HttpService. Now in fact the Felix Http Jetty implementation used in OSGi enRoute *does* provide this service, however it is missing the metadata from the manifest saying that it provides this service. This is a packaging bug in the Felix Jetty bundle, and is why the resolve fails. There is a further question, which is why on earth the Vaadin Flow bundle is using the HttpService? It would be better and easier for them to use the Http Whiteboard than to use the old HttpService to provide content… Best Regards, Tim On 16 Jan 2019, at 04:45, Paul F Fraser via osgi-dev wrote: Hi, Following the process below I have sucessfully managed to run a vaadin flow bundle in OSGi. Create vaadin flow bundle in enroute maven project. https://github.com/QNENet/enRouteQNEFlow-0.0.1Use flow bundle in bnd workspace and export as jar, which of course contains all necessary dependencies.java -jar flow.jar works at localhost:8080 https://s3-ap-southeast-2.amazonaws.com/qnenet/vaadinFlow/flow.jar create application from enRoute archetypeAdd all dependencies as used in exported bnd workspace flow.jarenRoute app fails. [ERROR] Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:4.1.0:export (default) on project flow-app: Unable to resolve <>: missing requirement osgi.identity;filter:='(osgi.identity=com.vaadin.flow.osgi)' [caused by: Unable to resolve com.vaadin.flow.osgi version=1.2.3: missing requirement osgi.service;filter:='(objectClass=org.osgi.service.http.HttpService)';effective:='active'] -> [Help 1] Any assistance to solve this last (?) hurdle to having an OSGi work environment for vaadin flow development would be most appreciated. Thanks Paul Fraser ___ 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
[osgi-dev] No service events for an embedded OSGi Framework?
Hi, I'm trying to setup an OSGi framework instance (Felix) then to install two bundles and finally getting a reference to a ComponentFactory inside the framework via a ServiceListener. No Exceptions are thrown but my ServiceListener ist not getting any events. You can have a look at the code here: https://github.com/Sandared/jmh-benchmarks/blob/master/benchmarks/src/main/java/io/jatoms/jmh/OSGiBenchmark2.java Or If you want to execute it and play with it you can run it here: https://gitpod.io/#https://github.com/Sandared/jmh-benchmarks/blob/master/benchmarks/src/main/java/io/jatoms/jmh/OSGiBenchmark2.java just type the following commands into the terminal: cd benchmarks mvn clean install java -jar target/benchmarks.jar I also tried to acquire the service directly by starting the bundles, then wait a second and then calling bundleContext.getServiceReference(ComponentFactory.class). But when I tried to turn this reference into a service via ComponentFactory factory = bundleContext.getService(ref); I get a ClassCastException stating that Felix SCR's ComponentFactoryImplementation cannot be cast to ComponentFactory... which doesn't make much sense to me, as the ComponentFactoryImplementation implements ComponentFactory. Am I doing something fundamentally wrong? Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] JMH within OSGi
Hi, I want to benchmark a method within a running OSGi instance. There are three services A, B, C where A references B and B references C. Calling a method on A transitively calls a method on B which calls a method on C. A, B and C are configured at runtime through ConfigurationAdmin and I want to benchmark the method called on A when everything is set up. I wanted to use JMH but have no clue on how to force JMH to use the instance of A created by OSGi? Is this even possible? If not, how would you benchmark something within OSGi? Does anyone have experience with JMH in the context of OSGi and could kindly give me some advice? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Typos/Errata in R7 compendium
Hi, what do I have to do to report typos/errata in the compendium spec? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] enRoute Quickstart Maven Build Failure
Thank you so much! -- Originalnachricht -- Von: "Tim Ward" <tim.w...@paremus.com> An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 08.05.2018 12:08:44 Betreff: Re: [osgi-dev] enRoute Quickstart Maven Build Failure The enRoute project has now been updated to use the released R7 API as well as released versions of Declarative Services, Config Admin, Http Whiteboard, JPA Service, Transaction Control, and Configurator. The one remaining snapshot implementation is the JAX-RS whiteboard, which is not yet released Best Regards, Tim On 6 May 2018, at 18:13, Tim Ward <tim.w...@paremus.com> wrote: The Aries JPA snapshots have probably been deleted as Aries JPA 2.7.0 was released last week. The OSGi R7 API is now also released, so the enRoute indexes and archetypes will need to be updated for that too. There are likely to be other Apache projects doing the same thing as part of the R7 RI release process. Feel free to create a PR, or I should be able to update this on Tuesday. Tim Sent from my iPhone On 6 May 2018, at 12:35, Thomas Driessen via osgi-dev <osgi-dev@mail.osgi.org> wrote: Hi, I just tried to do the quickstart tutorial. I cloned the repository and run the command "mvn verify", but the buil failed with the following message: [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] quickstart [pom] [INFO] rest [jar] [INFO] app [jar] [INFO] [INFO] --< org.osgi.enroute.examples.quickstart:quickstart >--- [INFO] Building quickstart 0.0.1-SNAPSHOT [1/3] [INFO] [ pom ]- [INFO] [INFO] -< org.osgi.enroute.examples.quickstart:rest >-- [INFO] Building rest 0.0.1-SNAPSHOT [2/3] [INFO] [ jar ]- [WARNING] The POM for org.apache.aries.jpa.javax.persistence:javax.persistence_2.1:jar:2.7.0-SNAPSHOT is missing, no dependency information available [INFO] [INFO] Reactor Summary: [INFO] [INFO] quickstart 0.0.1-SNAPSHOT .. SUCCESS [ 0.028 s] [INFO] rest ... FAILURE [ 0.413 s] [INFO] app 0.0.1-SNAPSHOT . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.709 s [INFO] Finished at: 2018-05-06T13:33:50+02:00 [INFO] [ERROR] Failed to execute goal on project rest: Could not resolve dependencies for project org.osgi.enroute.examples.quickstart:rest:jar:0.0.1-SNAPSHOT: Failure to find org.apache.aries.jpa.javax.persistence:javax.persistence_2.1:jar:2.7.0-SNAPSHOT in https://oss.sonatype.org/content/groups/osgi was cached in the local repository, resolution will not be reattempted until the update interval of OSGi has elapsed or updates are forced -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :rest 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
[osgi-dev] enRoute Quickstart Maven Build Failure
Hi, I just tried to do the quickstart tutorial. I cloned the repository and run the command "mvn verify", but the buil failed with the following message: [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] quickstart [pom] [INFO] rest [jar] [INFO] app [jar] [INFO] [INFO] --< org.osgi.enroute.examples.quickstart:quickstart >--- [INFO] Building quickstart 0.0.1-SNAPSHOT [1/3] [INFO] [ pom ]- [INFO] [INFO] -< org.osgi.enroute.examples.quickstart:rest >-- [INFO] Building rest 0.0.1-SNAPSHOT [2/3] [INFO] [ jar ]- [WARNING] The POM for org.apache.aries.jpa.javax.persistence:javax.persistence_2.1:jar:2.7.0-SNAPSHOT is missing, no dependency information available [INFO] [INFO] Reactor Summary: [INFO] [INFO] quickstart 0.0.1-SNAPSHOT .. SUCCESS [ 0.028 s] [INFO] rest ... FAILURE [ 0.413 s] [INFO] app 0.0.1-SNAPSHOT . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.709 s [INFO] Finished at: 2018-05-06T13:33:50+02:00 [INFO] [ERROR] Failed to execute goal on project rest: Could not resolve dependencies for project org.osgi.enroute.examples.quickstart:rest:jar:0.0.1-SNAPSHOT: Failure to find org.apache.aries.jpa.javax.persistence:javax.persistence_2.1:jar:2.7.0-SNAPSHOT in https://oss.sonatype.org/content/groups/osgi was cached in the local repository, resolution will not be reattempted until the update interval of OSGi has elapsed or updates are forced -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :rest Kind regards, Thomas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Vaadin 10 OSGi Support
Thanks Paul and Timothy :) Maybe in Vaadin 10 they offer better OSGi support than in Vaadin 8. This would be a really nic web UI solution for people that want to stay in the Java world. Thomas -- Originalnachricht -- Von: "Paul F Fraser via osgi-dev" <osgi-dev@mail.osgi.org> An: osgi-dev@mail.osgi.org Gesendet: 23.03.2018 10:44:16 Betreff: Re: [osgi-dev] Vaadin 10 OSGi Support The beta4 release (today) has issue 455 as a known limitation. Someone might be listening. I have added a comment and nice to see Timothy J has also commented. Paul On 22/03/2018 11:07 PM, Thomas Driessen via osgi-dev wrote: Hi, as some people already wrote about Vaadin in OSGi applications in this mailinglist, maybe those are interested in "upvoting" the "OSGi support and test" issue of the new Vaadin 10. https://github.com/vaadin/flow/issues/455 Maybe this gets us a better OSGi support in Vaadin 10 sooner. Kind regards, Thomas ___ OSGi Developer Mail List osgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Vaadin 10 OSGi Support
Hi, as some people already wrote about Vaadin in OSGi applications in this mailinglist, maybe those are interested in "upvoting" the "OSGi support and test" issue of the new Vaadin 10. https://github.com/vaadin/flow/issues/455 Maybe this gets us a better OSGi support in Vaadin 10 sooner. Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] DS Reference injection order
Thanks a lot for the clarifying answers!
I think I got it now!
-- Originalnachricht --
Von: "Peter Kriens" <peter.kri...@aqute.biz>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Cc: "BJ Hargrave" <hargr...@us.ibm.com>; "Tim Ward"
<tim.w...@paremus.com>
Gesendet: 02.02.2018 10:54:34
Betreff: Re: [osgi-dev] DS Reference injection order
In this case you do not have such guarantee about injection. And it
won’t be necessary since you could just make them mandatory references.
You need to distinguish two things:
1) The existence of or the state of the system
2) Injection
If you have an optional dependence then all bets are off because there
can always be a delay between the events. Only mandatory references
give you any guarantee here. For example, to handle cyclic dependencies
DS can delay injection of optional dependencies although the service is
present.
What you could do is to lookup the services through the component
context, they should be there.
So what you can observe through the AggregateState service is not by
definition observable through optional services. A bit like relativity
theory.
Kind regards,
Peter Kriens
On 2 Feb 2018, at 10:35, Thomas Driessen via osgi-dev
<osgi-dev@mail.osgi.org> wrote:
Hi,
thanks for all those answers and sorry for my late response.
Maybe I have been a little bit too imprecise.
The reason I asked, was that I found this article by Peter Kriens
about an AggregateState:
http://aqute.biz/2017/04/24/aggregate-state.html
I wrote such a service and only was wondering afterwards if this
really works all the times or if I just hit a lucky punch and it
worked the few times I tested it. Or if I got Peter's intentions
completely wrong and did something AggregateState was not meant for.
So what I do is writing a component as described in the article like
this:
@Component
public class MyComp{
@Reference(target="(&(x.prop=x)(y.prop=y))")
private AggregateState state;
@Reference(target="(x.prop=x)")
private volatile X x;
@Reference(target="(y.prop=y)")
private volatile Y y;
@Activate
private void activate(){
doSomethingWithXandY();
}
}
So even if my AggregateState is satisfied, which means that there are
fitting, activated services for X and Y, can I rest assured that X and
Y are injected BEFORE activate() is called? Because my understanding
was that X and Y might still be null and MyComp is nevertheless
eligible for activation.
Kind regards,
Thomas
-- Originalnachricht --
Von: "BJ Hargrave" <hargr...@us.ibm.com>
An: tim.w...@paremus.com; osgi-dev@mail.osgi.org
Cc: osgi-dev@mail.osgi.org; thomas.driessen...@gmail.com
Gesendet: 31.01.2018 15:40:53
Betreff: Re: [osgi-dev] DS Reference injection order
Tim correctly cites the spec regarding the order SCR must process the
elements in the XML. Since you are using annotations,
there is one more thing to know. The javadoc for the Reference
annotation states:
In the generated Component Description for a component, the
references must be ordered in ascending lexicographical order (using
String.compareTo ) of the reference names.
So you can control the order of the reference elements in the xml by
the names of the references.
The order of processing reference can be useful if you are using
method injection and a method needs to use a previously injected
reference. But since you examples show field injection, your
component cannot not really observe the order of injection.
With 'volatile' you have a dynamic reference which can be updated at
any time, so there is no order with respect to other reference.
--
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: Tim Ward via osgi-dev <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: Thomas Driessen <thomas.driessen...@gmail.com>, OSGi Developer
Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] DS Reference injection order
Date: Wed, Jan 31, 2018 6:43 AM
Firstly - why do you need to rely on this? It sounds like very
fragile code to me and you should probably consider rewriting so
that you don’t need to care. However...
Section 112.5.7 of the compendium says that:
When binding services, the references are processed in the order in
which they are specified in the component description. That is,
target services from the first specified reference are bound before
services from the next specified reference.
A static optional service will not be set if it is not satisfied, or
will if it is. A dynamic optional service will behave the same way,
but it may be unset a
Re: [osgi-dev] DS Reference injection order
Hi,
thanks for all those answers and sorry for my late response.
Maybe I have been a little bit too imprecise.
The reason I asked, was that I found this article by Peter Kriens about
an AggregateState: http://aqute.biz/2017/04/24/aggregate-state.html
I wrote such a service and only was wondering afterwards if this really
works all the times or if I just hit a lucky punch and it worked the few
times I tested it. Or if I got Peter's intentions completely wrong and
did something AggregateState was not meant for.
So what I do is writing a component as described in the article like
this:
@Component
public class MyComp{
@Reference(target="(&(x.prop=x)(y.prop=y))")
private AggregateState state;
@Reference(target="(x.prop=x)")
private volatile X x;
@Reference(target="(y.prop=y)")
private volatile Y y;
@Activate
private void activate(){
doSomethingWithXandY();
}
}
So even if my AggregateState is satisfied, which means that there are
fitting, activated services for X and Y, can I rest assured that X and Y
are injected BEFORE activate() is called? Because my understanding was
that X and Y might still be null and MyComp is nevertheless eligible for
activation.
Kind regards,
Thomas
-- Originalnachricht --
Von: "BJ Hargrave" <hargr...@us.ibm.com>
An: tim.w...@paremus.com; osgi-dev@mail.osgi.org
Cc: osgi-dev@mail.osgi.org; thomas.driessen...@gmail.com
Gesendet: 31.01.2018 15:40:53
Betreff: Re: [osgi-dev] DS Reference injection order
Tim correctly cites the spec regarding the order SCR must process the
elements in the XML. Since you are using annotations, there
is one more thing to know. The javadoc for the Reference annotation
states:
In the generated Component Description for a component, the references
must be ordered in ascending lexicographical order (using
String.compareTo ) of the reference names.
So you can control the order of the reference elements in the xml by
the names of the references.
The order of processing reference can be useful if you are using method
injection and a method needs to use a previously injected reference.
But since you examples show field injection, your component cannot not
really observe the order of injection.
With 'volatile' you have a dynamic reference which can be updated at
any time, so there is no order with respect to other reference.
--
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: Tim Ward via osgi-dev <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: Thomas Driessen <thomas.driessen...@gmail.com>, OSGi Developer
Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] DS Reference injection order
Date: Wed, Jan 31, 2018 6:43 AM
Firstly - why do you need to rely on this? It sounds like very fragile
code to me and you should probably consider rewriting so that you
don’t need to care. However...
Section 112.5.7 of the compendium says that:
When binding services, the references are processed in the order in
which they are specified in the component description. That is,
target services from the first specified reference are bound before
services from the next specified reference.
A static optional service will not be set if it is not satisfied, or
will if it is. A dynamic optional service will behave the same way,
but it may be unset and reset many times afterwards on other threads.
Dynamic services should always be treated with care, whether they are
optional or not.
Tim
On 31 Jan 2018, at 10:50, Thomas Driessen via osgi-dev
<osgi-dev@mail.osgi.org> wrote:
Hi,
I searched the compendium spec but didn't find what I was looking
for.
If I have a DS with multiple references to other DS
@Component
class Example1{
@Reference
Example2 e2
@Reference
Example3 e3
}
in which order are the references injected? Is there even a
deterministic order?
In the above example both references are static/mandatory. What
happens if I have a static/mandatory and a dynamic/optional one like
this:
@Component
class Example1{
@Reference
Example2 e2
@Reference
volatile Example3 e3
}
Kind regards,
Thomas
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev=DwMFaQ=jf_iaSHvJObTbx-siA1ZOg=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms=P8DWwyvfdkJmQulD35LW62YOdKbDVw6eIWSALp1HIbI=U70U3kBVjtwoTlXKCafEOLUaXN8uM6uEth9KO1zjavY=>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.o
[osgi-dev] DS Reference injection order
Hi,
I searched the compendium spec but didn't find what I was looking for.
If I have a DS with multiple references to other DS
@Component
class Example1{
@Reference
Example2 e2
@Reference
Example3 e3
}
in which order are the references injected? Is there even a
deterministic order?
In the above example both references are static/mandatory. What happens
if I have a static/mandatory and a dynamic/optional one like this:
@Component
class Example1{
@Reference
Example2 e2
@Reference
volatile Example3 e3
}
Kind regards,
Thomas___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Vaadin 8.2.1 in OSGi
Hi,
if someone is still interested in using Vaadin 8 in OSGi: I've created
an integration that enables the developer to use a declared Vaadin UI as
a Declarative Service.
The code for this integration can be found here:
https://github.com/Sandared/vaadin8integration
All a developer has to do now is to annotate the class extending UI with
@Component and add a path under which it should be registered:
@Component(service = UI.class,
HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/test")
public class VaadinUI extends UI{
.
}
Kind regards,
Thomas___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Fwd: Fwd: Vaadin 8.2 in OSGi: ClassNotFound
Hi Paul, right now I'm using a mixture of Vaadin 8.2.1 bundles, the enroute code and a little bit of current vaadin bugfixing code ;) If you start all vaadin bundles (com.vaadin.shared, com.vaadin.server, com.vaadin.external.gentyref, com.vaadin.client-compiled and com.vaadin.themes) vaadin will take care of registering all needed resources, which has been done before by VaadinResource.java in the enroute example. The rest is done by an adopted version of Peter Kriens' original enRoute Vaadin example and can be found in my GitHub repository (https://github.com/Sandared/vaadin8osgi) if you are interested. Right now I've only set up a minimal example and have not yet worked with Vaadin perspective only with Bndtools. Until now I didn't have to compile widgets or themes... but I'm new to Vaadin, maybe I'm missing something here? I'm glad for every advice you can give me :) I think I will continue to explore Vaadin 8 in OSGi within the next week. Kind regards, Thomas -- Originalnachricht -- Von: "Paul F Fraser via osgi-dev" <osgi-dev@mail.osgi.org> An: "Thomas Driessen" <thomas.dries...@ds-lab.org>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 18.01.2018 19:58:18 Betreff: Re: [osgi-dev] Fwd: Fwd: Vaadin 8.2 in OSGi: ClassNotFound On 19/01/2018 2:15 AM, Thomas Driessen wrote: Hello, just for other people that are trying to get Vaadin 8 to work within an OSGi environment: Hi Thomas, Good to hear that you are on the way. Are you now using all Vaadin OSGi bundles and none of the enRoute bundles? Are you developing in the Vaadin perspective or Bndtools? Is the compile of widgets and themes now automatic? Paul___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Fwd: Fwd: Vaadin 8.2 in OSGi: ClassNotFound
Hello, just for other people that are trying to get Vaadin 8 to work within an OSGi environment: The ClassNotFoundException for AppWidgetset can be ignored. If Vaadin does not find this class it falls back to the default widgetset. The lost connection seems to stem from false urlPatterns for UIs. After the initial load of an UI that is registered under localhost:8080/test Vaadin sends XHR requests for each interaction (e.g. resizing, clicks, etc.) to the server. The path for these requests are always in form of /UIDL/?... In our case this would be localhost:8080/test/UIDL. If there is no servlet registered for this path, the Vaadin client receives a malformed response and displays a popup that says: Connection lost... . I fixed this issue in my example application by letting VaadinApplicationHandler change all urlPatterns of UIs to /* The VaadinResource class of the original enRoute example is not needed anymore, as Vaadin 8 takes care of registering its resources (Widgetsets/Themes/other stuff) itself as long as its bundles are started in the right order! The first bundle to start must be vaadin-shared. Kind regards, Thomas -- Originalnachricht -- Von: "Thomas Driessen" <thomas.dries...@ds-lab.org> An: "Matthews, Kevin" <kevin.matth...@firstdata.com>; "Paul F Fraser" <pa...@a2zliving.com>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 17.01.2018 18:07:27 Betreff: Re[2]: [osgi-dev] Fwd: Fwd: Vaadin 8.2 in OSGi: ClassNotFound Hello Paul, thank you for the hint to the enroute Vaadin exmaple. My steps so far: I tried to merge Peter's code with the current work of Vaadin regarding their OSGi compatibility [1] and got Vaadin 8.2.1 to at least show the UI once. However, after the initial request it looses the connection to the server and isn't working anymore :( From Peter's code I removed the VaadinResources class, because this is done now by Vaadin, at least if you start the bundles in the right order [2]. They are using static method calls between bundles and if the vaadin-shared bundle hasn't been started before the others there will be an exception in the @Activate method of some of their other services -.- Right now I'm dealing with a ClassNotFoundException as Vaadin can not find an AppWidgetset? Additionally the reconection issues seems to originate from some XHR configuration issues. I've set up a sample workspace [3], so that anyone who is interested can investigate those issues too. Kind regards, Thomas [1] https://github.com/mmerruko/framework/commit/ce52b21290ca5790b1b193876a2d000d7d1d970e [2] https://github.com/vaadin/framework/issues/10526 [3] https://github.com/Sandared/vaadin8osgi.git -- Originalnachricht -- Von: "Matthews, Kevin via osgi-dev" <osgi-dev@mail.osgi.org> An: "Paul F Fraser" <pa...@a2zliving.com>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 17.01.2018 00:29:53 Betreff: Re: [osgi-dev] Fwd: Fwd: Vaadin 8.2 in OSGi: ClassNotFound I apologize to send this request on this thread but I had sent this topic on a separate email thread and got no response. A simple question. Does anyone know or had done production deployment model using bnd osgi services. What’s the best practice to deploy these bundles to a standalone server as runnable jar or to docker containers using apache ace. From:osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Paul F Fraser via osgi-dev Sent: Tuesday, January 16, 2018 6:00 PM To: OSGi Developer Mail List Subject: [osgi-dev] Fwd: Fwd: Vaadin 8.2 in OSGi: ClassNotFound Forwarded with permission-- Forwarded Message Subject: Fwd: [osgi-dev] Vaadin 8.2 in OSGi: ClassNotFound Date: Tue, 16 Jan 2018 22:24:18 +0100 From: Pierre De Rop <pierre.de...@gmail.com> <mailto:pierre.de...@gmail.com> To: Paul F Fraser <pa...@a2zliving.com> <mailto:pa...@a2zliving.com> Hello Paul; I'm Pierre, one of the apache felix dependency manager committer; so, I just wanted to comment the following part in your mail: "Also, I have given up using Bndtools with Oxygen as there seems to be an intermittent problem that causes Eclipse to not load the workspace and once it happens I have had to reinstall Eclipse. So I have gone back to Neon and so far the problem has not re-occurred." Indeed, I think I came across the same issue you described; and when my eclipse Oxygen (and bndtools 3.5.0) can't restart, then the problem is resolved using the "-clean" eclipse option (see [1]]) hope this helps; kind regards /Pierre [1] https://stackoverflow.com/questions/2030064/how-to-run-eclipse-in-clean-mode-and-what-happens-if-we-do-so <https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_2030064_
[osgi-dev] Vaadin 8.2 in OSGi: ClassNotFound
Hi,
I also asked this question in the Vaadin forum. I just thought that maybe
another OSGi developer already had the same problems and am therefore
posting this question here too:
I just tried to run a simple Hello World Vaadin app in an OSGi environment
(I don't use Karaf) and ended up with a ClassNotFoundException:
Caused by: java.lang.ClassNotFoundException: de.unia.smds.maf.web.gui.MyUI
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at
org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:132)
at java.lang.ClassLoader.loadClass(Unknown Source)
at
com.vaadin.server.ServletPortletHelper.verifyUIClass(ServletPortletHelper.java:72)
My Setup is as follows:
- I'm using BndTools 3.5 in Eclipse Oxygen
- From Maven I get the following dependencies:
com.vaadin
vaadin-osgi-integration
8.2.1
com.vaadin
vaadin-server
8.2.1
com.vaadin
vaadin-themes
8.2.1
com.vaadin
vaadin-client-compiled
8.2.1
- I created a new Bnd OSGi project and configured my Buildpath like this:
-buildpath: \
org.eclipse.xtend.lib,\
org.eclipse.xtend.lib.macro,\
org.eclipse.xtext.xbase.lib,\
com.google.guava;version=18.0,\
osgi.enroute.base.api,\
com.vaadin.server;version=8.2,\
org.jsoup;version=1.8,\
com.vaadin.external.gentyref;version=1.2,\
com.vaadin.client-compiled;version=8.2,\
com.vaadin.shared;version=8.2,\
com.vaadin.themes;version=8.2
- Then I created the two classes MyUI and MyUIServlet
public class MyUI extends UI {
@Override
protected void init(final VaadinRequest request) {
Label _label = new Label("Hello World");
this.setContent(_label);
}
}
@Component(service = VaadinServlet.class, property = {
(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/hello") })
@VaadinServletConfiguration(ui = MyUI.class, productionMode = false)
@SuppressWarnings("all")
public class MyUIServlet extends VaadinServlet {
}
When I try to access the UI at http://localhost:8080/hello I receive the
above mentioned exception.
Did anyone had similar problems?
As I am using the official OSGi integration from Vaadin I thought that this
would work out of the box.
Am I missing something here?
Kind regards,
Thomas
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] OSGi Push Streams
Hi, where can I find the current reference implementation for the upcoming OSGi Push Streams? I've seen some talks about it, but could not find it anywhere. Apache Aries had them in their repository, but the last update has been last year. Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Some questions
Thanks a lot for this quick, in-depth answers :) 2017-09-28 10:01 GMT+02:00 Thomas Driessen <thomas.driessen...@gmail.com>: > > -- Forwarded message -- > From: Timothy Ward <tim.w...@paremus.com> > Date: 2017-09-27 16:05 GMT+02:00 > Subject: Re: [osgi-dev] Some questions > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Cc: Thomas Driessen <thomas.driessen...@gmail.com> > > > Some more responses inline: > > On 27 Sep 2017, at 14:29, Neil Bartlett <njbartl...@gmail.com> wrote: > > > On 27 Sep 2017, at 14:14, Thomas Driessen <thomas.driessen...@gmail.com> > wrote: > > Hi, > > after working for some time with OSGi now I have a bunch of questions that > I couldn't find a satisfying answer for yet. Maybe some of you can help me > to clarify those: > > 1) Why is OSGi using annotations as configuration objects? > > > Two reasons: > 1. Annotation fields can have defaults specified directly. > 2. Annotation types are limited to primitives, Strings (and arrays > thereof) which map neatly to the kinds of data that can be represented in > config files. > > >- It is really strange that within an @Activate method the >annotation-config object is null but I still can call the methods defined >on it. > > The default toString of the Felix SCR configuration proxies used to be > null. This proved very confusing in the debugger, and I believe that it has > been changed in recent releases. > > >- Wouldn't DTOs be the better choice? Maybe in combination with an >annotation and annotation processor that assures the DTO consists only of >primitives, arrays of primitives or other DTOs. Configuration values like “ >component.name" could be represented as values of a ConfigurationDTO >containing a ComponentDTO which has a name variable. > > DTOs don’t give a good way of providing defaults, and they encourage > people to believe that the configurations can contain rich types (you > mention your DTO containing DTOs). Configuration Admin configurations are > flat, and Annotations give a really good mapping for them. The decision was > therefore to use the type which is well suited, rather than building a lot > of infrastructure to restrict a type which isn’t. > > 2) Why are the OSGi DS annotations RetentionPolicy.CLASS? > > > > Because runtime retention would create a runtime dependency, i.e. an > Import-Package for the annotation type package. That in turn would prevent > resolution of a bundle if the annotations were not present at runtime. > > > Also the annotations are not used by the Service Component Runtime, only > the XML is used. Having runtime retention would confuse what is otherwise a > clear statement about the source of truth. > > > >- Sometimes it would be nice to find the annotated methods/fields at >runtime, e.g. at testing in a non-OSGi environment > > You could just read the XML descriptor - it has a well defined schema. > > 3) Why are the OSGi DS annotations not inherited? > > > > You might be using bnd (or an alternative tool) to process the class files > of a bundle after the Java source has been compiled. When doing this it is > not necessary to have the superclasses visible, and so bnd would not know > about inherited annotations. So if bnd looks for inherited annotations when > available, it could produce different results depending on how it is > invoked. > > In practice, most people use a tool like Bndtools or bnd-maven-plugin > which puts the same JARs on the bnd classpath that were used for > compilation, and you obviously DO need superclasses visible for > compilation, so you can just turn on the option to use inheritance. > > >- I know that there is a option in bnd for this, but I’m not sure if >or when it is save to use this option, as I'm not really sure about the >implications this might have. > > This option is safe if all of the class hierarchy is contained within a > single bundle. It is not safe if the inheritance tree spans different > bundles. The annotations are processed at build time based on the > compilation class path but the runtime behaviour is determined by the way > in which your bundles wire in the OSGi framework. Obviously if your bundle > wires differently at runtime then the generated XML may be broken (for > example if an injected private field is renamed between micro versions). > > >- Are there any best practices/patterns for the cases where I have >mutliple implementations of one service and all of them share code that >should be called e.g. during activation or deactivation? > > Goo
[osgi-dev] Some questions
Hi, after working for some time with OSGi now I have a bunch of questions that I couldn't find a satisfying answer for yet. Maybe some of you can help me to clarify those: 1) Why is OSGi using annotations as configuration objects? It is really strange that within an @Activate method the annotation-config object is null but I still can call the methods defined on it.Wouldn't DTOs be the better choice? Maybe in combination with an annotation and annotation processor that assures the DTO consists only of primitives, arrays of primitives or other DTOs. Configuration values like "component.name" could be represented as values of a ConfigurationDTO containing a ComponentDTO which has a name variable. 2) Why are the OSGi DS annotations RetentionPolicy.CLASS? Sometimes it would be nice to find the annotated methods/fields at runtime, e.g. at testing in a non-OSGi environment 3) Why are the OSGi DS annotations not inherited? I know that there is a option in bnd for this, but I'm not sure if or when it is save to use this option, as I'm not really sure about the implications this might have.Are there any best practices/patterns for the cases where I have mutliple implementations of one service and all of them share code that should be called e.g. during activation or deactivation? Any explanation is appreciated :) Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] ConfigurationPlugin is not called on configuration update
Hi,
I'm trying to implement a service that shall store a configuration in a
file each time it is updated.
My current setup looks like this:
Managed Service:
@Component(configurationPid="system")
public class SomeManagedService{
...
}
ConfigurationPlugin/ConfigurationListener
@Component
public class ConfigToFileService implements ConfigurationPlugin,
ConfigurationListener{
@Override
public void configurationEvent(ConfigurationEvent event) {
System.out.println("Listener Event Received!");
}
@Override
public void modifyConfiguration(ServiceReference reference,
Dictionary properties) {
System.out.println("Plugin Event Received!");
}
}
Console Command:
@Component(service = ConfigurationConsoleUI.class,
immediate = true, enabled = true,
property = {
CommandProcessor.COMMAND_SCOPE + "=config",
CommandProcessor.COMMAND_FUNCTION + "=updateConfig"})
public class ConfigurationConsoleUI {
@Reference
private ConfigurationAdmin configAdmin;
public void updateConfig() {
try {
Configuration configuration =
configAdmin.getConfiguration("system", "?");
configuration.update(configuration.getProperties());
} catch (IOException e) {
e.printStackTrace();
}
}
}
When I call "updateConfig" the ConfigurationListener method of my
ConfigToFileService is called, but the ConfiurationPlugin method is not.
My expectation would have been that first the ConfigurationPlugin method
is called and then the ConfigurationListener method.
Do I have to do anything else to get the ConfigurationPlugin method to
be called by ConfigurationAdmin?
Any advice is appreciated.
Kind regards,
Thomas___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Configuring reference.cardinality.minimum / reference.target via Metatypes
Well, sorry for the dumb question.
It was literally written down two lines below from where I stopped
reading in the Compendium specification.
I just had to name the property like:
_cardinality_minimum
and it just worked.
OSGi is great ;)
-- Originalnachricht --
Von: "Thomas Driessen" <thomas.driessen...@gmail.com>
An: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 13.04.2017 15:24:21
Betreff: Configuring reference.cardinality.minimum / reference.target
via Metatypes
Hi,
I was wondering if one can configure the @Reference cardinality.minimum
property of a service vie Metatypes somehow?
In my example (written in Xtend) I'd like to configure the minimum
cardinality of 'stuff'. So is there a magic property name/pattern (like
in the commented code below) that I can use in MyConfiguration in
order to achieve that?
@ObjectClassDefinition
annotation MyConfiguration{
String name
// String stuffCardinalityMinimum
}
@Designate(ocd = MyConfiguration)
@Component(configurationPid = 'configurable')
class ConfigurableTest{
@Reference(
cardinality = ReferenceCardinality.MULTIPLE,
policy = ReferencePolicy.DYNAMIC,
policyOption = ReferencePolicyOption.GREEDY
)
volatile List stuff
@Activate
private def void activate(MyConfiguration config){
println('''Activated: «config.name»''')
}
@Modified
private def void update(MyConfiguration config){
println('''Updated: «config.name»''')
}
@Deactivate
private def void deactivate(){
println('''Deactivated''')
}
}
@Component
class Stuff implements IStuff{}
interface IStuff{}
Any advice is appreciated :)
Kind regards,
Thomas___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Configuring reference.cardinality.minimum / reference.target via Metatypes
Hi,
I was wondering if one can configure the @Reference cardinality.minimum
property of a service vie Metatypes somehow?
In my example (written in Xtend) I'd like to configure the minimum
cardinality of 'stuff'. So is there a magic property name/pattern (like in
the commented code below) that I can use in MyConfiguration in order to
achieve that?
@ObjectClassDefinition
annotation MyConfiguration{
String name
// String stuffCardinalityMinimum
}
@Designate(ocd = MyConfiguration)
@Component(configurationPid = 'configurable')
class ConfigurableTest{
@Reference(
cardinality = ReferenceCardinality.MULTIPLE,
policy = ReferencePolicy.DYNAMIC,
policyOption = ReferencePolicyOption.GREEDY
)
volatile List stuff
@Activate
private def void activate(MyConfiguration config){
println('''Activated: «config.name»''')
}
@Modified
private def void update(MyConfiguration config){
println('''Updated: «config.name»''')
}
@Deactivate
private def void deactivate(){
println('''Deactivated''')
}
}
@Component
class Stuff implements IStuff{}
interface IStuff{}
Any advice is appreciated :)
Kind regards,
Thomas
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Updating service properties at runtime
Sorry. I received the Email from BJ Hargrave the moment I sent my own.
Thank you guys for your answers!
-- Originalnachricht --
Von: "Thomas Driessen" <thomas.driessen...@gmail.com>
An: "Dirk Fauth" <dirk.fa...@gmail.com>; "OSGi Developer Mail List"
<osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:35:16
Betreff: Re[2]: [osgi-dev] Updating service properties at runtime
I am using the annotations osgi.annotations 6.0.1.
My Service looks like this:
@Component
public class ServiceAImpl implements IServiceA{
...
@Reference(cardinality = ReferenceCardinality.Multiple)
public synchronized void addServiceB(IServiceB service){
...
}
}
and I was just wondering if there is the possibility to write something
like
@Reference(cardinality = ReferenceCardinality, Multiple,
minimumCardinality = 4)
But Jens Kübler already wrote that I would have to add this information
manually to the generated XML.
Maybe the following is possible then?
@Component(
property = "ServiceB.cardinality.minimum=4"
)
public class ServiceAImpl implements IServiceA{
...
}
Kind regards,
Thomas
-- Originalnachricht --
Von: "Dirk Fauth" <dirk.fa...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:25:06
Betreff: Re: [osgi-dev] Updating service properties at runtime
Well if you use Bndtools you should be able to use the annotations.
Maybe you use the wrong annotations in the configuration?
Am 02.03.2017 2:18 PM schrieb "Thomas Driessen"
<thomas.driessen...@gmail.com>:
I'm using the version 5.6.1 of Felix as osgi framework if that does
matter?
Eclipse is only used as IDE in combination with bndtools 4
Thomas
-- Originalnachricht --
Von: "Dirk Fauth" <dirk.fa...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:13:42
Betreff: Re: [osgi-dev] Updating service properties at runtime
Actually Oxygen in its current development state contains Felix SCR,
so it supports DS 1.3 under the hood.
For the DS 1.3 annotations there is a Gerrit patch available that
needs to be verified. I'm currently looking at this so it can be
part of Eclipse Oxygen.
Minimum cardinality is a DS 1.3 feature so it will not work with
Eclipse in its current release state.
Am 02.03.2017 2:07 PM schrieb "Thomas Driessen"
<thomas.driessen...@gmail.com>:
Thank you very much!
-- Originalnachricht --
Von: "Kübler, Jens" <jens.kueb...@vector.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:05:27
Betreff: RE: [osgi-dev] Updating service properties at runtime
Eclipse does only support the DS 1.2 spec and this was added in a
later version.
if you are running in a DS 1.3 environment you have to add it
manually to the xml and cannot use the annotations.
Discussion is under way to add the functionality in Eclipse 4.7
Kind Regards
Jens
From:osgi-dev-boun...@mail.osgi.org
[mailto:osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>] On Behalf Of Thomas
Driessen
Sent: Thursday, March 02, 2017 2:01 PM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Updating service properties at runtime
Thank you both for your answers.
Is it possible to directly annotate a reference with the minimum
cardinality, or do I have to do this via ConfigurationAdmin?
In Eclipse autocomplete only shows the property cardinality which
expects a ReferenceCardinality (OPTIONAL, MANDATORY, etc.)
112.6.2.2 in the specification also only talks about how to adress
this property via ConfigurationAdmin.
Kind regards,
Thomas
-- Originalnachricht --
Von: "Dirk Fauth" <dirk.fa...@gmail.com>
An: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 13:37:21
Betreff: Re: [osgi-dev] Updating service properties at runtime
You can find an example in one of my blog posts.
http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/
<http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/>
At the bottom the usage of the minimum cardinality reference
property is shown.
Am 02.03.2017 1:07 PM schrieb "Carsten Ziegeler"
<cziege...@apache.org>:
You can do this with DS, have a look at section 112.6.2.2 Minimum
Cardinality Property
Regards
Carsten
Thomas Driessen wrote
> Hi,
>
> I currently have the following usecase:
>
> Service A depends on Service B
> Service B depends on 4x Service C
> Service A
Re: [osgi-dev] Updating service properties at runtime
I am using the annotations osgi.annotations 6.0.1.
My Service looks like this:
@Component
public class ServiceAImpl implements IServiceA{
...
@Reference(cardinality = ReferenceCardinality.Multiple)
public synchronized void addServiceB(IServiceB service){
...
}
}
and I was just wondering if there is the possibility to write something
like
@Reference(cardinality = ReferenceCardinality, Multiple,
minimumCardinality = 4)
But Jens Kübler already wrote that I would have to add this information
manually to the generated XML.
Maybe the following is possible then?
@Component(
property = "ServiceB.cardinality.minimum=4"
)
public class ServiceAImpl implements IServiceA{
...
}
Kind regards,
Thomas
-- Originalnachricht --
Von: "Dirk Fauth" <dirk.fa...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:25:06
Betreff: Re: [osgi-dev] Updating service properties at runtime
Well if you use Bndtools you should be able to use the annotations.
Maybe you use the wrong annotations in the configuration?
Am 02.03.2017 2:18 PM schrieb "Thomas Driessen"
<thomas.driessen...@gmail.com>:
I'm using the version 5.6.1 of Felix as osgi framework if that does
matter?
Eclipse is only used as IDE in combination with bndtools 4
Thomas
-- Originalnachricht --
Von: "Dirk Fauth" <dirk.fa...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:13:42
Betreff: Re: [osgi-dev] Updating service properties at runtime
Actually Oxygen in its current development state contains Felix SCR,
so it supports DS 1.3 under the hood.
For the DS 1.3 annotations there is a Gerrit patch available that
needs to be verified. I'm currently looking at this so it can be part
of Eclipse Oxygen.
Minimum cardinality is a DS 1.3 feature so it will not work with
Eclipse in its current release state.
Am 02.03.2017 2:07 PM schrieb "Thomas Driessen"
<thomas.driessen...@gmail.com>:
Thank you very much!
-- Originalnachricht --
Von: "Kübler, Jens" <jens.kueb...@vector.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 14:05:27
Betreff: RE: [osgi-dev] Updating service properties at runtime
Eclipse does only support the DS 1.2 spec and this was added in a
later version.
if you are running in a DS 1.3 environment you have to add it
manually to the xml and cannot use the annotations.
Discussion is under way to add the functionality in Eclipse 4.7
Kind Regards
Jens
From:osgi-dev-boun...@mail.osgi.org
[mailto:osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>] On Behalf Of Thomas
Driessen
Sent: Thursday, March 02, 2017 2:01 PM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Updating service properties at runtime
Thank you both for your answers.
Is it possible to directly annotate a reference with the minimum
cardinality, or do I have to do this via ConfigurationAdmin?
In Eclipse autocomplete only shows the property cardinality which
expects a ReferenceCardinality (OPTIONAL, MANDATORY, etc.)
112.6.2.2 in the specification also only talks about how to adress
this property via ConfigurationAdmin.
Kind regards,
Thomas
-- Originalnachricht --
Von: "Dirk Fauth" <dirk.fa...@gmail.com>
An: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 02.03.2017 13:37:21
Betreff: Re: [osgi-dev] Updating service properties at runtime
You can find an example in one of my blog posts.
http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/
<http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/>
At the bottom the usage of the minimum cardinality reference
property is shown.
Am 02.03.2017 1:07 PM schrieb "Carsten Ziegeler"
<cziege...@apache.org>:
You can do this with DS, have a look at section 112.6.2.2 Minimum
Cardinality Property
Regards
Carsten
Thomas Driessen wrote
> Hi,
>
> I currently have the following usecase:
>
> Service A depends on Service B
> Service B depends on 4x Service C
> Service A may only become active when Service B has exactly 4x
Service
> C, thus becoming active itself.
>
> I'm using declarative services which only support 0-*, 1-*, 0-1
and
> exactly 1 dependencies between services.
>
> One idea I came up with, was to count the C services in B's
setC(C c)
> method and, on reaching the count of 4, setting a specific
property on B
> (e.g. weirdUsecaseIsActive = true) and let A's re
Re: [osgi-dev] Updating service properties at runtime
I'm using the version 5.6.1 of Felix as osgi framework if that does matter? Eclipse is only used as IDE in combination with bndtools 4 Thomas -- Originalnachricht -- Von: "Dirk Fauth" <dirk.fa...@gmail.com> An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 02.03.2017 14:13:42 Betreff: Re: [osgi-dev] Updating service properties at runtime Actually Oxygen in its current development state contains Felix SCR, so it supports DS 1.3 under the hood. For the DS 1.3 annotations there is a Gerrit patch available that needs to be verified. I'm currently looking at this so it can be part of Eclipse Oxygen. Minimum cardinality is a DS 1.3 feature so it will not work with Eclipse in its current release state. Am 02.03.2017 2:07 PM schrieb "Thomas Driessen" <thomas.driessen...@gmail.com>: Thank you very much! -- Originalnachricht -- Von: "Kübler, Jens" <jens.kueb...@vector.com> An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 02.03.2017 14:05:27 Betreff: RE: [osgi-dev] Updating service properties at runtime Eclipse does only support the DS 1.2 spec and this was added in a later version. if you are running in a DS 1.3 environment you have to add it manually to the xml and cannot use the annotations. Discussion is under way to add the functionality in Eclipse 4.7 Kind Regards Jens From:osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org>] On Behalf Of Thomas Driessen Sent: Thursday, March 02, 2017 2:01 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Updating service properties at runtime Thank you both for your answers. Is it possible to directly annotate a reference with the minimum cardinality, or do I have to do this via ConfigurationAdmin? In Eclipse autocomplete only shows the property cardinality which expects a ReferenceCardinality (OPTIONAL, MANDATORY, etc.) 112.6.2.2 in the specification also only talks about how to adress this property via ConfigurationAdmin. Kind regards, Thomas -- Originalnachricht -- Von: "Dirk Fauth" <dirk.fa...@gmail.com> An: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 02.03.2017 13:37:21 Betreff: Re: [osgi-dev] Updating service properties at runtime You can find an example in one of my blog posts. http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/ <http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/> At the bottom the usage of the minimum cardinality reference property is shown. Am 02.03.2017 1:07 PM schrieb "Carsten Ziegeler" <cziege...@apache.org>: You can do this with DS, have a look at section 112.6.2.2 Minimum Cardinality Property Regards Carsten Thomas Driessen wrote > Hi, > > I currently have the following usecase: > > Service A depends on Service B > Service B depends on 4x Service C > Service A may only become active when Service B has exactly 4x Service > C, thus becoming active itself. > > I'm using declarative services which only support 0-*, 1-*, 0-1 and > exactly 1 dependencies between services. > > One idea I came up with, was to count the C services in B's setC(C c) > method and, on reaching the count of 4, setting a specific property on B > (e.g. weirdUsecaseIsActive = true) and let A's reference to B filter > with a corresponding target filter. > > I know this sound like a dirty hack, but I did not found any better > solutions. > > Therefore, my questions are: > 1) Is there a better solution for my usecase? > 2) If not: How do I update properties of a service at runtime? > > Kind regards, > Thomas > > > ___ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev <https://mail.osgi.org/mailman/listinfo/osgi-dev> > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List 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 <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
Re: [osgi-dev] Updating service properties at runtime
Thank you very much! -- Originalnachricht -- Von: "Kübler, Jens" <jens.kueb...@vector.com> An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 02.03.2017 14:05:27 Betreff: RE: [osgi-dev] Updating service properties at runtime Eclipse does only support the DS 1.2 spec and this was added in a later version. if you are running in a DS 1.3 environment you have to add it manually to the xml and cannot use the annotations. Discussion is under way to add the functionality in Eclipse 4.7 Kind Regards Jens From:osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Thomas Driessen Sent: Thursday, March 02, 2017 2:01 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Updating service properties at runtime Thank you both for your answers. Is it possible to directly annotate a reference with the minimum cardinality, or do I have to do this via ConfigurationAdmin? In Eclipse autocomplete only shows the property cardinality which expects a ReferenceCardinality (OPTIONAL, MANDATORY, etc.) 112.6.2.2 in the specification also only talks about how to adress this property via ConfigurationAdmin. Kind regards, Thomas -- Originalnachricht -- Von: "Dirk Fauth" <dirk.fa...@gmail.com> An: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Gesendet: 02.03.2017 13:37:21 Betreff: Re: [osgi-dev] Updating service properties at runtime You can find an example in one of my blog posts. http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/ At the bottom the usage of the minimum cardinality reference property is shown. Am 02.03.2017 1:07 PM schrieb "Carsten Ziegeler" <cziege...@apache.org>: You can do this with DS, have a look at section 112.6.2.2 Minimum Cardinality Property Regards Carsten Thomas Driessen wrote > Hi, > > I currently have the following usecase: > > Service A depends on Service B > Service B depends on 4x Service C > Service A may only become active when Service B has exactly 4x Service > C, thus becoming active itself. > > I'm using declarative services which only support 0-*, 1-*, 0-1 and > exactly 1 dependencies between services. > > One idea I came up with, was to count the C services in B's setC(C c) > method and, on reaching the count of 4, setting a specific property on B > (e.g. weirdUsecaseIsActive = true) and let A's reference to B filter > with a corresponding target filter. > > I know this sound like a dirty hack, but I did not found any better > solutions. > > Therefore, my questions are: > 1) Is there a better solution for my usecase? > 2) If not: How do I update properties of a service at runtime? > > Kind regards, > Thomas > > > ___ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ 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
[osgi-dev] Updating service properties at runtime
Hi, I currently have the following usecase: Service A depends on Service B Service B depends on 4x Service C Service A may only become active when Service B has exactly 4x Service C, thus becoming active itself. I'm using declarative services which only support 0-*, 1-*, 0-1 and exactly 1 dependencies between services. One idea I came up with, was to count the C services in B's setC(C c) method and, on reaching the count of 4, setting a specific property on B (e.g. weirdUsecaseIsActive = true) and let A's reference to B filter with a corresponding target filter. I know this sound like a dirty hack, but I did not found any better solutions. Therefore, my questions are: 1) Is there a better solution for my usecase? 2) If not: How do I update properties of a service at runtime? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Components are not started, although marked with immediate=true
Hi,
I have a problem with immediate services and hoped that you guys maybe
can help.
I'm currently trying to implement several services within one bundle
(see below for code).
I have set all of them to be immediate (by immediate=true), but still,
when I start the OSGi container with my bundle in it, only Con1,
InDataPort1 and OutDataPort1 are active. The rest is satisfied but not
active according to felix.scr console output:
g! list
BundleId Component Name Default State
Component Id State PIDs (Factory PID)
[ 10] test.Con1 enabled
[ 0] [active ]
[ 10] test.InDataPort1 enabled
[ 1] [active ]
[ 10] test.OutDataPort1 enabled
[ 2] [active ]
[ 10] test.Process1 enabled
[ 3] [satisfied ]
[ 10] test.Thread1_1 enabled
[ 4] [satisfied ]
[ 10] test.Thread1_2 enabled
[ 5] [satisfied ]
Am I doing something wrong?
I assumed that all services should be started as soon as they are
satisfied.
Any advice is highly appreciated.
Kind regards,
Thomas
@Component(immediate = true, service = IProcess.class, property =
"de.uniaugsburg.smds.aadl2osgi.component.uid=test.Process1")
public class Process1 implements IProcess {
@Reference(target = "(uid=test.Thread1_1)")
private volatile IPeriodicThread thread1;
@Reference(target = "(uid=test.Thread1_2)")
private volatile IPeriodicThread thread2;
}
@Component(service = IPeriodicThread.class, property =
"de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_1", immediate
= true)
public class Thread1_1 implements IPeriodicThread {
@Reference(target = "(uid=test.OutDataPort1)")
private volatile IOutDataPort outport;
@Activate
public void initialize_FW() {
init();
}
@Deactivate
public void finalize_FW() {
deinit();
}
}
@Component(service = IPeriodicThread.class, property =
"de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_2", immediate
= true)
public class Thread1_2 implements IPeriodicThread {
@Reference(target = "(uid=test.InDataPort1)")
private volatile IOutDataPort outport;
@Activate
public void initialize_FW() {
init();
}
@Deactivate
public void finalize_FW() {
deinit();
}
}
@Component(service = IOutDataPort.class, property =
"uid=test.OutDataPort1", immediate = true)
public class OutDataPort1 implements IOutDataPort {
@Reference(target = "(target=test.OutDataPort1)", cardinality =
ReferenceCardinality.OPTIONAL, policyOption =
ReferencePolicyOption.GREEDY)
private volatile IPortConnection incomingPortConnections;
private volatile Set outgoingPortConnections = new
ConcurrentSkipListSet();
@Reference(target = "(source=test.OutDataPort1)", cardinality =
ReferenceCardinality.OPTIONAL, policyOption =
ReferencePolicyOption.GREEDY)
public void addOutgoingPortConnection(final IPortConnection con) {
outgoingPortConnections.add(con);
}
public void removeOutgoingPortConnection(final IPortConnection con) {
outgoingPortConnections.remove(con);
}
}
@Component(service = IInDataPort.class, property =
"uid=test.InDataPort1", immediate = true)
@SuppressWarnings("all")
public class InDataPort1 implements IInDataPort {
@Reference(target = "(target=test.InDataPort1)", cardinality =
ReferenceCardinality.OPTIONAL, policyOption =
ReferencePolicyOption.GREEDY)
private volatile IPortConnection incomingPortConnections;
private volatile Set outgoingPortConnections = new
ConcurrentSkipListSet();
@Reference(target = "(source=test.InDataPort1)", cardinality =
ReferenceCardinality.OPTIONAL, policyOption =
ReferencePolicyOption.GREEDY)
public void addOutgoingPortConnection(final IPortConnection con) {
outgoingPortConnections.add(con);
}
public void removeOutgoingPortConnection(final IPortConnection con) {
outgoingPortConnections.remove(con);
}
}
@Component(service = IPortConnection.class, property = {
"source=test.OutDataPort1", "target=test.InDataPort1" }, immediate =
true)
public class Con1 implements IPortConnection {
@Reference(cardinality = ReferenceCardinality.OPTIONAL, policyOption =
ReferencePolicyOption.GREEDY, target = "(uid=test.OutDataPort1)")
private volatile IOutDataPort source;
@Reference(cardinality = ReferenceCardinality.OPTIONAL, policyOption =
ReferencePolicyOption.GREEDY, target = "(uid=test.InDataPort1)")
private volatile IInDataPort target;
}___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Maven Central bundle shows IllegalArgumentException
Hi, I just started using the possibility to import Bundles from Maven Central (great work by the way, I was really missing that the last time I used BndTools :) ) Correct me if I did something wrong: I added a new dependency in the "central.xml" org.eclipse.xtend org.eclipse.xtend.lib 2.10.0 and refreshed my repositories. Now org.eclipse.xtend.lib is shown correctly, but its two transitive dependencies org.eclipse.xtend.org:org:eclipse.xtend.lib.macro and org.eclipse.xtext:org.eclipse.xtext.xbase.lib are both displayed with a [!] bheind their name. Behind the version there is a text displaying [java.lnag.IllegalArgumentException: Invalid syntax for version: [14.0,19.0)] Is this a warning or an error? Can I use the bundles anyway? Kind regards, Thomas___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
