New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vaadin 8.1.5 on OSGi, Shared not active after restart #10220

Open
Maurice-Betzel opened this Issue Oct 20, 2017 · 27 comments

Comments

Projects
None yet
6 participants
@Maurice-Betzel

Maurice-Betzel commented Oct 20, 2017

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:

2017-10-20T10:21:22,497 | INFO | paxweb-config-1-thread-1 | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [org.ops4j.pax.web.pax-web-extender-whiteboard [112]] to http service
2017-10-20T10:21:22,497 | INFO | FelixStartLevel | CommandExtension | 59 - org.apache.karaf.shell.core - 4.1.2 | Updating commands for bundle org.apache.karaf.jaas.command/4.1.2
2017-10-20T10:21:22,505 | INFO | FelixStartLevel | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [com.vaadin.client-compiled [94]] to http service
2017-10-20T10:21:22,517 | ERROR | FelixStartLevel | client-compiled | 94 - com.vaadin.client-compiled - 8.1.5 | [com.vaadin.osgi.widgetset.DefaultWidgetsetContribution(2)] The startup method has thrown an exception
com.vaadin.osgi.resources.OsgiVaadinResources$ResourceBundleInactiveException: Vaadin Shared is not active!
at com.vaadin.osgi.resources.OsgiVaadinResources.getService(OsgiVaadinResources.java:66) [98:com.vaadin.shared:8.1.5]
at com.vaadin.osgi.widgetset.DefaultWidgetsetContribution.startup(DefaultWidgetsetContribution.java:35) [94:com.vaadin.client-compiled:8.1.5]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

In webpage:

Failed to load the bootstrap javascript: /vaadin-8.1.5/VAADIN/vaadinBootstrap.js?v=8.1.5

The Vaadin Shared bundle is active

96 │ Active │ 50 │ 8.1.5 │ Vaadin OSGi Integration
97 │ Active │ 50 │ 8.1.5 │ Vaadin Server
98 │ Active │ 50 │ 8.1.5 │ Vaadin Shared
99 │ Active │ 50 │ 8.1.5 │ Vaadin Themes

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:

org.osgi.service.http.enabled=false
org.osgi.service.http.port=8181
org.osgi.service.http.secure.enabled=true
org.osgi.service.http.port.secure=8443
javax.servlet.context.tempdir = ${karaf.data}/data/pax-web-jsp
org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/keystore/keystore.jks
org.ops4j.pax.web.ssl.password=***
org.ops4j.pax.web.ssl.keypassword=***
org.ops4j.pax.web.ssl.clientauthneeded=false
org.ops4j.pax.web.session.timeout=5
org.ops4j.pax.web.config.file = ${karaf.etc}/jetty.xml

I am new to DS so i does somebody have a idea how i can delay startup?

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Oct 20, 2017

In the class OsgiVaadinResources, the getService method gets called before the BundleActivator start method gets hit.
Following Bundles call OsgiVaadinResources getService() before it is initialized:

  • com.vaadin.osgi.widgetset.DefaultWidgetsetContribution on startup() (Default Widgetset bundle)
  • com.vaadin.server.osgi.BootstrapContribution on startup() (Vaadin Server bundle)

After i installed Vaadin Server and the Default Widgetset AFTER the Vaadin Shared bundle all was OK.

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Oct 20, 2017

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]", ...
So what am i missing? Both violating bundles should wait on Vaadin Shared (com.vaadin.osgi.resources) before kicking in.

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Oct 20, 2017

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.

<feature name="platform-ui-services" description="Vaadin ui components" version="${project.version}" start-level="50"> <feature version="${karaf.version}">scr</feature> <feature version="${karaf.version}">http</feature> <feature version="${karaf.version}">http-whiteboard</feature> <bundle start-level="80">mvn:org.jsoup/jsoup/${jsoup.version}</bundle> <bundle start-level="80">mvn:com.vaadin.external/gentyref/1.2.0.vaadin1</bundle> <bundle start-level="80">mvn:com.vaadin/vaadin-shared/${vaadin.version}</bundle> <bundle start-level="90">mvn:com.vaadin/vaadin-server/${vaadin.version}</bundle> <bundle start-level="90">mvn:com.vaadin/vaadin-osgi-integration/${vaadin.version}</bundle> <bundle start-level="90">mvn:com.vaadin/vaadin-client-compiled/${vaadin.version}</bundle> <bundle start-level="90">mvn:com.vaadin/vaadin-themes/${vaadin.version}</bundle> </feature>

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Oct 20, 2017

