A sketch for enhanced OSGi support in Flow

Hi,

I’ve followed the ongoing effort of making Flow OSGi capable. Thank you for this great work by the way. However, this effort seems to aim at merely making the Flow framework run within an OSGi container, but not to enable OSGi developers to incorporate Flow in a pure OSGi application, e.g., making heavy use of Declarative Services (the DI of OSGi).

Therefore, I have tried to sketch a solution on how we might enhance the current version of Flow to enable OSGi developers to make @Route/@RouteAlias annotated classes also be OSGi components whose lifecycle is controlled by OSGi instead of Flow. Additionally, this solution would not need any invasive code changes in Flow core, as the current solution does with classes like OSGiAccess and others, but merely would be an additional bundle that can be deployed if running in an OSGi container but doesn’t have to if Flow is used in another context. This would also be more similar to the OSGi integration offered by Vaadin 8.

As said above, I already have tried to sketch a possible solution that requires as few changes as possible to existing code. This with additional explanations on how this might work can be found here: https://github.com/Sandared/flow-osgi

This sketch is not yet working. The places where additional work and input is needed are commented with TODOs I’m sure I didn’t cover all aspects of what is needed to make such an enhanced integration work, as I’m not very familiar with the inner workings of Flow. So any feedback is highly welcome. 😃

Kind regards, Thomas

[Legioth]

Rather than FQCN, I’d then recommend using HasElement as the service type. Alternatively, a separate marker interface could maybe be introduced for this purpose, e.g. RouteComponent.

[Sandared]

@pleku / @mehdi-vaadin that’s good to hear. I just wanted to make sure that I’m not wasting your and my time with this issue 😉

I really would love to see this integration work out, so if you need anything regarding OSGi (tips/hints/design/explanations/implementations) I will gladly help you out whenever I can. Just write me.

BTW: From what I saw during digging through the framework code I think that the OSGi integration can even be done without (or just minimal) changes to other parts of the framework, so maybe we are able to free the core part of the framework from OSGi dependencies completely.