Closed Legioth closed 5 years ago
Make sure the Model Proxy beans generated using Byte Buddy work as expected
👍
:+1:
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?
@Sandared @frieder Please note that it's more impactful to express your :+1: 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 :+1: reactions, whereas we might not open individual tickets to check if there happen to be :+1: comments there. At the same time, the number of :+1: in any location isn't the only input to our prioritization.
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?
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.
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.
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?
I would add two points to this list:
BundleResolver
, as currently in Vaadin 8 it only works with a FilesystemResolver
and a ClassloaderResolver
? 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:
For Vaadin 8 I implemented such a solution in Xtend, which you can see here
@Sandared
OSGi (and declarative services) support should be an absolute must in Vaadin 10, 11, 12 etc.
:thumbsup:
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.
We're using Vaadin 8 and OSGi in Liferay 7, and won't be able to migrate to flow until OSGi is supported.
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:
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.
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?
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.
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.