Oh boy the method call is a static one: public static VaadinResourceService getService()
How did i mis that, my brain was not expecting this in a OSGi environment. Lets make it a OSGi service...

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Oct 21, 2017

First attempt to implement a DS service to replace the static method call:
https://github.com/Maurice-Betzel/framework
Restarting with 8.2-SNAPSHOT now working as expected for a OSGi framework, loggings and HTTP service list identical to 8.1.5:

2017-10-21T15:34:22,439 | INFO | FelixStartLevel | Activator | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Pax Web started
2017-10-21T15:34:22,792 | INFO | paxweb-config-1-thread-1 | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [org.ops4j.pax.web.pax-web-extender-whiteboard [112]] to http service

2017-10-21T15:34:22,820 | INFO | FelixStartLevel | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [com.vaadin.client-compiled [94]] to http service
2017-10-21T15:34:22,964 | INFO | FelixStartLevel | HttpServiceContext | 91 - org.ops4j.pax.web.pax-web-jetty - 6.0.6 | registering context DefaultHttpContext [bundle=com.vaadin.client-compiled [94], contextID=default], with context-name:
2017-10-21T15:34:23,017 | INFO | FelixStartLevel | ContextHandler | 81 - org.eclipse.jetty.util - 9.3.14.v20161028 | Started HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.vaadin.client-compiled [94], contextID=default]}

2017-10-21T15:34:23,087 | INFO | FelixStartLevel | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [com.vaadin.server [97]] to http service
2017-10-21T15:34:24,036 | INFO | FelixStartLevel | HttpServiceContext | 91 - org.ops4j.pax.web.pax-web-jetty - 6.0.6 | registering context DefaultHttpContext [bundle=com.vaadin.server [97], contextID=default], with context-name:
2017-10-21T15:34:24,042 | INFO | FelixStartLevel | ContextHandler | 81 - org.eclipse.jetty.util - 9.3.14.v20161028 | Started HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.vaadin.server [97], contextID=default]}

2017-10-21T15:34:24,048 | INFO | FelixStartLevel | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [com.vaadin.shared [98]] to http service

2017-10-21T15:34:24,057 | INFO | FelixStartLevel | HttpServiceFactoryImpl | 92 - org.ops4j.pax.web.pax-web-runtime - 6.0.6 | Binding bundle: [com.vaadin.themes [99]] to http service
2017-10-21T15:34:24,090 | INFO | FelixStartLevel | HttpServiceContext | 91 - org.ops4j.pax.web.pax-web-jetty - 6.0.6 | registering context DefaultHttpContext [bundle=com.vaadin.themes [99], contextID=default], with context-name:
2017-10-21T15:34:24,097 | INFO | FelixStartLevel | ContextHandler | 81 - org.eclipse.jetty.util - 9.3.14.v20161028 | Started HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.vaadin.themes [99], contextID=default]}

But the following exception appeared on calling Notification.show(route); in my login page:

