Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Jürgen Albert via osgi-dev]

Hi Ray,

I love this reply, we should frame it somewhere! :-)

Amen to that and a happy new year to you and Pam.

Jürgen.

Am 03/01/2020 um 17:02 schrieb Raymond Auge via osgi-dev:



On Fri, Jan 3, 2020 at 10:29 AM Martin Petzold > wrote:


IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and
bnd "hate" Eclipse. It was never easy. The worst ever was not to
find together!

Sounds like you may not have tried bndtools.m2e integration in a long 
time or ever. OSGi, bnd, bndtools.m2e + Eclipse are a happy team that 
I use every single day on about 15 projects, including in IDE 
integration testing and live coding!


Furthermore, the bnd team (disclosure: of which I am part) are very 
active [1] in improving the IDE experience and are more than happy to 
address any issues you encounter.


Anyway, if you like what you have then more power to you :) but it 
seems like you might be alone on an island which can be awesome!... 
but it can also be bad.


Sincerely,
- Ray

[1] https://github.com/bndtools/bnd/pulse/monthly *(Activity - 1 
month: 49 merged pull requests, 68 commits, 29 closed issues, 3 new 
issues)*


=> My approach works well, I have a lot under my control and am
able to migrate to plain Java (with or without modules) if it is
required

I still love the OSGi specifications and framework, use a lot of
them, and learned a lot of them and all people involved!

Am 03.01.20 um 16:22 schrieb Dirk Fauth:


I also think that the chosen approach is not the best. Actually
it is a mixture of Tycho and plain maven that mostly works but
can lead to resolution issues like the one discussed.

For plain OSGi and Maven I agree with Ray. But you need to
migrate to bnd of course and get rid of the manual manifest
configuration (which is good IMHO).

If you really want to stick with manual manifest management, you
should use Tycho in its intended way by using repositories or a
target definition so the dependencies can be resolved
automatically via p2. pomDependencies consider is intended for
adding dependencies that are not available via p2 update sites.

But of course this is only my personal opinion based on my
experience.

Greez,
Dirk

Raymond Auge mailto:raymond.a...@liferay.com>> schrieb am Fr., 3. Jan. 2020,
15:49:

I would recommend, since you are using maven, not really
using tycho for much AND in order to future proof your OSGi
application you should probably migrate to
bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give
you a full cycle of tools to go from building to running.
Also it's the most cutting edge OSGi build support under the
hood and will reduce your MANIFEST editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

I'm using:


consider


It is working now with the following dependencies in my
POM for build/compile time. At runtime I use
org.eclipse.osgi (without the service and util bundle)
and implementations of cm (apache felix), event (apache
felix), and log (within org.eclipse.osgi an my own).




org.eclipse.platform
org.eclipse.osgi
${dependency.org.eclipse.osgi}





org.osgi
    org.osgi.service.cm

    ${dependency.org.osgi.service.cm
}


org.osgi
org.osgi.service.event
${dependency.org.osgi.service.event}


org.osgi
org.osgi.service.log
${dependency.org.osgi.service.log}


Am 03.01.20 um 15:29 schrieb Dirk Fauth:

Well afaik Tycho has its own reactor for resolving
dependencies. That's why I am a bit confused about your
message. If you build via Tycho you need to have a
working target definition or repositories configuration.
POM dependencies are not considered by default. If you
update to R7 you need to update to a current Eclipse
update site and ensure that all related bundles and/or
features are included.

But of course I am not sure if I understand your issue
completely. If you are not building using Tycho but
plain Maven probably some dependencies are not
resolvable. But the previous answers already covered
most topics. I just stepped in because of 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Jürgen Albert via osgi-dev]

Hallo Martin,

ich verfolge gerade deine Diskussion in der OSGi Dev Group (mein Kollege 
Mark Hoffmann hatte sich da auch schon einmal zu Wort gemeldet). 
Ähnliche Problemem wie du sie beschreibst hatten wir früher auch, als 
wir noch die PDE und Tycho verwendet haben. Mit dem Umstieg auf BND 
haben die sich alle in Luft aufgelöst. Rückblickend haben wir 
festegestellt, dass die PDE und Tycho fundamental falsche Ansätze 
verfolgen. Manifest First ist einer davon. Bis wir umgestiegen sind 
konnten wir uns auch nicht vorstellen wie falsch der ist, da wir es nie 
anders kannten. Viele Konzepte von OSGi sind uns dadruch aber immer 
verwehrt geblieben und werden es auch langfristig bleiben, da z.B. die 
PDE die aktuelle Version der Component Annotations gar nicht unterstützt.


Wir haben im letzten Jahr verschiedenen Firmen und Projekte beim Umstieg 
zu BND unterstützt und das Eesultat war immer ein wesentlich 
effizienterer Entwicklungsprozess und sauberere Bundles. Ich schreibe 
dir ausserhalb der Mailing List, da ich dir unsere Untersützung anbieten 
möchte. Wir haben exakt die von dir beschriebenen Probleme schon in 
verschiedenen Kontexten gelöst.


Falls du interesse an unserer Hilfe hast, melde dich einfach.

Gesundes neues noch,

Jürgen Albert.

Am 03/01/2020 um 16:29 schrieb Martin Petzold via osgi-dev:


IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and bnd 
"hate" Eclipse. It was never easy. The worst ever was not to find 
together!


=> My approach works well, I have a lot under my control and am able 
to migrate to plain Java (with or without modules) if it is required


I still love the OSGi specifications and framework, use a lot of them, 
and learned a lot of them and all people involved!


Am 03.01.20 um 16:22 schrieb Dirk Fauth:

I also think that the chosen approach is not the best. Actually it is 
a mixture of Tycho and plain maven that mostly works but can lead to 
resolution issues like the one discussed.


For plain OSGi and Maven I agree with Ray. But you need to migrate to 
bnd of course and get rid of the manual manifest configuration (which 
is good IMHO).


If you really want to stick with manual manifest management, you 
should use Tycho in its intended way by using repositories or a 
target definition so the dependencies can be resolved automatically 
via p2. pomDependencies consider is intended for adding dependencies 
that are not available via p2 update sites.


But of course this is only my personal opinion based on my experience.

Greez,
Dirk

Raymond Auge > schrieb am Fr., 3. Jan. 2020, 15:49:


I would recommend, since you are using maven, not really using
tycho for much AND in order to future proof your OSGi application
you should probably migrate to bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give you
a full cycle of tools to go from building to running. Also it's
the most cutting edge OSGi build support under the hood and will
reduce your MANIFEST editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

I'm using:


consider


It is working now with the following dependencies in my POM
for build/compile time. At runtime I use org.eclipse.osgi
(without the service and util bundle) and implementations of
cm (apache felix), event (apache felix), and log (within
org.eclipse.osgi an my own).




org.eclipse.platform
org.eclipse.osgi
${dependency.org.eclipse.osgi}





    org.osgi
    org.osgi.service.cm

    ${dependency.org.osgi.service.cm
}


    org.osgi
org.osgi.service.event
${dependency.org.osgi.service.event}


    org.osgi
org.osgi.service.log
${dependency.org.osgi.service.log}


Am 03.01.20 um 15:29 schrieb Dirk Fauth:

Well afaik Tycho has its own reactor for resolving
dependencies. That's why I am a bit confused about your
message. If you build via Tycho you need to have a working
target definition or repositories configuration. POM
dependencies are not considered by default. If you update to
R7 you need to update to a current Eclipse update site and
ensure that all related bundles and/or features are included.

But of course I am not sure if I understand your issue
completely. If you are not building using Tycho but plain
Maven probably some dependencies are not resolvable. But the
previous answers already covered most topics. I just stepped
in because of 

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[Jürgen Albert via osgi-dev]

