Initial OSGi support for Flow

[Legioth]

• Make sure that web resources handled by the Vaadin Servlet are available in OSGi #4229 Make sure that web resources handled by the Vaadin Servlet are available in OSGi
• OSGi: Use declarative service registration instead of programmatic for #4371 #4372 OSGi: Use declarative service registration instead of programmatic for OGSI: BootstrapHandler being in flow-server wants to access to the resources in flow-client #4371
• OSGi : RouteRegistryInitializer which is responsible for servlet initialization logic is not invoked in OSGi #4376 OSGi : RouteRegistryInitializer which is responsible for servlet initialization logic is not invoked in OSGi
• Spike: investigate proper way to support static resources in OSGi #4614 Spike: investigate proper way to support static resources in OSGi
• Use 1.2.0.vaadin1 version of gentyref library #4226 Use 1.2.0.vaadin1 version of gentyref library
• Automatic Flow tests for OSGi #4227 Automatic Flow tests for OSGi
• Simplify OSGi manifest generation #4232 Simplify OSGi manifest generation
• gwt-elemental is no OSGi compatible #4346 gwt-elemental is no OSGi compatible
• OGSI: BootstrapHandler being in flow-server wants to access to the resources in flow-client #4371 OGSI: BootstrapHandler being in flow-server wants to access to the resources in flow-client
• Spike: Investigate making all components & webjars an OSGi bundle with extracting & repackaging #4490 Spike: Investigate making all components & webjars an OSGi bundle with extracting & repackaging
• Make Button OSGi compatible bundle vaadin-button-flow#88 Make Button OSGi compatible bundle
• OSGi: Make all Flow components OSGi compatible #4630 OSGi: Make all Flow components OSGi compatible
• Verify that the platform is OSGi compatible #4658 Verify that the platform is OSGi compatible
• Documentation about making an component OSGi compatible bundle flow-and-components-documentation#302 Documentation about making an component OSGi compatible bundle
• Create another testing module for OSGi which uses different web container #4672 Create another testing module for OSGi which uses another web container- [ ] Project base for Flow and OSGi #4748 Project base for Flow and OSGi
• OSGi: enable root-context tests #4420 OSGi: enable root-context tests
• Make sure that static web resources are available in OSGi #4230 Make sure that static web resources are available in OSGi

[Artur-]

Make sure the Model Proxy beans generated using Byte Buddy work as expected

[Sandared]

👍

[frieder]

👍

[RaimundBarbeln]

We need OSGI Support for our project. We are currently injecting OSGI services into the UiProvider and ViewProviders. Since those providers no longer exist in Vaadin 10, how can we do that now?

[Legioth]

@Sandared @frieder Please note that it's more impactful to express your 👍 as a "reaction" on the issue itself compared to adding the same as a comment. The reason for this is that we occasionally look through the list of issues with most 👍 reactions, whereas we might not open individual tickets to check if there happen to be 👍 comments there. At the same time, the number of 👍 in any location isn't the only input to our prioritization.

[timothyjward]

We need OSGI Support for our project. We are currently injecting OSGI services into the UiProvider and ViewProviders. Since those providers no longer exist in Vaadin 10, how can we do that now?

It's really important that Vaadin components can use Declarative Services to inject OSGi services and configurations. I have previously used the UIProvider and ViewProvider to allow me to provide Vaadin with the DS managed objects (using prototype scope to get and release instances). What will the Vaadin 10 equivalent be?

[RaimundBarbeln]

I have previously used the UIProvider and ViewProvider to allow me to provide Vaadin with the DS managed objects (using prototype scope to get and release instances).

We do it exactly the same way in our project.
I am tasked with providing a proof of concept for migrating to Vaadin 10, but without the OSGI support I am lost.

[QNENet]

My project is 100% Vaadin and OSGi. I am not dependent on ViewProvider but I would be stuffed without UIProvider.
Is it not possible to retain in V10 or just a decision made without consideration for OSGi needs.

[Legioth]

Functionality similar to UIProvider and ViewProvider from Vaadin 8 and older is already available to some degree, though in a slightly different format. Please have a look at the Instantiator interface for that kind of functionality.

In addition to this, I can foresee a couple of things that would be necessary:

1. Support for registering and unregistering routes dynamically (i.e. when bundles are started and stopped)
2. Proper bundle metadata in each Vaadin .jar file.
3. Generally avoid doing things in ways that won't work in an OSGi environment, e.g. using Class.forName in specific ways
4. Regression testing to immediately discover any newly introduced issues specific to OSGi.

Anything else?

[Sandared]

I would add two points to this list:

1. Maybe the on-the-fly SASS compiler needs an additional BundleResolver, as currently in Vaadin 8 it only works with a FilesystemResolver and a ClassloaderResolver?
2. The current mechanism in Vaadin 8 to register resources via OSGiVaadinResources is flawed. In case the bundles are not started in the right order the current implementation leads to an Exception. A better solution would be to implement a BundleTracker that tracks all active bundles that have a specific resource haeder in their manifest, which points to the directory that shall be registered as resource/widgetset/theme at the HttpService. This approach has two benefits:
   • The compile-time dependencies to OSGi APIs in all non-OSGi vaadin-framework jars would be eliminated
   • All a developer has to do is to add one or two lines to the manifest of his resource/widgetset/theme jar instead of writing a service for each resource/theme/widgestset he wants to add. Also I think a manifest file is changed easier in an existing jar, than to add additional classes in case one wants to use a non-osgiified theme/widgetset/resource.

For Vaadin 8 I implemented such a solution in Xtend, which you can see here

[Legioth]

@Sandared

1. Vaadin 10 isn't based on Sass and there is therefore no on-the-fly compiler.
2. Let's that that into account when implementing anything.

[alexweirig]

OSGi (and declarative services) support should be an absolute must in Vaadin 10, 11, 12 etc.

👍

[rlegorreta]

The OSGiVaadinResources declares static global resources (widgets, themes, images and JS libraries) that are NOT independent from each bundle, they are global to Liferay DXP (i.e., the equinox OSGi). I think this approach breaks the rule that bundles has to be independent and just have an API.
For some peers in my team this is good but for me it breaks bundle independence and raise problems like bundle initialization. I believe it needs a better solution.
Mi concern is: the browser keeps all these resources in the client side (no bundle isolation)... the client side is not an OSGi micro code. How Vaadin 10 is going to match OSGi and keep bundle independence (API)..... maybe declaring bundle paths and release them at the browser memory.

[chrisnaan]

We're using Vaadin 8 and OSGi in Liferay 7, and won't be able to migrate to flow until OSGi is supported.

[pleku]

Just to clarify here to all who are eagerly waiting for the OSGi support in V10+ :

Vaadin 11 will not have OSGi support, unfortunately. Flow 1.1.0.beta1 is OSGI compatible, but the webjars used by the web component Java integrations are not OSGi compatible. Here is the issues for reference:

• Webjars are not OSGi compatible #4413
• Make WebJars support OSGi webjars/webjars#1307

If the webjars would get OSGi compatiblity, then we would be one step closer to the Vaadin platform being OSGi compatible. But this is not directly controlled by us so I cannot say whether this will happen or not (see the webjars issues for progress).

Our plan currently is to extract all the webjars/frontend dependencies (regardless of if webjars or another package manager like npm is used) and package them together as one single OSGi compatible bundle. This is something that you can already do yourself (when using Flow 1.1) but is not trivial. We want to make it easy.

The bad thing is that these things are not ready on time for Vaadin 11, and thus the next target is Vaadin 12 which will hit beta in beginning of November and everything should be done by then.

[flako-dd]

We also have a previous integration based on injecting UIProvider etc.
Would love to see flow to be compatible.
Is the Issue only the Manifest or are there specific class loading issues?

[Maurice-Betzel]

I am using Vaadin 8 / OSGi in a SCS architecture ( https://scs-architecture.org ) providing a working dynamic and modular setup. Having OSGi support within Vaadin is a crucial requirement. I do not want to build Web UIs in any other way anymore.

[rlhLegoSoft]

We are in similar position: we use Liferay DXP as a crucial requirement for our Customers. No step back. They use Liferay in many other ways (not just Vaadin). So Liferay DXP forces to use Vaadin 8/OSGi. And it is an excellent architecture.