2017-10-21T16:27:55,048 | ERROR | qtp1832689345-124 | DefaultErrorHandler | 97 - com.vaadin.server - 8.2.0.201710211245 |
java.lang.NoSuchMethodError: com.vaadin.ui.Notification.show(Ljava/lang/String;)V
at eu.abeel.platform.ria.VaadinloginUI.router(VaadinloginUI.java:49) ~[114:eu.abeel.platform.ria.layout:1.0.0.201710211312]
at eu.abeel.platform.ria.VaadinloginUI.init(VaadinloginUI.java:45) ~[114:eu.abeel.platform.ria.layout:1.0.0.201710211312]
at com.vaadin.ui.UI.doInit(UI.java:778) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(UIInitHandler.java:218) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(UIInitHandler.java:76) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1588) [97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:445) [97:com.vaadin.server:8.2.0.201710211245]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [18:javax.servlet-api:3.1.0]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) [79:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [79:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [91:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [76:org.eclipse.jetty.security:9.3.14.v20161028]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [91:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [79:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [91:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.Server.handle(Server.java:534) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at java.lang.Thread.run(Thread.java:748) [?:?]
2017-10-21T16:27:55,060 | WARN | qtp1832689345-124 | ServletHandler | 81 - org.eclipse.jetty.util - 9.3.14.v20161028 |
javax.servlet.ServletException: com.vaadin.server.ServiceException: java.lang.NoSuchMethodError: com.vaadin.ui.Notification.show(Ljava/lang/String;)V
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:447) [97:com.vaadin.server:8.2.0.201710211245]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [18:javax.servlet-api:3.1.0]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) [79:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [79:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [91:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [76:org.eclipse.jetty.security:9.3.14.v20161028]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [91:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [79:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [91:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.Server.handle(Server.java:534) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [78:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [70:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [81:org.eclipse.jetty.util:9.3.14.v20161028]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: com.vaadin.server.ServiceException: java.lang.NoSuchMethodError: com.vaadin.ui.Notification.show(Ljava/lang/String;)V
at com.vaadin.server.VaadinService.handleExceptionDuringRequest(VaadinService.java:1640) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1600) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:445) ~[97:com.vaadin.server:8.2.0.201710211245]
... 30 more
Caused by: java.lang.NoSuchMethodError: com.vaadin.ui.Notification.show(Ljava/lang/String;)V
at eu.abeel.platform.ria.VaadinloginUI.router(VaadinloginUI.java:49) ~[114:eu.abeel.platform.ria.layout:1.0.0.201710211312]
at eu.abeel.platform.ria.VaadinloginUI.init(VaadinloginUI.java:45) ~[114:eu.abeel.platform.ria.layout:1.0.0.201710211312]
at com.vaadin.ui.UI.doInit(UI.java:778) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(UIInitHandler.java:218) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(UIInitHandler.java:76) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1588) ~[97:com.vaadin.server:8.2.0.201710211245]
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:445) ~[97:com.vaadin.server:8.2.0.201710211245]

Where did i screw up?

@ctliv

This comment has been minimized.

ctliv commented Nov 7, 2017

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.

09:42:15,505 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.osgi.integration_8.1.6 [518]
09:42:15,510 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.server_8.1.6 [517]
09:42:15,513 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.external.gentyref_1.2.0.vaadin1 [515]
09:42:15,532 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED org.jsoup_1.8.3 [514]
09:42:15,543 ERROR [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][com_vaadin_liferay_integration:97] [com.vaadin.osgi.liferay.VaadinPortletProvider(38)] The activate method has thrown an exception 
com.vaadin.osgi.resources.OsgiVaadinResources$ResourceBundleInactiveException: Vaadin Shared is not active!
	at com.vaadin.osgi.resources.OsgiVaadinResources.getService(OsgiVaadinResources.java:66)
	at com.vaadin.osgi.liferay.VaadinPortletProvider.activate(VaadinPortletProvider.java:55)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
		[...]
09:42:15,547 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.liferay.integration_8.1.6 [535]
09:42:15,558 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.shared_8.1.6 [516]
09:42:15,562 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.themes_8.1.6 [520]
09:42:15,565 INFO  [fileinstall-/opt/liferay-ce-portal-7.0-ga5/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.client-compiled_8.1.6 [519]

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):

____________________________
Welcome to Apache Felix Gogo

g! lb
START LEVEL 20
   ID|State      |Level|Name
    0|Active     |    0|OSGi System Bundle (3.10.200.v20150831-0856)
		[...]
  514|Active     |   10|jsoup (1.8.3)
  515|Active     |   10|GenTyRef (1.2.0.vaadin1)
  516|Active     |   10|Vaadin Shared (8.1.6)
  517|Active     |   10|Vaadin Server (8.1.6)
  518|Active     |   10|Vaadin OSGi Integration (8.1.6)
  519|Active     |   10|Default Widgetset (8.1.6)
  520|Active     |   10|Vaadin Themes (8.1.6)
  535|Active     |   10|Vaadin Liferay Integration (8.1.6)
g! stop 535
g! start 535
g!

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.

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Nov 8, 2017

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.

@ctliv

This comment has been minimized.

ctliv commented Nov 12, 2017

Agree. Nevetheless when the exception is thrown, the whole Vaadin-Liferay-Integration installation should fail and the bundle should remain in "Resolved" state.

@stale

This comment has been minimized.

stale bot commented Apr 11, 2018

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):

  • Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
  • Provide more details how to reproduce the issue.
  • Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
  • Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
  • Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
  • If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

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!

@stale stale bot added the Stale label Apr 11, 2018

@geletejefazo18

This comment has been minimized.

geletejefazo18 commented Jul 11, 2018

Hi,
I have encountered the same issue for Vaadin 8.4.2 already deployed using Liferay DXP
After a restart or after applying a patch in Liferay Vaadin portlets are shown as undeployed in the web page, they cannot be added to a page anymore even though all the portlets and vaadin modules are Active in the go go shell console. The problem is the same described above, an exception is thrown while activating vaadin-liferay-integration because vaadin-shared is not active but anyway vaadin-liferay-integration appears STARTED even though it is not true and therefore the portlets do not work. The workaround is to stop and start the module vaadin-liferay-integration but vaadin should keep this module in resolved state until the dependencies are available.
Did you manage to fix this issue differently?

@stale stale bot removed the Stale label Jul 11, 2018

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Jul 11, 2018

Nope, the issue is a static call between bundles (a #no go on OSGi) resulting in a forced startup sequence.

@ctliv

This comment has been minimized.

ctliv commented Jul 16, 2018

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:

  • Manually stop and start (using Gogo shell) VLI bundle after every restart of Liferay.
  • Use a modified version of VLI bundle that I have made. The only difference from the official is that there is an explicit dependency from "com.vaadin.shared*" (there is no bnd.bnd file because I use Apache Felix Maven Bundle Plugin which allows to write OSGi manifest data in pom.xml). Just clone repository, change Vaadin version (currently is: "8.2.0"), call "mvn package", install VLI-fix and finally remove original VLI.
@geletejefazo18

This comment has been minimized.

geletejefazo18 commented Jul 16, 2018

Hi all,
Thanks for your replies. I've been trying to modify the bnd file of liferay-integration so it takes vaadin-shared as a dependency that must have before activating the module but I haven't succeeded.
@ctliv I've also deployed your modified version of the VLI (thanks!) whose aim is to achieve what I was trying to find but still happens the same. Stopping vaadin-shared and then deploying again vaadin-liferay-integration-fix shows the same problem of Vaadin-Shared is not active!
I think the problem lays on the static call between bundles mentioned by @Maurice-Betzel . vaadin-liferay calls the static method of OsgiVaadinResources (vaadin-shared) before vaadin-shared being active, Vaadin shared should have included a Reference annotation instead of a static call. For me having to stop and start is not a proper solution, I don't understand why Vaadin states in the its website that is compatible with Liferay 7, that is not tru to me. Every time the server restarts your portlets may disappear so you will have to stop and start manually vaadin-liferay-integration. This seems to be a bug to me.

@ctliv

This comment has been minimized.

ctliv commented Jul 30, 2018

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.
It's strange that my simple VLI-fix doesn't work as expected, because it works in another (single and not in production) environment I tested it in. An advice I may give you is to strictly respect, upon initial Vaadin installation in the OSGi runtime, the order suggested by Vaadin itself (which is, BTW, a violation of OSGi spec, because correct import/export dependencies should let the runtime automatically figure out the correct order of bundle activations). The order is: Jsoup, Gentyref, Vaadin Shared, Vaadin Server, Vaadin OSGi integration, Vaadin Client Compiled, Vaadin Themes, Vaadin Liferay Ingteration (fix).

@ctliv

This comment has been minimized.

ctliv commented Aug 13, 2018

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.
I have now updated VLI-fix adding a Bundle Activator that checks every 5 seconds for Vaadin Shared until no error is returned, thus forcing the correct startup order. I made some tests and things seem to work, now.

PS: I saw that Vaadin OSGi Integration bundle calls the same problematic instruction (VaadinResourceService service = OsgiVaadinResources.getService()), though not at bundle startup. In any case, I have developed a similar fix.

@geletejefazo18

This comment has been minimized.

geletejefazo18 commented Aug 14, 2018

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!

@ctliv

This comment has been minimized.

ctliv commented Aug 14, 2018

Good. You're welcome.

@ZheSun88

This comment has been minimized.

Contributor

ZheSun88 commented Sep 26, 2018

hi, recently, we have quite a few changes on this related issue. Could you test your project with the new released framework version 8.6.0.alpha2? Thanks.

@geletejefazo18

This comment has been minimized.

geletejefazo18 commented Sep 28, 2018

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:
Could not resolve module: com.vaadin.liferay.integration [1406]_ Unresolved requirement: Import-Package: com.vaadin.osgi.resources; version="[8.6.0,8.6.0]"_ [Sanitized]
Which is correct, and leaves the module Installed instead of Active.
Once vaadin-shared is deployed, vaadin-liferay-integration starts - so that would solve the issue when starting up Liferay.
Is Vaadin 8.6.0 the one that is going to contain this fix? Does a previous release contain the same fix?
Thanks

@ZheSun88

This comment has been minimized.

Contributor

ZheSun88 commented Oct 1, 2018

@geletejefazo18 Hi, thanks for verifying this.
To answer the questions related to the released version which contains this change, Yes, 8.6.0 (would be released by the end of October 2018) will be the first stable version containing it, and before that, pre-release 8.6.0.alpha2 and 8.6.0.beta1 can be used.
Thanks again.

@ctliv

This comment has been minimized.

ctliv commented Oct 5, 2018

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:

  • jsoup-1.11.3.jar
  • gentyref-1.2.0.vaadin1.jar
  • vaadin-server-8.6.0.beta1.jar
  • vaadin-client-compiled-8.6.0.beta1.jar
  • vaadin-themes-8.6.0.beta1.jar
  • vaadin-liferay-integration-8.6.0.beta1.jar

Then I deployed:

  • vaadin-shared-8.6.0.beta1.jar

This was to check that Vaadin Liferay Integration awas able to detect Vaadin Shared. This is what I logged:

2018-10-05 08:54:08.027 ERROR [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][com_vaadin_liferay_integration:97] [com.vaadin.osgi.liferay.VaadinPortletProvider(3840)] The activate method has thrown an exception
com.vaadin.osgi.resources.OsgiVaadinResources$ResourceBundleInactiveException: Vaadin Shared is not active!
        at com.vaadin.osgi.resources.OsgiVaadinResources.getService(OsgiVaadinResources.java:66)
        at com.vaadin.osgi.liferay.VaadinPortletProvider.activate(VaadinPortletProvider.java:53)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       [...]
2018-10-05 08:54:08.033 INFO  [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][BundleStartStopLogger:35] STARTED com.vaadin.liferay.integration_8.6.0.beta1 [1005]
2018-10-05 08:54:08.265 INFO  [fileinstall-/opt/liferay-ce-portal-7.1.0-ga1/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.shared_8.6.0.beta1 [1006]

So, the issue is still present.

I repeated the procedure for Vaadin OSGi Integration:

  • vaadin-osgi-integration-8.6.0.beta1.jar

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):

2018-10-05 08:59:45.373 INFO  [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][AutoDeployDir:261] Processing vaadin-osgi-integration-8.6.0.beta1.jar
2018-10-05 08:59:54.441 INFO  [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][AutoDeployDir:261] Processing vaadin-shared-8.6.0.beta1.jar
2018-10-05 09:00:00.478 INFO  [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][BundleStartStopLogger:35] STARTED com.vaadin.server_8.6.0.beta1 [1002]
2018-10-05 09:00:00.495 INFO  [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][BundleStartStopLogger:35] STARTED com.vaadin.client-compiled_8.6.0.beta1 [1003]
2018-10-05 09:00:00.509 INFO  [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][BundleStartStopLogger:35] STARTED com.vaadin.themes_8.6.0.beta1 [1004]
2018-10-05 09:00:00.565 INFO  [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][BundleStartStopLogger:35] STARTED com.vaadin.osgi.integration_8.6.0.beta1 [1008]
2018-10-05 09:00:00.898 INFO  [fileinstall-/opt/liferay-ce-portal-7.1.0-ga1/osgi/modules][BundleStartStopLogger:35] STARTED com.vaadin.shared_8.6.0.beta1 [1009]

So, to summarize, when Vaadin Liferay Integration is deployed (or started) before Vaadin Shared, the following error still occurs:

2018-10-05 08:54:08.027 ERROR [Refresh Thread: Equinox Container: d0ebbec2-6ec8-0018-1875-feb9bf5e3c64][com_vaadin_liferay_integration:97] [com.vaadin.osgi.liferay.VaadinPortletProvider(3840)] The activate method has thrown an exception
com.vaadin.osgi.resources.OsgiVaadinResources$ResourceBundleInactiveException: Vaadin Shared is not active!
        at com.vaadin.osgi.resources.OsgiVaadinResources.getService(OsgiVaadinResources.java:66)
@ctliv

This comment has been minimized.

ctliv commented Oct 5, 2018

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:

2018-10-05 09:08:13.018 ERROR [fileinstall-/opt/liferay-ce-portal-7.1.0-ga1/osgi/modules][com_vaadin_shared:97] [com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent(3847)] The deactivate method has thrown an exception
java.lang.IllegalStateException: The service has been unregistered
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:206)
        at com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent.deactivate(VaadinResourceTrackerComponent.java:225)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       [...]
2018-10-05 09:08:13.028 ERROR [fileinstall-/opt/liferay-ce-portal-7.1.0-ga1/osgi/modules][com_vaadin_shared:97] [com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent(3847)] The unbindWidgetset method has thrown an exception
java.lang.IllegalArgumentException: The bundle did not register the alias: /vaadin-8.6.0.beta1/VAADIN/widgetsets/com.vaadin.DefaultWidgetSet
        at org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.unregisterHttpServiceAlias(HttpServiceRuntimeImpl.java:785)
       [...]
2018-10-05 09:08:13.033 ERROR [fileinstall-/opt/liferay-ce-portal-7.1.0-ga1/osgi/modules][com_vaadin_shared:97] [com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent(3847)] The unbindTheme method has thrown an exception
java.lang.IllegalArgumentException: The bundle did not register the alias: /vaadin-8.6.0.beta1/VAADIN/themes/valo
        at org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.unregisterHttpServiceAlias(HttpServiceRuntimeImpl.java:785)
       [...]
2018-10-05 09:08:13.044 INFO  [fileinstall-/opt/liferay-ce-portal-7.1.0-ga1/osgi/modules][BundleStartStopLogger:38] STOPPED com.vaadin.shared_8.6.0.beta1 [1009]

So, in version 8.6.0.beta1 the issue described in this thread is still present, but there is also this new issue.

@bforster30

This comment has been minimized.

bforster30 commented Nov 5, 2018

Is this problem resolved with Vaadin 10/11 in Liferay 7.1?

@pleku

This comment has been minimized.

Contributor

pleku commented Nov 5, 2018

@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.

@bforster30

This comment has been minimized.

bforster30 commented Nov 5, 2018

In that case, would it be a good idea for our company to move away from Vaadin for Liferay?

@pleku

This comment has been minimized.

Contributor

pleku commented Nov 5, 2018

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).

@Maurice-Betzel

This comment has been minimized.

Maurice-Betzel commented Nov 10, 2018

As a workaround on Apache Karaf, i detect if any servlets are undeployed and then restart Vaadin shared programmatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment