Vaadin 8.1.5 on OSGi, Shared not active after restart #10220
Comments
|
In the class OsgiVaadinResources, the getService method gets called before the BundleActivator start method gets hit.
After i installed Vaadin Server and the Default Widgetset AFTER the Vaadin Shared bundle all was OK. |
|
Import and export in the manifest should determine the startup sequence of the bundles. But both violating bundles have: Import-Package: com.vaadin.osgi.resources;version="[8.1.5,8.1.5]", ... |
|
I "solved" this for now by adding startup levels in my Karaf environment, but this is only a workaround. The startup of bundles should be determined on the dependency tree.
|
|
Oh boy the method call is a static one: public static VaadinResourceService getService() |
|
First attempt to implement a DS service to replace the static method call:
But the following exception appeared on calling Notification.show(route); in my login page:
Where did i screw up? |
|
I have encountered same issue. The following is the startup sequence of Liveray 7.0 GA5 with Vaadin 8.1.6 already deployed. An exception is thrown (in OsgiVaadinResources.getService method) while activating Vaadin-Liferay-Integration bundle, but in spite of this the module appears as STARTED. So when later Vaadin-Shared is started, Equinox does not attempt to start Vaadin-Liferay-Integration again. The result is that, for example, portlets in custom applications are not registered and made available. To solve the issue, Vaadin-Liferay-Integration has to be manually stopped and started in Gogo Shell (so, after Vaadin-Shared has been correctly started): I don't understand why Vaadin-Liferay-Integration appears as started even tough an exception is thrown, but the solution should be to add a specific dependency in Vaadin-Liferay-Integration's bnd.bnd to both Vaadin-Osgi-Integration and Vaadin-Shared. |
|
The problem are cross bundle static method calls into the Shared bundle. So if Shared is not an instance yet, it blows up in your face. |
|
Agree. Nevetheless when the exception is thrown, the whole Vaadin-Liferay-Integration installation should fail and the bundle should remain in "Resolved" state. |
|
Hello there! It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe. There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):
Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too! |
|
Hi, |
|
Nope, the issue is a static call between bundles (a #no go on OSGi) resulting in a forced startup sequence. |
|
Hello. I've been using Vaadin 8.2.0, but as far as I see the issue is still present in 8.4.5. The problem is in the bnd.bnd file in Vaadin Liferay Integration (VLI). The import-package dependency is simply "com.vaadin.*". This does not allow the OSGi runtime to detect an explicit dependency on some of the Vaadin modules (in particular, Vaadin Shared), preventing the right order of activation. The result is that VLI activator fails but the bundle is nevertheless marked as started. AFAIK, there are two solutions:
|
|
Hi all, |
|
Hello @geletejefazo18, sorry for my late response. I do agree that the cause of the problem is the static access between Vaadin bundles. Vaadin was originally compatible with Liferay 6 (not OSGi) and when Liferay 7 (OSGi) came out, it did not fully adapt to OSGi specs. Instead, some basic dependencies were put in bnd.bnd and some specific bridge modules (VLI) where added. |
|
Hello @geletejefazo18. Apparently, even if Vaadin Liferay Integration (VLI) bundle declares the correct dependencies, the Equinox runtime does not respect the correct order of startup, resulting in VLI started before Vaadin Shared, which causes the issue. PS: I saw that Vaadin OSGi Integration bundle calls the same problematic instruction ( |
|
Hi @ctliv Your solution seems to work! I've tested it a little bit and correct, now the bundle activator waits until vaadin-shared module is active. I'll test it more these days and let you know the outcome. Thanks! |
|
Good. You're welcome. |
|
hi, recently, we have quite a few changes on this related issue. Could you test your project with the new released framework version |
|
Hi @ZheSun88 , I've tested the version 8.6.0.alpha2 and seems to work. Deploying the vaadin-liferay-integration without having vaadin-shared deployed leads to the following exception: |
|
@geletejefazo18 Hi, thanks for verifying this. |
|
Hello @ZheSun88 , sorry for my delay in answering your request, but I'm currently working with Liferay CE 7.1.0 GA1 which has a further incompatibility with Vaadin, so I had to adapt Vaadin Server 8.6.0.beta1. I installed plain Liferay 7.1.0 GA1 and then have deployed Vaadin bundles in the following (explicitly wrong) order:
Then I deployed:
This was to check that Vaadin Liferay Integration awas able to detect Vaadin Shared. This is what I logged: So, the issue is still present. I repeated the procedure for Vaadin OSGi Integration:
In this case everything went well (but this had always been, as Vaadin OSGi Integration does not perform a call to Vaadin Shared at startup): So, to summarize, when Vaadin Liferay Integration is deployed (or started) before Vaadin Shared, the following error still occurs: |
|
But now, @ZheSun88 , there is also another problem with version 8.6.0.beta1. Vaadin Server does not corrently register "vaadinBootstrap.js.gz" and Valo Theme, so no Vaadin-based portlet actually runs. When undeploying Vaadin Shared here is what it is logged: So, in version 8.6.0.beta1 the issue described in this thread is still present, but there is also this new issue. |
|
Is this problem resolved with Vaadin 10/11 in Liferay 7.1? |
|
@bforster30 the new Vaadin platform (10 & 11) doesn't support Portals. Vaadin 12 will support OSGi, but not yet portals. There are some plans for adding portal support, but I cannot yet give any guarantee to which version (there are quarterly releases) or whether we will add specific support for Liferay. |
|
In that case, would it be a good idea for our company to move away from Vaadin for Liferay? |
|
Vaadin 8 has Liferay support and is supported until 2022, but as this issue and #11222, there are some things to fix with that. Before end of life for Vaadin 8, there will most likely be Portal support for the platform too, we just cannot give any exact timeline at the moment for that, or Liferay specific support (if there are any specific features needed, I hope not). |
|
As a workaround on Apache Karaf, i detect if any servlets are undeployed and then restart Vaadin shared programmatically. |
|
@swimmesberger pull request #11334 has solved the issue. I made a test with Vaadin 8.6.3 on Liferay CE 7.1.1 GA2 and the problem did not occur. If @Maurice-Betzel agrees, issue can be closed. |
|
Hello there! We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet. There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):
Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too! |
|
It looks this issue has been solved. closed for now |
|
Please reopen this ticket. The issue is still present. I am using Vaadin 8.8.3 with Liferay 7.2 and still getting the exception "Vaadin Shared is not active!". The problem is that the vaadin-liferay-integration bundle is already accessing resources of bundle vaadin-shared although the activator method of vaadin-shared hasn't finished. |
|
I merged the current master into #11335 , let us see the validation. |
|
I can confirm that Vaadin Portlets with version 8.8.3 are working with Liferay 7.2 when applying the changes of the pull request #11335. |
|
The patch will be released with Framework 8.9.0.alpha1 which would be released later today , please let us know if you have any further issues. |
Using: Windows 10 x64, Karaf 4.1.2, Vaadin 8.1.5, OPS4J Pax Web 6.0.6, Jetty 9.3.14
Observed after Karaf restart:
In webpage:
The Vaadin Shared bundle is active
if i restart the OPS4J PAX Web - Runtime and re-initiate the binding, everything hooks in fine and the page is available. There seems to be some timing issue some where i could not pinpoint yet.
I was not able to reproduce this problem on a stock Karaf with just Vaadin installed and HTTPS configured. OPS4J PAX Web configuration:
I am new to DS so i does somebody have a idea how i can delay startup?
The text was updated successfully, but these errors were encountered: