[osgi-dev] Remote service (thread) context properties?

[Bernd Eckenfels via osgi-dev]

When I use a Remote Service for distributed OSGi application I would like my 
provider to be able to implicitly pass some thread context like tracing IDs and 
also a user authorization token.

The OSGi compendium talks about implementation specific security based on 
codesigning, but not on thread identity (JAAS Context). Was there any plan to 
add something, like an interceptor mechanism?

Some of it could be implementation specific, but some form of portable endpoint 
binding access would be nice, like peer-address, jaas-context, opentracing-id, 
maybe audit, tenant and request-ids?

I can enrich my services with a Map for most of it, however then 
there is no reliable way for the provider to add/ensure some of its protocol 
header properties and it hides the business interface under removing parameters.

Gruss
Bernd
--
http://bernd.eckenfels.net
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

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

[Alain Picard via osgi-dev]

Tim,

Finally got around to this debouncer, and I tested to change the sleep
time. When I set it to like 800 to 1500, it never completes after shoing
"Closing the Generator". At 500, I get a Queue full that I can understand.
So why the hang?

Alain



On Mon, Jan 7, 2019 at 8:11 AM Tim Ward  wrote:

> This use case is effectively a “debouncing” behaviour, which is possible
> to implement with a little thought.
>
> There are a couple of ways to attempt it. This one uses the asyncMap
> operation to asynchronously gather the events until it either times out the
> promise or it hits the maximum stream size. Note that you have to filter
> out the “empty” lists that are used to resolve the promises which are being
> aggregated into the window. The result of this is a window which starts on
> the first event arrival and then buffers the events for a while. The next
> window isn’t started until the next event
>
>
> Best Regards,
>
> Tim
>
>
> @Test
> public void testWindow2() throws InvocationTargetException,
> InterruptedException {
>
> PushStreamProvider psp = new PushStreamProvider();
>
> SimplePushEventSource sps = psp.createSimpleEventSource(Integer.
> class);
>
> Promise>> result = psp.createStream(sps)
> .asyncMap(2, 0, new StreamDebouncer(
> new PromiseFactory(PromiseFactory.inlineExecutor()),
> 10, Duration.ofSeconds(1)))
> .filter(c -> !c.isEmpty())
> .collect(Collectors.toList());
>
> new Thread(() -> {
>
> for (int i = 0; i < 200;) {
>
> for (int j = 0; j < 23; j++) {
> sps.publish(i++);
> }
>
> try {
> System.out.println("Burst finished, now at " + i);
> Thread.sleep(2000);
> } catch (InterruptedException e) {
> sps.error(e);
> break;
> }
> }
>
> System.out.println("Closing generator");
> sps.close();
>
> }).start();
>
> System.out.println(result.getValue().toString());
>
> }
>
>
> public static class StreamDebouncer implements Function extends Collection>> {
>
> private final PromiseFactory promiseFactory;
> private final int maxSize;
> private final Duration maxTime;
>
>
> private final Object lock = new Object();
>
>
> private List currentWindow;
> private Deferred> currentDeferred;
>
> public StreamDebouncer(PromiseFactory promiseFactory, int maxSize,
> Duration maxTime) {
> this.promiseFactory = promiseFactory;
> this.maxSize = maxSize;
> this.maxTime = maxTime;
> }
>
> @Override
> public Promise> apply(T t) throws Exception {
>
>
> Deferred> deferred = null;
> Collection list = null;
> boolean hitMaxSize = false;
> synchronized (lock) {
> if(currentWindow == null) {
> currentWindow = new ArrayList<>(maxSize);
> currentDeferred = promiseFactory.deferred();
> deferred = currentDeferred;
> list = currentWindow;
> }
> currentWindow.add(t);
> if(currentWindow.size() == maxSize) {
> hitMaxSize = true;
> deferred = currentDeferred;
> currentDeferred = 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 
> 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 <
> 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> extends 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 

[osgi-dev] Removing queued events in Push Steams

[Alain Picard via osgi-dev]

Hi,

We have cases where we need to process events with different priorities,
and such priority can change after the initial event having been queued,
but not yet processed.

For example, when there is an event that some content has changed, we
subscribe to this event and based on some conditions this might trigger the
need to update some diagrams in our case. This is considered a "background
priority" event, since we simply want to get it updated when we have some
cycles so as not being stuck doing it whenever someone requests such
diagram to view/edit it.

We also have events when someone for example requests to open such a
diagram, where we need to determine if it is up to date, and if it needs to
be updated, to get this pushed and processed as quickly as possible, as the
user is waiting.

So far we have setup 2 different push streams to support this.

The issue here is that while this is high-priority event comes in, we need
to make sure that we can cancel any similar queued events from the low
priority stream, and possibly let it proceed if it is already being
processed.

What is the best approach here ? Are we on the right track to start with?

Thanks
Alain
___
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?

[Thomas Driessen via osgi-dev]

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

Re: [osgi-dev] enRoute Project archetype not working correctly?

[Tim Ward via osgi-dev]

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

[Thomas Driessen via osgi-dev]

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