Skip to content
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.

Sign up for GitHub

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

Jump to bottom

NamespaceException thrown with OSGi application when using Karaf 4.2 #12396

Open
TatuLund opened this issue Sep 8, 2021 · 8 comments
Open

NamespaceException thrown with OSGi application when using Karaf 4.2 #12396

TatuLund opened this issue Sep 8, 2021 · 8 comments

Comments

@TatuLund
Copy link
Contributor

TatuLund commented Sep 8, 2021

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]
@hakanen
Copy link

hakanen commented Sep 20, 2021

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.

@TatuLund
Copy link
Contributor Author

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)

@hakanen
Copy link

hakanen commented Sep 20, 2021

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.

@hakanen
Copy link

hakanen commented Sep 21, 2021

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.

@hakanen
Copy link

hakanen commented Sep 21, 2021

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.

@TatuLund
Copy link
Contributor Author

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

framework/shared/src/main/java/com/vaadin/osgi/resources/impl/VaadinResourceTrackerComponent.java

Line 266 in 2d30ee9

if (resourceRegistration != null)

@TatuLund
Copy link
Contributor Author

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

@hakanen
Copy link

hakanen commented Sep 21, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hakanen @TatuLund