Hi Clement,

we have discussed this problem you have at a OSGi meeting and Carsten 
Ziegler implemented something that goes beyond the Spec, that might help 
you I assume here that you are using the Felix ConfigAdmin. See: 
https://issues.apache.org/jira/browse/FELIX-6059


You have to possibilities:
1. The ConfigAdmin will be registered with a property config.plugins, 
that names all ConfigurationPlugins that serve a property 
config.plugin.id. Thus register your plugin with e.g. 
config.plugin.id=my.id. Add a mandatory Service reference for the Config 
Admin with a target filter like (config.plugins=my.id) in the service 
that needs configuration. With this your Service will be activated after 
the ConfigAdmin knows about you plugin and handles the properties 
accordingly.


2. If you start your runtime with a framework property 
felix.cm.config.plugins=my.id1,my.id2 the ConfigAdmin will not become 
active and registered until the a Plugin with config.plugin.id=my.id1 
and config.plugin.id=my.id2 is available.


I hope this helps,

Jürgen.



Am 08/10/2019 um 16:27 schrieb Tim Ward via osgi-dev:
My question is, how can I tell to the Configurator bundle to not 
process resources that contains placeholder until my 
ConfigurationPlugin is up?


There are ways that you could attempt to do this, however they’re all 
inelegant and error prone. What would make more sense would be for the 
ConfigurationPlugin to detect the existing configurations which 
contain placeholders at startup and trigger an update for them. This 
will cause the configuration to be re-delivered, including any 
necessary configuration plugin execution.


In general you are better off trying to make things ordering 
independent rather than to control the order that things happen in. 
The result is a much more flexible and stable system.


Best Regards,

Tim

On 8 Oct 2019, at 12:54, BJ Hargrave via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Configuration Plugins mutate configuration data each time it is 
delivered to a configuration target. So the Configuration Plugin must 
be active before any configuration targets which care about the 
mutated configuration data.
So this is orthogonal to Configurator which is about putting 
configuration data in the CM configuration data store.

--

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: "Clément Delgrange via osgi-dev" mailto:osgi-dev@mail.osgi.org>>
Sent by: osgi-dev-boun...@mail.osgi.org

To: OSGi Developer Mail List mailto:osgi-dev@mail.osgi.org>>
Cc:
Subject: [EXTERNAL] [osgi-dev] Configurator resources that depend
on a ConfigurationPlugin
Date: Tue, Oct 8, 2019 06:08
Hi all,
I have a question regarding the Configurator and the
ConfigurationPlugin spec. I would like to provision my
application with configurations as I do with my the bundles, for
this the Configurator seems perfect. But, the values inside my
configurations could be different depending of the environment
(dev, beta, prod, ...) and my configurations may contain
sensitive data that I don't want in my Git repo. In this case I
think I could provide a ConfigurationPlugin which will replace
placeholders with data coming from a database.
My question is, how can I tell to the Configurator bundle to not
process resources that contains placeholder until my
ConfigurationPlugin is up?
Thanks,
Clément Delgrange.
___
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



--
Jürgen Albert
Geschäftsführer

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de

XING:   https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Migrating from OSGI to Microservices

[Jürgen Albert via osgi-dev]

lueprint. And so on. Even if you use “traditional”
distribution without the dynamic lifecycle it is still quite
fun and OSGi has a lot to offer (e.g. JAX-RS whiteboard).

So in general if you choose a microservice architecture and
choose to build immutable small containers you are not at
odds with OSGi. It actually can help. If you already have an
OSGi application you can consider it a head start. You will
have to refactor a lot to split your business logic into
independent services, but you won’t refactor less if you were
not OSGi based.
Mohamed however mentioned he’d like to use ready-made
solutions to implement application features and has issues
with OSGi in that respect. What are they?
OSGi can provide means to structure distributed applications,
but it sure can’t provide an independent analog of every
heavy-lifting framework out there.
---
Todor Boev
OSGi Platform
Software AG

From: osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>
[mailto:osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>] On Behalf Of Jurgen
Albert via osgi-dev
Sent: Friday, May 3, 2019 3:41 PM
To: SMAIL LOUNES; OSGi Developer Mail List
Subject: Re: [osgi-dev] Migrating from OSGI to Microservices

Well, like I said: Kubernetes only knows and cares about
Containers (Pods) and nothing about any application life
cycle. You can define e.g. dependencies like an application
container requires a container with a DB. So when someone
triggers the start of your application container it will make
sure that the DB container is started and as far as I
remember will set the coordinates to the DB as system
properties for you. However, It will not know the state of
readyness of your application or the DB. As an example, we
have search server tailor maid for one of our customers. On
first start it rebuilds the index from the raw data in their
DB. This can take a couple of minutes. For Kubernetes the
container is up and running, but the server will not be
available to answer queries until the index is ready.

Thus, if you want to use the Kubernetes API to start a Pod
for a specific services it you can do that, but everything
else is not in its scope. It is just a convenient tool to
manage an Infrastructure. The rest belongs to your
application domain.

Regards,

Jürgen.

Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES:
Thank you for this remarkable answer,
I'm working on a research project about developping a highly
distributed and dynamic communication platform, so we're
looknig for using kubernetes to manage µservices life cycle,
osgi is a condidate too. we can use an osgi container to
deploy some µservices.. do you have an idea about using
kubernetes for life cycle mangement and how integrate it's API

Thank you so much, Best regards

Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev
mailto:osgi-dev@mail.osgi.org>> a
écrit :
Hi Mohamed,

I had the fortune and in parts misfortune of being part of a
few such migration projects. Besides our own internal one,
everyone decided against OSGi. The descension was always
because of personal resentment and/or because everybody had
his personal favourite toy they wanted to play with. The
reasons ranged from " We don't want to use Eclipse" (enroute
with maven  wasn't available at the time) over "We want
spring because we don't understand OSGi and it seems to
complicated" to " Java is outdated, we want to build it with
NodeJS". They all jumped on the Martin Fowler approach
without really considering what it means in the end. Each
ended in disaster or went through a hard phase of near
disaster with jobs and reputations on the line. Most ended up
with something OSGiish with a lot of the pain going along
with modularity but missing most of its benefits.

The issue is complex but we Identified one main reason:

Modularity is an abstract concept for many developers. Spring
for example does not really teach and force a developer to
think in a modular fashion. All I saw was a bunch of smaller
Monoliths packed in Docker containers. The dynamic nature of
a Microservice environment OSGi addresses with its Bundle and
Service life cycle , was pushed in the realm of Kubernetes.
But Kubernetes (or comparable Systems) is made for managing
your Con

Re: [osgi-dev] Migrating from OSGI to Microservices

[Jürgen Albert via osgi-dev]

. This can take a couple of minutes. For
Kubernetes the container is up and running, but the server will
not be available to answer queries until the index is ready.

Thus, if you want to use the Kubernetes API to start a Pod for a
specific services it you can do that, but everything else is not
in its scope. It is just a convenient tool to manage an
Infrastructure. The rest belongs to your application domain.

Regards,

Jürgen.

Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES:
Thank you for this remarkable answer,
I'm working on a research project about developping a highly
distributed and dynamic  communication platform, so we're looknig
for using kubernetes to manage µservices life cycle, osgi is a
condidate too. we can use an osgi container to deploy some
µservices.. do you have an idea about using kubernetes for life
cycle mangement and how integrate it's API

Thank you so much, Best regards

Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev
mailto:osgi-dev@mail.osgi.org>> a écrit :
Hi Mohamed,

I had the fortune and in parts misfortune of being part of a few
such migration projects. Besides our own internal one, everyone
decided against OSGi. The descension was always because of
personal resentment and/or because everybody had his personal
favourite toy they wanted to play with. The reasons ranged from "
We don't want to use Eclipse" (enroute with maven  wasn't
available at the time) over "We want spring because we don't
understand OSGi and it seems to complicated" to " Java is
outdated, we want to build it with NodeJS". They all jumped on the
Martin Fowler approach without really considering what it means in
the end. Each ended in disaster or went through a hard phase of
near disaster with jobs and reputations on the line. Most ended up
with something OSGiish with a lot of the pain going along with
modularity but missing most of its benefits.

