framework
framework copied to clipboard
vaadin
NamespaceException thrown with OSGi application when using Karaf 4.2
This exception is logged and when one tries to access the application there is an error shown in browser
"Failed to load the bootstrap javascript: /vaadin-8.13.3/VAADIN/vaadinBootstrap.js?v=8.13.3"
It looks like that exception is thrown before https://github.com/vaadin/framework/blob/master/server/src/main/java/com/vaadin/server/osgi/BootstrapContribution.java is applied, thus bootstrap loading fails.
Used Karaf 4.2.11, Vaadin 8.13.3
2021-09-07T20:13:22,515 | ERROR | pipe-bundle:install -s mvn:org.vaadin.mmerruko/osgidashboard-demo/1.0 | WebApplication | 100 - org.ops4j.pax.web.pax-web-extender-whiteboard - 7.2.23 | Registration skipped for [ResourceWebElement{mapping=DefaultResourceMapping{httpContextId=com.vaadin,alias=/VAADIN/themes/demotheme/*,path=/VAADIN/themes/demotheme}}] due to error during registration
org.osgi.service.http.NamespaceException: alias: '/vaadin-8.13.3/VAADIN/themes/demotheme/*' is already in use in this or another context
at org.ops4j.pax.web.service.spi.model.ServerModel.addServletModel(ServerModel.java:124) ~[?:?]
at org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:246) ~[?:?]
at org.ops4j.pax.web.service.internal.HttpServiceStarted.registerResources(HttpServiceStarted.java:310) ~[?:?]
at org.ops4j.pax.web.service.internal.HttpServiceProxy.registerResources(HttpServiceProxy.java:76) ~[?:?]
at org.ops4j.pax.web.extender.whiteboard.internal.element.ResourceWebElement.register(ResourceWebElement.java:57) ~[!/:?]
at org.ops4j.pax.web.extender.whiteboard.internal.WebApplication.registerWebElement(WebApplication.java:392) [!/:?]
at org.ops4j.pax.web.extender.whiteboard.internal.WebApplication.addWebElement(WebApplication.java:199) [!/:?]
at org.ops4j.pax.web.extender.whiteboard.internal.tracker.AbstractTracker.addingService(AbstractTracker.java:193) [!/:?]
at org.ops4j.pax.web.extender.whiteboard.internal.tracker.AbstractTracker.addingService(AbstractTracker.java:46) [!/:?]
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) [osgi.core-6.0.0.jar:?]
at org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.Felix.registerService(Felix.java:3587) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:355) [org.apache.felix.framework-5.6.12.jar:?]
at com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent$Delegate.registerImpl(VaadinResourceTrackerComponent.java:314) [!/:8.13.3]
at com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent$Delegate.register(VaadinResourceTrackerComponent.java:244) [!/:8.13.3]
at com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent.registerResource(VaadinResourceTrackerComponent.java:193) [!/:8.13.3]
at com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent.bindTheme(VaadinResourceTrackerComponent.java:67) [!/:8.13.3]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_162]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_162]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162]
at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) [!/:?]
at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) [!/:?]
at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) [!/:?]
at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) [!/:?]
at org.apache.felix.scr.impl.inject.methods.BindMethod.invoke(BindMethod.java:42) [!/:?]
at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:2083) [!/:?]
at org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:2058) [!/:?]
at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeBindMethod(SingleComponentManager.java:443) [!/:?]
at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.addedService(DependencyManager.java:333) [!/:?]
at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.addedService(DependencyManager.java:301) [!/:?]
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1200) [!/:?]
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1121) [!/:?]
at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:928) [!/:?]
at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:864) [!/:?]
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1152) [!/:?]
at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:114) [!/:?]
at org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.Felix.registerService(Felix.java:3587) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:929) [!/:?]
at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:915) [!/:?]
at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133) [!/:?]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:984) [!/:?]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:752) [!/:?]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:674) [!/:?]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:437) [!/:?]
at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:667) [!/:?]
at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:305) [!/:?]
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:554) [!/:?]
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:70) [!/:?]
at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:421) [!/:?]
at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196) [!/:?]
at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169) [!/:?]
at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49) [!/:?]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) [osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [osgi.core-6.0.0.jar:?]
at org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4579) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2174) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) [org.apache.felix.framework-5.6.12.jar:?]
at org.apache.karaf.bundle.command.Install.execute(Install.java:115) [!/:?]
at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) [!/:4.2.11]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [!/:4.2.11]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [!/:4.2.11]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) [!/:4.2.11]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) [!/:4.2.11]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) [!/:4.2.11]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) [!/:4.2.11]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) [!/:4.2.11]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [!/:4.2.11]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_162]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
This exception doesn't look like it's related to the cores ResourceContribution but more like double registration of the theme. Could it be that there's some other bundle that registers that same theme path?
The missing bootstrapJS-problem is AFAIK related to changes in 8.9.0. The integration tests for karaf are not executed and clearly show this same problem.
Could it be that there's some other bundle that registers that same theme path?
That is a possiblity, I have not been able to hunt down deep enough into code to verify that. If you have some ideas I am more than happy to hear them.
The missing bootstrapJS-problem is AFAIK related to changes in 8.9.0.
There was some fixes made for version 8.9.0 regarding OSGi use in context of Liferay, and regression is due that is a possibility. There seem to be much less Karaf users than Liferay users, hence we have not received vocal feedback about this or tickets filed.
The integration tests for karaf are not executed and clearly show this same problem.
Yes, we have been working on to fix the tests, but that task has been not completed yet. (This ticket was filed as collateral of that process)
That is a possiblity, I have not been able to hunt down deep enough into code to verify that. If you have some ideas I am more than happy to hear them.
Either there's a duplicate Resource-registration in that bundle or some other bundle registers that same path. The changes in 8.9.0 make the ServletContext from vaadin-shared as the default-context, so any resource registered without specific context will be mapped to it. That is what I've observed. So possibly test with a clean karaf with just http-whiteboard and that bundle installed, and check that bundle for duplicate paths.
There was some fixes made for version 8.9.0 regarding OSGi use in context of Liferay, and regression is due that is a possibility. There seem to be much less Karaf users than Liferay users, hence we have not received vocal feedback about this or tickets filed.
At my work we have an app running with Karaf 4.2.x and Vaadin 8.8.6, since the versions above that fail. We've just never had time to confirm where the problem is, hence no ticket, thought it has been discussed with our dev contact. Anyway, what I've recently dug up is that there's the aforementioned ServletContextHelper registration with the factory shared/src/main/java/com/vaadin/osgi/resources/impl/VaadinServletContextFactory.java, and the only time that factory is called is a call with the bundle pax-web-runtime. Now that means that the bundle set as the source of all the resources is the pax-web-runtime-bundle, which does not have access to resources in different bundles. I don't know how that part works in Liferay, maybe the bundle that is used in the call to that ServiceFactory can access the classpath of all other bundles. When e.g. VaadinTheme is then registered as Resource-service in com.vaadin.osgi.resources.impl.VaadinResourceTrackerComponent.Delegate#registerImpl(), it's bound to the context which then tries to find the resource from the pax-web-runtime-bundle. One way to solve this would be to add the classloader of the original service-object and the path to the Vaadin-shareds context, and then do path-matching to find the correct classloader to use to serve the resource. Hope this helps.
I found a way to reproduce your exception. Running this on a clean karaf (started with bin/karaf clean), you'll end up with the same exception
feature:install http-whiteboard bundle:install -s mvn:com.vaadin.external/gentyref/1.2.0.vaadin1 bundle:install -s mvn:org.jsoup/jsoup/1.11.2 bundle:install -s mvn:com.vaadin.external.slf4j/vaadin-slf4j-jdk14/1.6.1 bundle:install -s mvn:com.vaadin.external.atmosphere/atmosphere-runtime/2.4.30.vaadin4 bundle:install -s mvn:com.vaadin/vaadin-shared/8.13.3 bundle:install -s mvn:com.vaadin/vaadin-server/8.13.3 bundle:install -s mvn:com.vaadin/vaadin-themes/8.13.3 bundle:install -s mvn:com.vaadin/vaadin-push/8.13.3 bundle:install -s mvn:com.vaadin/vaadin-client-compiled/8.13.3 bundle:install -s mvn:com.vaadin/osgi-vaadin-servlet-publisher/0.9.0 bundle:install -s wrap:mvn:org.vaadin.teemusa/sidemenu/2.0.0 bundle:install -s wrap:mvn:org.vaadin.addons/stepper/2.4.0 bundle:install -s mvn:com.fasterxml.jackson.core/jackson-core/2.10.0 bundle:install -s mvn:com.fasterxml.jackson.core/jackson-annotations/2.10.0 bundle:install -s mvn:com.fasterxml.jackson.core/jackson-databind/2.10.0 bundle:install -s mvn:org.vaadin.mmerruko/osgidashboard-dashboard/1.0 bundle:install -s mvn:org.vaadin.mmerruko/osgidashboard-osgi/1.0 bundle:install -s mvn:org.vaadin.mmerruko/osgidashboard-demo/1.0 echo "Installed" http:list | grep demo bundle:uninstall org.vaadin.mmerruko.osgidashboard-demo echo "Uninstalled" http:list | grep demo bundle:install -s mvn:org.vaadin.mmerruko/osgidashboard-demo/1.0 echo "Installed" http:list | grep demo
Just check that you have the other 2 bundles from that demo available. The echos show that the ResourceServlet for the theme is still registered after the demo-bundle providing it is uninstalled, so the next install causes the NamespaceException. Tracing that lead to pax-web-runtime/AbstractTracker#removedService(ref,element). Seems that when the context is shared, the services/elements are not removed.
I think the missing vaadinBootstrap.js is not caused by this, since it can be observed by running the test setup from test/servlet-containers/karaf/karaf-run/pom.xml and then browsing to the url in the test/servlet-containers/karaf/karaf-run/src/test/java/com/vaadin/test/osgi/KarafIntegrationIT.java tests.
Seems that that test is not executed since the packaging of that project is pom.
Yes, this rather peculiar. My understanding is the Theme is registered by VaadinResourceTrackerComponent
And there is checking if the resource is already registered, it wont be done again
https://github.com/vaadin/framework/blob/2d30ee97f19e1ae956a67afeb0e41f0ee6d08de8/shared/src/main/java/com/vaadin/osgi/resources/impl/VaadinResourceTrackerComponent.java#L266
One potential caveat is that metainfo in this annotation is not 100% correct. Should it be ReferenceCardinality.OPTIONAL instead of ReferenceCardinality.MULTIPLE ?
https://github.com/vaadin/framework/blob/master/shared/src/main/java/com/vaadin/osgi/resources/impl/VaadinResourceTrackerComponent.java#L65
One potential caveat is that metainfo in this annotation is not 100% correct. Should it be ReferenceCardinality.OPTIONAL instead of ReferenceCardinality.MULTIPLE ?
https://github.com/vaadin/framework/blob/master/shared/src/main/java/com/vaadin/osgi/resources/impl/VaadinResourceTrackerComponent.java#L65
MULTIPLE is valid there if you want to allow multiple themes to be registered, MULTIPLE is 0..n, OPTIONAL is just 0..1.
To me it seems that the problem with the namespace is related to ops4j/org.ops4j.pax.web#1603 when using Karaf with pax-web.