The issue is complex but we Identified one main reason:

Modularity is an abstract concept for many developers. Spring for
example does not really teach and force a developer to think in a
modular fashion. All I saw was a bunch of smaller Monoliths packed
in Docker containers. The dynamic nature of a Microservice
environment OSGi addresses with its Bundle and Service life cycle
, was pushed in the realm of Kubernetes. But Kubernetes (or
comparable Systems) is made for managing your Containers and not
for any application and service life cycle. Thus one needs at
least a few Developers/Architects that have modularity
internalised and address issues early on.

Another issue with the Martin Fowler approach you have already
addressed. A fully distributed system comes with a lot of
different problems (e.g. caches). Also the point of network
latency and the time serialization and deserialization is an
underestimated issue.

Like Neil stated: If you are already have an OSGi application you
already have a microservice architecture, but maybe no distributed
one. The way to go is build a good microservice monolith (or
modulith, like it is called nowadays) and then move only the
services to there own containers, that really need scaling. Graham
Charters talk from the 2016 EclipseCon Europe addresses this quite
nicely:

https://de.slideshare.net/mfrancis/microservices-osgi-better-together-graham-charters

By your mention of blueprint, I deduct that you might use an older
version of OSGi. Our internal project was somewhat similar and we
managed to go distributed without major problems. We migrated to
the latest OSGi Version and used bnd instead of PDE. Later we
moved some service to there own container. It worked like charm.
We could even show the process to a customer, with zero downtime,
by pulling up the new containers and removing bundles with the
local service implementations while the system was running.

Regarding your point of finding/keep OSGi developers: This is
something we are confronted with rather often. The best way get
developers sold on OSGi is using the latest version of it together
with bnd (pure or with the maven integration). The development
speed you can reach and maintain even in complex applications
makes most other Java developers jealous and interested to learn more.
Regards,
Jürgen.

Am 03/05/2019 um 10:57 schrieb Mohamed AFIF via osgi-dev:
Hi  Andrei,
My question had as aim to collect some experiences of suchs
migrations if this exist, we're in brainstorming phase and I'm not
making any judgement value about OSGI or microservices
architecture,  but what we push to believe that we should probely
move toward another technology, is:  the business requirement,
indeed we want to expose ou

Re: [osgi-dev] Migrating from OSGI to Microservices

[Jürgen Albert via osgi-dev]

ss modularity to build good microservces.

Here again OSGi can be a compelling solution since it tends to
build really small footprint images, because it has deep
understanding what each jar needs. This does not come for free –
you need to describe your code well in the module metadata.

The third thing I noticed is that it only really works well when
you use simple/light OSGi components. Use http whiteboard, not web
bundles. Use declarative services, not blueprint. And so on. Even
if you use “traditional” distribution without the dynamic
lifecycle it is still quite fun and OSGi has a lot to offer (e.g.
JAX-RS whiteboard).

So in general if you choose a microservice architecture and choose
to build immutable small containers you are not at odds with OSGi.
It actually can help. If you already have an OSGi application you
can consider it a head start. You will have to refactor a lot to
split your business logic into independent services, but you won’t
refactor less if you were not OSGi based.

Mohamed however mentioned he’d like to use ready-made solutions to
implement application features and has issues with OSGi in that
respect. What are they?

OSGi can provide means to structure distributed applications, but
it sure can’t provide an independent analog of every heavy-lifting
framework out there.

---

Todor Boev

OSGi Platform

Software AG

*From:*osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>
[mailto:osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>] *On Behalf Of *Jurgen
Albert via osgi-dev
*Sent:* Friday, May 3, 2019 3:41 PM
*To:* SMAIL LOUNES; OSGi Developer Mail List
*Subject:* Re: [osgi-dev] Migrating from OSGI to Microservices

Well, like I said: Kubernetes only knows and cares about
Containers (Pods) and nothing about any application life cycle.
You can define e.g. dependencies like an application container
requires a container with a DB. So when someone triggers the start
of your application container it will make sure that the DB
container is started and as far as I remember will set the
coordinates to the DB as system properties for you. However, It
will not know the state of readyness of your application or the
DB. As an example, we have search server tailor maid for one of
our customers. On first start it rebuilds the index from the raw
data in their DB. This can take a couple of minutes. For
Kubernetes the container is up and running, but the server will
not be available to answer queries until the index is ready.

Thus, if you want to use the Kubernetes API to start a Pod for a
specific services it you can do that, but everything else is not
in its scope. It is just a convenient tool to manage an
Infrastructure. The rest belongs to your application domain.

Regards,

Jürgen.

Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES:

Thank you for this remarkable answer,

I'm working on a research project about developping a highly
distributed and dynamic  communication platform, so we're
looknig for using kubernetes to manage µservices life cycle,
osgi is a condidate too. we can use an osgi container to
deploy some µservices.. do you have an idea about using
kubernetes for life cycle mangement and how integrate it's API

Thank you so much, Best regards

    Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev
mailto:osgi-dev@mail.osgi.org>> a écrit :

Hi Mohamed,

I had the fortune and in parts misfortune of being part of
a few such migration projects. Besides our own internal
one, everyone decided against OSGi. The descension was
always because of personal resentment and/or because
everybody had his personal favourite toy they wanted to
play with. The reasons ranged from " We don't want to use
Eclipse" (enroute with maven  wasn't available at the
time) over "We want spring because we don't understand
OSGi and it seems to complicated" to " Java is outdated,
we want to build it with NodeJS". They all jumped on the
Martin Fowler approach without really considering what it
means in the end. Each ended in disaster or went through a
hard phase of near disaster with jobs and reputations on
the line. Most ended up with something OSGiish with a lot
of the pain going along with modularity but missing most
of its benefits.

The issue is complex but we Identified one main reason:

Modularity is an abstract concept for many developers.
Spring for example does not really

Re: [osgi-dev] osgi-dev Digest, Vol 151, Issue 3

[Jürgen Albert via osgi-dev]

Hi Mohamed,

As far as I see it, Blueprint is a dead horse. I would recommend you 
switch to DS or the new CDI implementation. Both make working with 
components very easy and convenient.


Regarding the use of bnd:

If you use the maven bundle plugin you are already have bnd behind the 
scene. How do you run you application during dev time? Do you have the 
live update ability like bnd has? This means, when I launch something in 
my IDE, bnd will update my bundle in the running system, the moment I 
make any change to my project. This saves a lot of time, because you 
rarely need to restart you application during development. This feature 
is also important, because you have a constant dynamic in you system. 
Bundles and Services come and go every time you press save. I found a 
lot of bugs in our old bundles, because at the time we never really took 
advantage of the dynamic nature in osgi and had a lot of clean up 
issues. This Feature intuitively teaches the developer to take the life 
cycle of a component serious, because this is crucial for a real 
distributed microservice environment and often underestimated.


If you want to stick with maven instead of using the pure bnd approach I 
recommend having a look at the https://enroute.osgi.org/ examples. They 
should show most of the things you will need.


Regards,

Jürgen.

Am 06/05/2019 um 12:09 schrieb Mohamed AFIF:



Hello Jürgen

Yes I  agree with you, that a microservice architecture has become a 
fashion more than a technology, in itself, and a lot of projects ended 
up failing,
this is why we're tryin to find out how new microservice architecture 
could be more efficient for our business need and if it will bring a 
real added value to our projets.
 in other hand,   , we use maven-bundle-plugin (apache.Felix) to build 
our osgi jars and when you deduce that we use an older vesion of osgi  
because we use Blueprint, do you recommand that we replace it by DS 
when we upgrade our karaf version, now we use Karaf 4.0.6
regarding BND tools, honestly I don't see the added value that can 
bring in OSGI project (except testing).


Regards,

Mohamed

Le ven. 3 mai 2019 à 13:25, > a écrit :


Send osgi-dev mailing list submissions to
osgi-dev@mail.osgi.org 

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.osgi.org/mailman/listinfo/osgi-dev
or, via email, send a message with subject or body 'help' to
osgi-dev-requ...@mail.osgi.org 

You can reach the person managing the list at
osgi-dev-ow...@mail.osgi.org 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of osgi-dev digest..."


Today's Topics:

   1. Re: Migrating from OSGI to Microservices (Scott Lewis)
   2. Re: Migrating from OSGI to Microservices (Mohamed AFIF)
   3. Re: Migrating from OSGI to Microservices (J?rgen Albert)


--

Message: 1
Date: Thu, 2 May 2019 09:55:20 -0700
From: Scott Lewis mailto:sle...@composent.com>>
To: osgi-dev@mail.osgi.org 
Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
Message-ID: <5e8a5823-f3d1-3a0e-543b-ee4389c0f...@composent.com
>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Another option is to use OSGi Remote Services [A].

Some implementations allow use of both Jaxrs or non-Jaxrs (e.g.
legacy)
REST providers [B].

Scott

[A]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html

[B] https://wiki.eclipse.org/Distribution_Providers


On 5/2/2019 7:51 AM, BJ Hargrave via osgi-dev wrote:
> With OSGi's JAX-RS support [1], you can easily publish and consume
> RESTy endpoints in your OSGi application.
> So there is no need to "leave" OSGi to participate in a
microservice
> environment.
> [1]:
>
https://osgi.org/specification/osgi.enterprise/7.0.0/service.jaxrs.html
> --
>
> 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: Neil Bartlett via osgi-dev mailto:osgi-dev@mail.osgi.org>>
>     Sent by: osgi-dev-boun...@mail.osgi.org

>     To: Mohamed AFIF mailto:afif.moha...@gmail.com>>, OSGi Developer Mail
>     List mailto:osgi-dev@mail.osgi.org>>
>     Cc:
>     Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
>     Date: Thu, May 2, 2019 6:37 AM
>     Well the good news is that OSGi is already a 

Re: [osgi-dev] Migrating from OSGI to Microservices

[Jürgen Albert via osgi-dev]

Well, like I said: Kubernetes only knows and cares about Containers 
(Pods) and nothing about any application life cycle. You can define e.g. 
dependencies like an application container requires a container with a 
DB. So when someone triggers the start of your application container it 
will make sure that the DB container is started and as far as I remember 
will set the coordinates to the DB as system properties for you. 
However, It will not know the state of readyness of your application or 
the DB. As an example, we have search server tailor maid for one of our 
customers. On first start it rebuilds the index from the raw data in 
their DB. This can take a couple of minutes. For Kubernetes the 
container is up and running, but the server will not be available to 
answer queries until the index is ready.


Thus, if you want to use the Kubernetes API to start a Pod for a 
specific services it you can do that, but everything else is not in its 
scope. It is just a convenient tool to manage an Infrastructure. The 
rest belongs to your application domain.


Regards,

Jürgen.

Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES:

Thank you for this remarkable answer,
I'm working on a research project about developping a highly 
distributed and dynamic  communication platform, so we're looknig for 
using kubernetes to manage µservices life cycle, osgi is a condidate 
too. we can use an osgi container to deploy some µservices.. do you 
have an idea about using kubernetes for life cycle mangement and how 
integrate it's API


Thank you so much, Best regards

Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> a écrit :


Hi Mohamed,

I had the fortune and in parts misfortune of being part of a few
such migration projects. Besides our own internal one, everyone
decided against OSGi. The descension was always because of
personal resentment and/or because everybody had his personal
favourite toy they wanted to play with. The reasons ranged from "
We don't want to use Eclipse" (enroute with maven  wasn't
available at the time) over "We want spring because we don't
understand OSGi and it seems to complicated" to " Java is
outdated, we want to build it with NodeJS". They all jumped on the
Martin Fowler approach without really considering what it means in
the end. Each ended in disaster or went through a hard phase of
near disaster with jobs and reputations on the line. Most ended up
with something OSGiish with a lot of the pain going along with
modularity but missing most of its benefits.

The issue is complex but we Identified one main reason:

Modularity is an abstract concept for many developers. Spring for
example does not really teach and force a developer to think in a
modular fashion. All I saw was a bunch of smaller Monoliths packed
in Docker containers. The dynamic nature of a Microservice
environment OSGi addresses with its Bundle and Service life cycle
, was pushed in the realm of Kubernetes. But Kubernetes (or
comparable Systems) is made for managing your Containers and not
for any application and service life cycle. Thus one needs at
least a few Developers/Architects that have modularity
internalised and address issues early on.

Another issue with the Martin Fowler approach you have already
addressed. A fully distributed system comes with a lot of
different problems (e.g. caches). Also the point of network
latency and the time serialization and deserialization is an
underestimated issue.

Like Neil stated: If you are already have an OSGi application you
already have a microservice architecture, but maybe no distributed
one. The way to go is build a good microservice monolith (or
modulith, like it is called nowadays) and then move only the
services to there own containers, that really need scaling. Graham
Charters talk from the 2016 EclipseCon Europe addresses this quite
nicely:

https://de.slideshare.net/mfrancis/microservices-osgi-better-together-graham-charters

By your mention of blueprint, I deduct that you might use an older
version of OSGi. Our internal project was somewhat similar and we
managed to go distributed without major problems. We migrated to
the latest OSGi Version and used bnd instead of PDE. Later we
moved some service to there own container. It worked like charm.
We could even show the process to a customer, with zero downtime,
by pulling up the new containers and removing bundles with the
local service implementations while the system was running.

Regarding your point of finding/keep OSGi developers: This is
something we are confronted with rather often. The best way get
developers sold on OSGi is using the latest version of it together
with bnd (pure or with the maven integration). The development
speed you ca

Re: [osgi-dev] Migrating from OSGI to Microservices

[Jürgen Albert via osgi-dev]

Hi Mohamed,

I had the fortune and in parts misfortune of being part of a few such 
migration projects. Besides our own internal one, everyone decided 
against OSGi. The descension was always because of personal resentment 
and/or because everybody had his personal favourite toy they wanted to 
play with. The reasons ranged from " We don't want to use Eclipse" 
(enroute with maven  wasn't available at the time) over "We want spring 
because we don't understand OSGi and it seems to complicated" to " Java 
is outdated, we want to build it with NodeJS". They all jumped on the 
Martin Fowler approach without really considering what it means in the 
end. Each ended in disaster or went through a hard phase of near 
disaster with jobs and reputations on the line. Most ended up with 
something OSGiish with a lot of the pain going along with modularity but 
missing most of its benefits.


The issue is complex but we Identified one main reason:

Modularity is an abstract concept for many developers. Spring for 
example does not really teach and force a developer to think in a 
modular fashion. All I saw was a bunch of smaller Monoliths packed in 
Docker containers. The dynamic nature of a Microservice environment OSGi 
addresses with its Bundle and Service life cycle , was pushed in the 
realm of Kubernetes. But Kubernetes (or comparable Systems) is made for 
managing your Containers and not for any application and service life 
cycle. Thus one needs at least a few Developers/Architects that have 
modularity internalised and address issues early on.


Another issue with the Martin Fowler approach you have already 
addressed. A fully distributed system comes with a lot of different 
problems (e.g. caches). Also the point of network latency and the time 
serialization and deserialization is an underestimated issue.


Like Neil stated: If you are already have an OSGi application you 
already have a microservice architecture, but maybe no distributed one. 
The way to go is build a good microservice monolith (or modulith, like 
it is called nowadays) and then move only the services to there own 
containers, that really need scaling. Graham Charters talk from the 2016 
EclipseCon Europe addresses this quite nicely: 
https://de.slideshare.net/mfrancis/microservices-osgi-better-together-graham-charters


By your mention of blueprint, I deduct that you might use an older 
version of OSGi. Our internal project was somewhat similar and we 
managed to go distributed without major problems. We migrated to the 
latest OSGi Version and used bnd instead of PDE. Later we moved some 
service to there own container. It worked like charm. We could even show 
the process to a customer, with zero downtime, by pulling up the new 
containers and removing bundles with the local service implementations 
while the system was running.


Regarding your point of finding/keep OSGi developers: This is something 
we are confronted with rather often. The best way get developers sold on 
OSGi is using the latest version of it together with bnd (pure or with 
the maven integration). The development speed you can reach and maintain 
even in complex applications makes most other Java developers jealous 
and interested to learn more.


Regards,

Jürgen.


Am 03/05/2019 um 10:57 schrieb Mohamed AFIF via osgi-dev:

Hi  Andrei,
My question had as aim to collect some experiences of suchs migrations 
if this exist, we're in brainstorming phase and I'm not making any 
judgement value about OSGI or microservices architecture,  but what we 
push to believe that we should probely move toward another technology, 
is:  the business requirement, indeed we want to expose our service to 
clients as API, and the several technical complications we 've ve been 
faced to everytime we want to implement a feature easily provided and 
could be implemented by other open framework in the market, there is 
also the Human ressource question is involved beacause it's not easy 
find/keep OSGI developers.
personaly  I think that OSGI is a perfect tehcnology for servers or 
embedded system, but I've some doubt when it's regarding applications 
with open architectures, it's my own view and I could be wrong


Regards

Mohamed.







@Neil
Obviously a simple



Le jeu. 2 mai 2019 à 16:52, Andrei Dulvac > a écrit :


Hi Mohamed, Neil.

Neil, while I agree with you, I think Mohamed means it in the more
"modern", widely-accepted sense:
https://martinfowler.com/articles/microservices.html

"""
In short, the microservice architectural style [1]

is an approach to developing a single application as a suite of
small services, each running in its own process and communicating
with lightweight mechanisms, often an HTTP resource API.
"""

Mohamed, I'm curious what you end up with. Without getting too
much into it, I dismissed the idea as 

Re: [osgi-dev] SCR API

[Jürgen Albert via osgi-dev]

See my comments inline.
Am 25/02/2019 um 16:24 schrieb Thomas Driessen:

Hi Tim, hi Jürgen,

thanks for your detailed answers.

Just to wrap it up so I didn't get something wrong:

A service is an object with an interface and properties registered in 
the OSGi service registry and can be seen as an OSGi primitive for 
bundle interoperation.
SCR is just a DI Framework that takes OSGi's dynamism into account and 
additionally registers all its components (declarative services) as 
services in the OSGi service registry.


Yes and no. The Second half of the first sentence is correct, the first 
only partial:


DS creates Components, that follow a lifecycle (activate, update, 
deactivate) dependent on the availability of configurations and/or 
dependencies. If a Component declares a service class (Which can be a 
normal class, abstract class or Interface), then it is registered in the 
service un-/registry according to its life cycle.




@Tim: I might have expressed myself ambiguously. I didn't want to 
propose to change the DS specification which standardizes how services 
can be defined declaratively and also describes the behavior of a SCR 
implementation.
What I instead intended to do was to ask if it would be 
possible/sensible for a SCR implementation (e.g., Apache Felix SCR) to 
also offer an API as mentioned before, so that I can write an Extender 
that takes non-annotated classes at runtime and tell an SCR 
implementation which fields/methods have to be treated as if they were 
annotated with DS annotations.


However, if that is what you understood from my last mail anyway then 
I still seem to be too dumb to get why such an API would be a request 
for a radically different component model, e.g., why it makes such a 
difference if the SCR instantiates a component because of an XML it 
reads or because another entity commands it to do so. The information 
that is given for the instantiation would be the same on the 
imperative as on the declarative way I think.


I can see that creating new DS component descriptions programmatically 
might be useful, but I'm not quite sure, when this should be necessary.
@Jürgen: I don't think this would work in my case, as I need a 
reference to the instance created. So when I create an instance via 
ConfigAdmin then I usually don't get back a reference to the instance 
that is created by the ConfigAdmin, but only have a reference on the 
configuration I used to create a new instance. Or am I wrong?
What do you need to do with the View of your example? If this needs to 
be used elsewhere, then this component should await the emergence on the 
Service you have just configured via a reference with a target.


Kind regards,
Thomas




-- Originalnachricht --
Von: "Jürgen Albert via osgi-dev" <mailto:osgi-dev@mail.osgi.org>>

An: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
Gesendet: 22.02.2019 15:34:16
Betreff: Re: [osgi-dev] SCR API


As an Addition to the things already suggested:

Taking your example I would create the MainView as follows:

@Route("")
@Component(name="MainView ", service=HasElement.class, 
configurationPolicy=Required, scope=PROTOTYPE)

public class MainView extends VerticalLayout{
  @Reference //what ever is required here
  SomeService someService;
}

You can then use the Configurator or Config Admin to create you 
component and even your someService target binding. Here is an 
example for the Configurator would need to be translated to the 
ConfigAdmin if you want to do this programmatically.


{
    ":configurator:resource-version": 1,
    "MainView~instance1":
    {
        "someService.target": "(fancy.service.id.prop=fizzbuzz)"
    }
}

Regards,

Jürgen.


Am 22/02/2019 um 10:29 schrieb Tim Ward via osgi-dev:

Hi Thomas,

I’m not sure that there is a naming issue here, but possibly a 
different misunderstanding.



From my understanding there are two kinds of "services”:


This is not really accurate. There is only one kind of service in 
OSGi, and it’s an object which has been registered with the service 
registry. It is always registered by a call to 
context.registerService(...). It doesn’t matter whether this action 
is taken directly by your bundle, or on your bundle’s behalf by an 
extender bundle. The fact that all services are the same is 
important because this is how bundles interoperate. Your bundles can 
use any mechanisms that they like internally and they can still 
interact with other bundles that may be using the same, or 
different, internal details.


2) "Fancy services" aka DS managed by a SCR. I specify those 
declaratively via annotations, they have a lifecycle and can have 
references to other services/components via annotations like 
@Activate/@Deactivate (Lifecycle) and @Reference. Those I will call 
components for the rest of this mail.


There are a large number of different component models arou

Re: [osgi-dev] SCR API

[Jürgen Albert via osgi-dev]

As an Addition to the things already suggested:

Taking your example I would create the MainView as follows:

@Route("")
@Component(name="MainView ", service=HasElement.class, 
configurationPolicy=Required, scope=PROTOTYPE)

public class MainView extends VerticalLayout{
  @Reference //what ever is required here
  SomeService someService;
}

You can then use the Configurator or Config Admin to create you 
component and even your someService target binding. Here is an example 
for the Configurator would need to be translated to the ConfigAdmin if 
you want to do this programmatically.


{
    ":configurator:resource-version": 1,
    "MainView~instance1":
    {
        "someService.target": "(fancy.service.id.prop=fizzbuzz)"
    }
}

Regards,

Jürgen.


Am 22/02/2019 um 10:29 schrieb Tim Ward via osgi-dev:

Hi Thomas,

I’m not sure that there is a naming issue here, but possibly a 
different misunderstanding.



From my understanding there are two kinds of "services”:


This is not really accurate. There is only one kind of service in 
OSGi, and it’s an object which has been registered with the service 
registry. It is always registered by a call to 
context.registerService(...). It doesn’t matter whether this action is 
taken directly by your bundle, or on your bundle’s behalf by an 
extender bundle. The fact that all services are the same is important 
because this is how bundles interoperate. Your bundles can use any 
mechanisms that they like internally and they can still interact with 
other bundles that may be using the same, or different, internal details.


2) "Fancy services" aka DS managed by a SCR. I specify those 
declaratively via annotations, they have a lifecycle and can have 
references to other services/components via annotations like 
@Activate/@Deactivate (Lifecycle) and @Reference. Those I will call 
components for the rest of this mail.


There are a large number of different component models around in Java. 
These provide lifecycle management and injection for your objects. In 
the case of OSGi aware component models they also provide support for 
registering the object instance as a service (using 
context.registerService()).


For Declarative Services the programming and configuration model is 
declarative - you describe how you want your component’s lifecycle to 
look using XML (or annotations to generate the XML). This XML is 
packaged into your bundle and used by a Service Component Runtime (an 
implementation of the DS specification) at runtime to find and manage 
your component.


Components on the other side have references and lifecycle methods, 
but in order to instantiate them programmatically I have to force a 
developer to annotate the class 
with @Component(scope=ServiceScope.PROTOTYPE) and then use 
ServiceObjects#getService() to instantiate/register it.


This procedure can be error-prone, e.g., when I assume that scope is 
always PROTOTYPE but the developer forgot to set it to this value. 
This problem came up during my discussion with Vaadin for a Flow-OSGi 
integration.


This is really a decision that needs to be made by the component 
developer. It doesn’t always make sense for a component to be 
PROTOTYPE scoped, and they need to be aware that there may be multiple 
instances created


In this context it would be great if there were a possibility to 
programmatically create components (not services) where I can tell 
SCR what fields/methods have to be treated as @Reference or lifecycle 
methods and let SCR do the heavy lifting.


This is not what SCR does. SCR is a declarative component model, not a 
programmatic one. There is no “DS builder API” for creating 
components. If you want a builder API for creating a component then 
you need to use a component framework that works in this way. As Ray 
pointed out in a previous mail chain there is the Apache Aries 
Component DSL. You could also use Apache Felix Dependency Manager.




Would such an API make sense? Or would it even be possible?


I think in general this would be very useful in order to create OSGi 
integrations for third-party libs that need to interact with DS in OSGi.


This isn’t really a question of third party libraries interacting with 
DS, it’s a request for a radically different component model with some 
DS-like capabilities. There are already framework implementations in 
the world that provide what you’re looking for, just not using DS.


Best Regards,

Tim


On 21 Feb 2019, at 18:07, Thomas Driessen via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Hi BJ,

sorry for being imprecise. I sometimes get confused regarding the 
proper naming in OSGi. I will try to clear things up by defining what 
my understanding is about services:


From my understanding there are two kinds of "services":
1) "Old school Services": I usually register those programmatically 
via context.registerService(...). Those services are just POJOs with 
a little bit metadata, i.e., properties, and a well-defined 

Re: [osgi-dev] Push Streams Event grouping and batching

[Jürgen Albert via osgi-dev]

ferred= null;
list= currentWindow;
currentWindow= null;
}
}


if(deferred != null) {
if(hitMaxSize) {
// We must resolve this way round to avoid racing
// the timeout and ending up with empty lists in
// all the promises
deferred.resolve(Collections.emptyList());
return promiseFactory.resolved(list);
} else {
final Collection finalList = list;
return deferred.getPromise()
.timeout(maxTime.toMillis())
.recover(x -> {
synchronized (lock) {
if(currentWindow == finalList) {
currentWindow = null;
currentDeferred= null;
return finalList;
}
}
return Collections.emptyList();
});
}
} else {
return promiseFactory.resolved(Collections.emptyList());
}
}


}




On 7 Jan 2019, at 11:25, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Thanks  Jürgen,

As I said that is what I went with and it is very satisfying
right now. As for pushback, I'm out of luck since the producer
is fully "disjoint" with a whiteboard pattern, but we have
configured ourselves with appropriated buffering But I'll keep
this code in mind, as we will surely have other patterns to
    support as we use push streams more and more.

Alain


On Mon, Jan 7, 2019 at 5:55 AM Jürgen Albert via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Hi Alain,

windowing would be your goto method. AFAIK there is not way
to extend a window, if you expect more messages to arrive.
Thus you would need to live with multiple batches, in case
of a prolonged burst. back pressure however is possible,
even if you use a buffer and/or windowing. The solution
would look like this:

psp.createPushStreamBuilder()
.withPushbackPolicy( q -> {
                            return Math.max(0, q.size() - 650);
                        })
.withQueuePolicy(QueuePolicyOption.BLOCK)
                    .withBuffer(new
ArrayBlockingQueue>(1200))
                        .build();

This PuschbackPolicy looks at the queue size and gradually
increases the pushback starting with one on the 651st element.

The grouping is another topic. The split method can do your
grouping, if you know what groups to expect. It essentially
returns an array of pushstreams correlating to each
predicate you give it. For everything else, you would need
to do the grouping for every batch you get with the usual
stream methods.

Regards,

Jürgen.

Am 05/01/2019 um 19:47 schrieb Alain Picard via osgi-dev:

For now I went with my simple solution of using a window
with just duration, and that is working fine, even if it
might not be the most optimal or streamlined approach.

Alain


On Sat, Jan 5, 2019 at 5:27 AM Alain Picard
mailto:pic...@castortech.com>> wrote:

Hi,

We are using push streams to process post-commit
events. Those events originate from different data
sources. At the moment we are processing those
individually, but the overhead of having a transaction
for each is too much. Quite often those events come in
bursts following an upstream transaction/ change set.

The goal is to group events by data source and batch
them, i.e. wait a bit when an event arrives to see if
others are also coming. If they keep coming, keep
collecting a bit longer, o/w move on.

I see that the PushStream has methods coalesce and
window. Window seems a bit more appropriate here, as it
offers both duration and maxEvents. But it seems to
operate all the time, and not start a batch upon
receiving an event, which doesn't sound optimal in this
case. More concerning to me is the comment regarding
back-pressure. We can't use back pressure (no control
on producer which is implemented via whiteboard. So
here the maxEvents is more a way to limit the batch and
not to indicate need for back pressure.

Still, that doesn't address grouping. See that there is
a fork, but that is made to deal with a fixed number of
child streams.

Would I just be best to use a window with just
duration, collect a number of events, then move on and
use a regular stream to group them and if necessary
batch them in smaller groups?

Cheers,

Alain


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org  <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/lis

Re: [osgi-dev] Push Streams Event grouping and batching

[Jürgen Albert via osgi-dev]

w = null;
currentDeferred= null;
return finalList;
}
}
return Collections.emptyList();
});
}
} else {
return promiseFactory.resolved(Collections.emptyList());
}
}


}




On 7 Jan 2019, at 11:25, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Thanks Jürgen,

As I said that is what I went with and it is very satisfying
right now. As for pushback, I'm out of luck since the producer is
fully "disjoint" with a whiteboard pattern, but we have
configured ourselves with appropriated buffering But I'll keep
this code in mind, as we will surely have other patterns to
    support as we use push streams more and more.

Alain


On Mon, Jan 7, 2019 at 5:55 AM Jürgen Albert via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Hi Alain,

windowing would be your goto method. AFAIK there is not way
to extend a window, if you expect more messages to arrive.
Thus you would need to live with multiple batches, in case of
a prolonged burst. back pressure however is possible, even if
you use a buffer and/or windowing.  The solution would look
like this:

psp.createPushStreamBuilder()
.withPushbackPolicy( q -> {
                            return Math.max(0, q.size() - 650);
                        })
.withQueuePolicy(QueuePolicyOption.BLOCK)
                    .withBuffer(new
ArrayBlockingQueue>(1200))
                        .build();

This PuschbackPolicy looks at the queue size and gradually
increases the pushback starting with one on the 651st element.

The grouping is another topic. The split method can do your
grouping, if you know what groups to expect. It essentially
returns an array of pushstreams correlating to each predicate
you give it. For everything else, you would need to do the
grouping for every batch you get with the usual stream methods.

Regards,

Jürgen.

Am 05/01/2019 um 19:47 schrieb Alain Picard via osgi-dev:

For now I went with my simple solution of using a window
with just duration, and that is working fine, even if it
might not be the most optimal or streamlined approach.

Alain


On Sat, Jan 5, 2019 at 5:27 AM Alain Picard
mailto:pic...@castortech.com>> wrote:

Hi,

We are using push streams to process post-commit events.
Those events originate from different data sources. At
the moment we are processing those individually, but the
overhead of having a transaction for each is too much.
Quite often those events come in bursts following an
upstream transaction/ change set.

The goal is to group events by data source and batch
them, i.e. wait a bit when an event arrives to see if
others are also coming. If they keep coming, keep
collecting a bit longer, o/w move on.

I see that the PushStream has methods coalesce and
window. Window seems a bit more appropriate here, as it
offers both duration and maxEvents. But it seems to
operate all the time, and not start a batch upon
receiving an event, which doesn't sound optimal in this
case. More concerning to me is the comment regarding
back-pressure. We can't use back pressure (no control on
producer which is implemented via whiteboard. So here
the maxEvents is more a way to limit the batch and not
to indicate need for back pressure.

Still, that doesn't address grouping. See that there is
a fork, but that is made to deal with a fixed number of
child streams.

Would I just be best to use a window with just duration,
collect a number of events, then move on and use a
regular stream to group them and if necessary batch them
in smaller groups?

Cheers,

Alain


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org  <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
Jürgen Albert

Geschäftsführer

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail:j.alb...@datainmotion.de  <mailto:j.alb...@datainmotion.de>
Web:www.datainmotion.de  <http://www.datainmotion.de/>

XING:https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Devel

Re: [osgi-dev] Push Streams Event grouping and batching

[Jürgen Albert via osgi-dev]

Hi Alain,

windowing would be your goto method. AFAIK there is not way to extend a 
window, if you expect more messages to arrive. Thus you would need to 
live with multiple batches, in case of a prolonged burst. back pressure 
however is possible, even if you use a buffer and/or windowing.  The 
solution would look like this:


psp.createPushStreamBuilder()
                        .withPushbackPolicy( q -> {
                            return Math.max(0, q.size() - 650);
                        })
.withQueuePolicy(QueuePolicyOption.BLOCK)
                    .withBuffer(new ArrayBlockingQueueextends EObject>>(1200))

                        .build();

This PuschbackPolicy looks at the queue size and gradually increases the 
pushback starting with one on the 651st element.


The grouping is another topic. The split method can do your grouping, if 
you know what groups to expect. It essentially  returns an array of 
pushstreams correlating to each predicate you give it. For everything 
else, you would need to do the grouping for every batch you get with the 
usual stream methods.


Regards,

Jürgen.

Am 05/01/2019 um 19:47 schrieb Alain Picard via osgi-dev:
For now I went with my simple solution of using a window with just 
duration, and that is working fine, even if it might not be the most 
optimal or streamlined approach.


Alain


On Sat, Jan 5, 2019 at 5:27 AM Alain Picard > wrote:


Hi,

We are using push streams to process post-commit events. Those
events originate from different data sources. At the moment we are
processing those individually, but the overhead of having a
transaction for each is too much. Quite often those events come in
bursts following an upstream transaction/ change set.

The goal is to group events by data source and batch them, i.e.
wait a bit when an event arrives to see if others are also coming.
If they keep coming, keep collecting a bit longer, o/w move on.

I see that the PushStream has methods coalesce and window. Window
seems a bit more appropriate here, as it offers both duration and
maxEvents. But it seems to operate all the time, and not start a
batch upon receiving an event, which doesn't sound optimal in this
case. More concerning to me is the comment regarding
back-pressure. We can't use back pressure (no control on producer
which is implemented via whiteboard. So here the maxEvents is more
a way to limit the batch and not to indicate need for back pressure.

Still, that doesn't address grouping. See that there is a fork,
but that is made to deal with a fixed number of child streams.

Would I just be best to use a window with just duration, collect a
number of events, then move on and use a regular stream to group
them and if necessary batch them in smaller groups?

Cheers,

Alain


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev



--
Jürgen Albert
Geschäftsführer

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de

XING:   https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Get Bundle for package and version

[Jürgen Albert via osgi-dev]

I needed to load the class first, because I only know its name, package 
and version. The RSA would load the class and it would ask my 
bundlecontext, to do it for him... Dynamic-ImportPackage did the trick 
here. I would prefere to establish a new bundle wiring on the fly, 
because I would know what package in what version I would need.


Am 12/11/2018 um 14:46 schrieb Thomas Watson:
Can you explain why you need to know the exporter in this case?  It 
sounds like you have to be using reflection to call the service, in 
which case I would not think the wiring mattered.  If you need to know 
exactly the exporting bundle of the API then one approach would be to 
get the service object and interrogate its class/interface hierarchy 
until you find the API class name you are looking for and then use 
FrameworkUtil.getBundle(Class) method.


Tom

- Original message -
From: "Jürgen Albert via osgi-dev" 
Sent by: osgi-dev-boun...@mail.osgi.org
To: osgi-dev@mail.osgi.org
Cc:
Subject: [osgi-dev] Get Bundle for package and version
Date: Mon, Nov 12, 2018 6:58 AM
Hi,

I have a whiteboard, that needs to consume a remote service.
Neither the
RSA that registers the service proxy nor my whiteboard that needs to
work with the interface has a wiring to the API Bundle. What the RSA
does tell me, is the packages and the versions of the API Interfaces.
Now I'm looking for a way to ge the appropriate bundle wiring. I
know, I
can iterate over all available Bundles, and look if one exports the
package in the given version, but AFAIK I can't be sure if this is the
right package, in case it was offered by multiple bundles.

What would be the right approach here?

Thx,

Jürgen.

--
Jürgen Albert
Geschäftsführer

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de

XING: https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev




--
Jürgen Albert
Geschäftsführer

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de

XING:   https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Get Bundle for package and version

[Jürgen Albert via osgi-dev]

Hi,

I have a whiteboard, that needs to consume a remote service. Neither the 
RSA that registers the service proxy nor my whiteboard that needs to 
work with the interface has a wiring to the API Bundle. What the RSA 
does tell me, is the packages and the versions of the API Interfaces. 
Now I'm looking for a way to ge the appropriate bundle wiring. I know, I 
can iterate over all available Bundles, and look if one exports the 
package in the given version, but AFAIK I can't be sure if this is the 
right package, in case it was offered by multiple bundles.


What would be the right approach here?

Thx,

Jürgen.

--
Jürgen Albert
Geschäftsführer

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de

XING:   https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Fwd: Eclipse Extension-points and EMF in OSGI

[Jürgen Albert via osgi-dev]

It appears that we are too stupid to configure the project properly. You 
can get started with this: 
https://gitlab.com/gecko.io/geckoEMF/wikis/Get-started



Am 09/08/2018 um 14:54 schrieb Alain Picard:


On Thu, Aug 9, 2018 at 8:45 AM Jürgen Albert via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Hi Alain,

EMF does work without extension points, but in its current state
needs manual registration of you EPackages.

Ok that is the interesting part.

The OSGi Compatibility option in the genmodel only defines the
org.eclipse.core.runtime as optional, which dues does not really
solve anything.

Agreed, not much.


We have an extension for EMF that solves this issue. You can have
EMF with any framework you like and without extension points. Have
a look here: https://gitlab.com/gecko.io/geckoEMF

Gitlab is reporting an error " An error occurred while loading commit 
signature" and not getting that error with the other gecko.io 
<http://gecko.io> project.




If you have any questions, feel free to ask.

Jürgen.

Am 09/08/2018 um 11:12 schrieb Tim Ward:




Begin forwarded message:

*From: *Tim Ward mailto:tim.w...@paremus.com>>
*Subject: **Re: [osgi-dev] Eclipse Extension-points and EMF in OSGI*
*Date: *9 August 2018 at 10:02:50 BST
*To: *Alain Picard mailto:pic...@castortech.com>>, OSGi Developer Mail List
mailto:osgi-dev@mail.osgi.org>>
*Cc: *Scott Lewis mailto:sle...@composent.com>>

I would expect that Mark Hoffman or Jürgen Albert might have
some useful pointers, I’m pretty sure that they’re heavy users
of EMF.

Best Regards,

Tim


On 9 Aug 2018, at 09:20, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Scott,

I noticed the split of the o.e.core.runtime and am already
using the o.e.equinox.common + supplement and running some
stuff like that with Felix. But that part doesn't include of
the support for extension points that is in the other "half",
hence my question.

Alain


On Thu, Aug 9, 2018 at 12:18 AM Scott Lewis via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

IOn 8/8/2018 7:43 AM, Alain Picard via osgi-dev wrote:
> Working through our move from RCP to a generic OSGI
solution, and I am
> stuck with a couple of questions.
>
> There was an issue a while ago for EMF that resulted in a
generation
> setting to support generic OSGI frameworks and not only
> Eclipse/Equinox. But the resulting bundles still have
plugin.xml and
> expose extension points. My understanding is that this
part of Eclipse
> is not covered in the portable part of o.e.core.runtime.
We also have
> a number of our own extension-points, some that we have
already
> converted and others that are still around.
>
> So anyone has successfully used EMF and/or Extension
points outside of
> a full Eclipse environment?

Yes wrt extension registry/extension points.

o.e.core.runtime is a split package, split between bundles
o.e.equinox.common and o.e.equinox.registry

I'm not sure of the justification for split packages, but I
think it was
done to maintain backward compatibility in eclipse plugins.

The version I used was a few years ago, but at that time
these two
bundles...along with equinox...would run the extension
registry (i.e.
process extension points/extensions on startup).  AFAIK
that's still the
case.

If you want to use a framework other than equinox, I know
for certain
that o.e.equinox.common works just fine on Felix...as long
as one also
includes this bundle [1].

I don't think EMF requires anything in addition to
o.e.equinox.common
and o.e.equinox.registry but I'm not completely sure about
that.

Scott

[1] org.eclipse.equinox.supplement  - available via equinox
or maven central


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev






-- 
Jürgen Albert

Geschäftsführer

Data In Motion Consulting GmbH (haftungsbeschränkt)

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail:j.alb...@datainmotion.de <mailto:j.alb...@datainmotion.de>
Web:www.datainmotion

Re: [osgi-dev] Fwd: Eclipse Extension-points and EMF in OSGI

[Jürgen Albert via osgi-dev]

Hi Alain,

EMF does work without extension points, but in its current state needs 
manual registration of you EPackages. The OSGi Compatibility option in 
the genmodel only defines the org.eclipse.core.runtime as optional, 
which dues does not really solve anything.


We have an extension for EMF that solves this issue. You can have EMF 
with any framework you like and without extension points. Have a look 
here: https://gitlab.com/gecko.io/geckoEMF


If you have any questions, feel free to ask.

Jürgen.

Am 09/08/2018 um 11:12 schrieb Tim Ward:




Begin forwarded message:

*From: *Tim Ward mailto:tim.w...@paremus.com>>
*Subject: **Re: [osgi-dev] Eclipse Extension-points and EMF in OSGI*
*Date: *9 August 2018 at 10:02:50 BST
*To: *Alain Picard >, OSGi Developer Mail List 
mailto:osgi-dev@mail.osgi.org>>

*Cc: *Scott Lewis mailto:sle...@composent.com>>

I would expect that Mark Hoffman or Jürgen Albert might have some 
useful pointers, I’m pretty sure that they’re heavy users of EMF.


Best Regards,

Tim

On 9 Aug 2018, at 09:20, Alain Picard via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Scott,

I noticed the split of the o.e.core.runtime and am already using the 
o.e.equinox.common + supplement and running some stuff like that 
with Felix. But that part doesn't include of the support for 
extension points that is in the other "half", hence my question.


Alain


On Thu, Aug 9, 2018 at 12:18 AM Scott Lewis via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


IOn 8/8/2018 7:43 AM, Alain Picard via osgi-dev wrote:
> Working through our move from RCP to a generic OSGI solution,
and I am
> stuck with a couple of questions.
>
> There was an issue a while ago for EMF that resulted in a
generation
> setting to support generic OSGI frameworks and not only
> Eclipse/Equinox. But the resulting bundles still have
plugin.xml and
> expose extension points. My understanding is that this part of
Eclipse
> is not covered in the portable part of o.e.core.runtime. We
also have
> a number of our own extension-points, some that we have already
> converted and others that are still around.
>
> So anyone has successfully used EMF and/or Extension points
outside of
> a full Eclipse environment?

Yes wrt extension registry/extension points.

o.e.core.runtime is a split package, split between bundles
o.e.equinox.common and o.e.equinox.registry

I'm not sure of the justification for split packages, but I
think it was
done to maintain backward compatibility in eclipse plugins.

The version I used was a few years ago, but at that time these two
bundles...along with equinox...would run the extension registry
(i.e.
process extension points/extensions on startup).  AFAIK that's
still the
case.

If you want to use a framework other than equinox, I know for
certain
that o.e.equinox.common works just fine on Felix...as long as
one also
includes this bundle [1].

I don't think EMF requires anything in addition to
o.e.equinox.common
and o.e.equinox.registry but I'm not completely sure about that.

Scott

[1] org.eclipse.equinox.supplement  - available via equinox or
maven central


___
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






--
Jürgen Albert
Geschäftsführer

Data In Motion Consulting GmbH (haftungsbeschränkt)

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de

XING:   https://www.xing.com/profile/Juergen_Albert5

Rechtliches

Jena HBR 513025

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev