Hi, It looks like the ContextModel is null (causing the NPE).
It because the servlet model doesn’t have any context. I can guard this in Pax Web, but the resource is probably not complete in Vaadin. Regards JB > Le 3 mai 2021 à 16:18, Richard Hierlmeier <[email protected]> a > écrit : > > I upgraded my installation to Vaadin 8.13.0 (in the hope that this fixes my > problem. But now I have a different error: > > 2021-05-03T16:05:08,504 | ERROR | features-3-thread-1 | HttpServiceStarted > | 100 - org.ops4j.pax.web.pax-web-runtime - 7.3.13 | Could not > start the servlet context for context path [vaadin-8.13.0] > java.lang.NullPointerException: null > at > org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:255) > ~[?:?] > 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.registerWebElements(WebApplication.java:371) > ~[?:?] > at > org.ops4j.pax.web.extender.whiteboard.internal.WebApplication.registerHttpContext(WebApplication.java:283) > ~[?:?] > at > org.ops4j.pax.web.extender.whiteboard.internal.WebApplication.setServletContextHelper(WebApplication.java:429) > ~[?:?] > at > org.ops4j.pax.web.extender.whiteboard.internal.tracker.ServletContextHelperTracker.addingService(ServletContextHelperTracker.java:173) > ~[?:?] > at > org.ops4j.pax.web.extender.whiteboard.internal.tracker.ServletContextHelperTracker.addingService(ServletContextHelperTracker.java:49) > ~[?:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > ~[osgi.core-7.0.0.jar:?] > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903) > ~[osgi.core-7.0.0.jar:?] > at > org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) > ~[?:?] > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833) ~[?:?] > at org.apache.felix.framework.Felix.registerService(Felix.java:3804) ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328) > ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:501) > ~[?:?] > at > com.vaadin.osgi.resources.impl.VaadinResourceServiceImpl.start(VaadinResourceServiceImpl.java:62) > ~[?:?] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_202] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:1.8.0_202] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:1.8.0_202] > at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_202] > 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.ActivateMethod.invoke(ActivateMethod.java:318) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:354) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:115) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:1000) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:973) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:918) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:348) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:248) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:362) > ~[?:?] > at org.apache.felix.framework.Felix.getService(Felix.java:3954) ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:450) > ~[?:?] > at > org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:416) > ~[osgi.core-7.0.0.jar:?] > at > com.vaadin.osgi.resources.OsgiVaadinResources$1.addingService(OsgiVaadinResources.java:80) > ~[?:?] > at > com.vaadin.osgi.resources.OsgiVaadinResources$1.addingService(OsgiVaadinResources.java:76) > ~[?:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > ~[osgi.core-7.0.0.jar:?] > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903) > ~[osgi.core-7.0.0.jar:?] > at > org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) > ~[?:?] > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833) ~[?:?] > at org.apache.felix.framework.Felix.registerService(Felix.java:3804) ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328) > ~[?:?] > 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:488) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420) > ~[osgi.core-7.0.0.jar:?] > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) > ~[osgi.core-7.0.0.jar:?] > at > org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450) > ~[osgi.core-7.0.0.jar:?] > at > org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516) > ~[?:?] > at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4817) ~[?:?] > at org.apache.felix.framework.Felix.startBundle(Felix.java:2336) ~[?:?] > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?] > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) ~[?:?] > at > org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1160) > ~[?:?] > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1041) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) > ~[?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_202] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [?:1.8.0_202] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [?:1.8.0_202] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202] > > Am Mo., 3. Mai 2021 um 08:38 Uhr schrieb Jean-Baptiste Onofre > <[email protected] <mailto:[email protected]>>: > Hi Richard, > > It depends the whiteboard properties and the number of resource. I know we > have an improvement to do on Pax Web about dealing with several resources > locations in the same bundle. That’s maybe the issue. > That’s why I would like to check the way the resources are "exposed". > > Regards > JB > >> Le 3 mai 2021 à 08:27, Richard Hierlmeier <[email protected] >> <mailto:[email protected]>> a écrit : >> >> >> Are you sure that this is a Vaadin and not a Karaf 4.3.1 problem? What I can >> see is that the Vaadin application tries to download >> http://localhost:8181/vaadin-8.12.2/VAADIN/vaadinBootstrap.js >> <http://localhost:8181/vaadin-8.12.2/VAADIN/vaadinBootstrap.js>. However >> this URL can not be resolved. >> >> Shouldn't the following service provide this file? >> >> [com.vaadin.osgi.resources.OsgiVaadinResource] >> ---------------------------------------------- >> osgi.http.whiteboard.context.select = (osgi.http.whiteboard.context.name >> <http://osgi.http.whiteboard.context.name/>=com.vaadin) >> osgi.http.whiteboard.resource.pattern = /VAADIN/vaadinBootstrap.js >> osgi.http.whiteboard.resource.prefix = /VAADIN/vaadinBootstrap.js >> service.bundleid = 237 >> service.id <http://service.id/> = 251 >> service.scope = singleton >> Provided by : >> Vaadin Server (237) >> >> [javax.servlet.ServletContext] >> ------------------------------ >> osgi.web.contextname = com.vaadin >> osgi.web.contextpath = /vaadin-8.12.2 >> osgi.web.symbolicname = com.vaadin.shared >> osgi.web.version = 8.12.2 >> service.bundleid = 238 >> service.id <http://service.id/> = 242 >> service.scope = singleton >> Provided by : >> Vaadin Shared (238) >> Used by: >> OPS4J Pax Web - Runtime (100) >> >> Regards >> >> Richard >> >> >> >> >> >> Am Fr., 30. Apr. 2021 um 09:27 Uhr schrieb Васил Зорев >> <[email protected] <mailto:[email protected]>>: >> After a few restarts and version changes 8.6.0 worked for me as well.. >> Please ignore my previous statement, I cannot get a consistent result yet. >> >> На пт, 30.04.2021 г. в 9:34 ч. Jean-Baptiste Onofre <[email protected] >> <mailto:[email protected]>> написа: >> Hi Alex, >> >> Sure, you can send the archive to me. >> >> Regards >> JB >> >>> Le 30 avr. 2021 à 07:55, Alex Weirig <[email protected] >>> <mailto:[email protected]>> a écrit : >>> >>> Hello, >>> >>> I'm pretty sure, I've been successfully running a full OSGi Vaadin > 8.6.0 >>> application in karaf 4.2.x. >>> >>> The thing is, I had a fix provided by Vaadin that even allowed my to define >>> the main UI class as an OSGi service and thus to even use the @Reference >>> service injection in the main UI. >>> >>> That allowed me to use my OSGi backend services in the UI and to >>> dynamically compose my UI by getting references to "sub-UI" classes that >>> added pages etc to my main UI. That worked really nice and again I'm sure >>> that was > 8.6.0. >>> >>> I don't know how I can send you an archive of the patched Vaadin bundle >>> (can't use attachments) and I don't have github. >>> >>> @JB: can I send you the archive? >>> >>> >>> Mat frëndleche Gréiss, >>> Mit freundlichen Grüßen, >>> Meilleures salutations, >>> Kind regards, >>> >>> Alex Weirig >>> >>> Responsable Technique >>> Ville de Luxembourg >>> Service Enseignement >>> Centre Technolink >>> >>> Tel +352 4796 - 6127 <tel:+35247966127> >>> Fax +352 42 88 81 >>> Email [email protected] <mailto:[email protected]> >>> www.vdl.lu <http://www.vdl.lu/> >>> 2, rue Charles de Tornaco >>> L-2623 LUXEMBOURG >>> >>> indoors.this.blesses >>> <https://map.what3words.com/indoors.this.blesses> >>> schaufel.besten.kopie >>> <https://map.what3words.com/schaufel.besten.kopie> >>> supposons.levage.venger >>> <https://map.what3words.com/supposons.levage.venger> >>> On 30/04/2021 06:38, Jean-Baptiste Onofre wrote: >>>> Hi, >>>> >>>> It looks like a regression in Vaadin 8.6.0. >>>> >>>> I will try to take a look next week. >>>> >>>> Regards >>>> JB >>>> >>>>> Le 29 avr. 2021 à 22:03, Васил Зорев <[email protected] >>>>> <mailto:[email protected]>> a écrit : >>>>> >>>>> Does not seem that it was intentional, newer Vaadin 8 release notes say >>>>> there were "improvements in OSGi support". >>>>> >>>>> In my tests on Karaf 4.3.2-SNAPSHOT the last working version is 8.5.2, it >>>>> broke with 8.6.0. Possibly with >>>>> https://github.com/vaadin/framework/commit/7e89b5e3348be487110bd8a5c60336ff363cf9d6 >>>>> >>>>> <https://github.com/vaadin/framework/commit/7e89b5e3348be487110bd8a5c60336ff363cf9d6> >>>>> , >>>>> although not sure about it. I would suggest to ask on the Vaadin forums >>>>> as well, just in case. >>>>> >>>>> На чт, 29.04.2021 г. в 14:30 ч. Richard Hierlmeier >>>>> <[email protected] <mailto:[email protected]>> написа: >>>>> I have to port a Vaadin 7 applikation to Vaadin 8, so I planned to used >>>>> the newest one (8.12.2 or 8.13.0). >>>>> >>>>> I found a workaround for the problem. >>>>> When the Vaadin Servlet that hosts the UI has "/VAADIN/*" in the >>>>> URL-Patterns, then the Servlet is called when static resource files from >>>>> /VAADIN are requested. >>>>> You can overwride then in the VaadinServlet the findResourceURL method >>>>> and you can search for all OsgiVaadinResource services an ask them for >>>>> the resources. >>>>> >>>>> Can it be that Vaadin dropped the OSGI support for Vaadin 8. >>>>> >>>>> Regards >>>>> >>>>> Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Am Mi., 28. Apr. 2021 um 23:39 Uhr schrieb Васил Зорев >>>>> <[email protected] <mailto:[email protected]>>: >>>>> What Vaadin version do you depend on ? I deployed locally the app by >>>>> Peter Lehto - https://github.com/peterl1084/vaadin-karaf >>>>> <https://github.com/peterl1084/vaadin-karaf> and observed something kind >>>>> of strange. >>>>> >>>>> Karaf version is 4.3.2-SNAPSHOT (from 2-3 weeks ago). >>>>> >>>>> On Vaadin version 8.3.0, going to http://localhost:8181/myapp >>>>> <http://localhost:8181/myapp> showed the expected view. (however >>>>> vaadin-osgi-integration was 8.13.0 in the pom at that time, by mistake..) >>>>> >>>>> I then changed to Vaadin 8.13.0 and got the same error as you did: >>>>> Failed to load resource: the server responded with a status of 404 (Not >>>>> Found) >>>>> http://localhost:8181/vaadin-8.13.0/VAADIN/vaadinBootstrap.js?v=8.13.0 >>>>> <http://localhost:8181/vaadin-8.13.0/VAADIN/vaadinBootstrap.js?v=8.13.0> >>>>> myapp:21 Uncaught ReferenceError: vaadin is not defined >>>>> at myapp:21 >>>>> vaadin-8.13.0/VAADIN/themes/valo/favicon.ico:1 Failed to load resource: >>>>> the server responded with a status of 404 (Not Found) >>>>> http://localhost:8181/vaadin-8.13.0/VAADIN/themes/valo/favicon.ico >>>>> <http://localhost:8181/vaadin-8.13.0/VAADIN/themes/valo/favicon.ico> >>>>> >>>>> Funny enough, changing back to 8.3.0 got it running again... I leave it >>>>> for now, but will try to figure something out these days. >>>>> >>>>> Regards, >>>>> Vassil >>>>> >>>>> На ср, 28.04.2021 г. в 20:03 ч. Васил Зорев <[email protected] >>>>> <mailto:[email protected]>> написа: >>>>> Hi Richard, >>>>> >>>>> I cannot give an answer yet as I have no idea yet, but we are currently >>>>> running a Vaadin 7 app on Karaf 4.3.1 in my work environment so I would >>>>> be very interested to have a look into your issue. >>>>> >>>>> A few questions. Are you using "stock" Karaf 4.3.1 or you forked it and >>>>> built your own? Can you please provide a sample Vaadin 8 app (the minimal >>>>> possible version) that reproduces the error you get that I can deploy >>>>> locally? How do you deploy the app to Karaf? Also if needed please >>>>> provide a sample web descriptor file (if you don't use annotations). >>>>> >>>>> Regards, >>>>> Vassil >>>>> >>>>> На ср, 28.04.2021 г. в 10:50 ч. Richard Hierlmeier >>>>> <[email protected] <mailto:[email protected]>> написа: >>>>> >>>>> I try to get a simple Vaadin 8 application running on Karaf 4.3.1. >>>>> However it is not working. Vaadin can not load it's bootstrap Javascript >>>>> File. At the very beginning the Vaadin application makes an >>>>> http request to http://localhost:8181/VAADIN/vaadinBootstrap.js >>>>> <http://localhost:8181/VAADIN/vaadinBootstrap.js> >>>>> Karaf answers with an error code 404 (not found). >>>>> >>>>> The Vaadin OSGI integration registers it's static resources with >>>>> http-whiteboard. >>>>> The http:list <http://list/> shows that the patterns are known: >>>>> >>>>> karaf@root()> http:list <http://list/> >>>>> ID | Servlet | Servlet-Name >>>>> | State | Alias | >>>>> Url >>>>> ----+---------------------+-------------------------------------------------+-------------+-----------------------------------------------------+------------------------------------------------------ >>>>> 176 | CXFNonSpringServlet | cxf-osgi-transport-servlet >>>>> | Deployed | /cxf | >>>>> [/cxf/*] >>>>> 238 | ResourceServlet | txt >>>>> | Deployed | /VAADIN/test.txt | >>>>> [/VAADIN/test.txt/*] >>>>> 238 | ResourceServlet | >>>>> /VAADIN/themes/mytheme/*:/VAADIN/themes/mytheme | Deployed | >>>>> /VAADIN/themes/mytheme/* | >>>>> [/VAADIN/themes/mytheme/*] >>>>> 238 | ResourceServlet | /VAADIN/themes/valo/*:/VAADIN/themes/valo >>>>> | Deployed | /VAADIN/themes/valo/* | >>>>> [/VAADIN/themes/valo/*] >>>>> 238 | ResourceServlet | gz >>>>> | Deployed | /VAADIN/vaadinBootstrap.js.gz | >>>>> [/VAADIN/vaadinBootstrap.js.gz/*] >>>>> 238 | ResourceServlet | js >>>>> | Deployed | /VAADIN/vaadinBootstrap.js | >>>>> [/VAADIN/vaadinBootstrap.js/*] >>>>> 238 | ResourceServlet | gz >>>>> | Deployed | /VAADIN/vaadinPush.debug.js.gz | >>>>> [/VAADIN/vaadinPush.debug.js.gz/*] >>>>> 238 | ResourceServlet | js >>>>> | Deployed | /VAADIN/vaadinPush.debug.js | >>>>> [/VAADIN/vaadinPush.debug.js/*] >>>>> 238 | ResourceServlet | gz >>>>> | Deployed | /VAADIN/vaadinPush.js.gz | >>>>> [/VAADIN/vaadinPush.js.gz/*] >>>>> 238 | ResourceServlet | js >>>>> | Deployed | /VAADIN/vaadinPush.js | >>>>> [/VAADIN/vaadinPush.js/*] >>>>> 238 | ResourceServlet | DefaultWidgetSet >>>>> | Deployed | /VAADIN/widgetsets/com.vaadin.DefaultWidgetSet/* | >>>>> [/VAADIN/widgetsets/com.vaadin.DefaultWidgetSet/*] >>>>> 238 | ResourceServlet | Vaadin7WidgetSet >>>>> | Deployed | /VAADIN/widgetsets/com.vaadin.v7.Vaadin7WidgetSet/* | >>>>> [/VAADIN/widgetsets/com.vaadin.v7.Vaadin7WidgetSet/*] >>>>> >>>>> I debugged the http request to /VAADIN/vaadinBootstrap.js in the >>>>> ResourceServlet from pax-web-jetty and found out that the ResourceServlet >>>>> has the wrong HttpContext. >>>>> It is using the one from CXF and not the from the Vaadin bundle. >>>>> >>>>> karaf@root()> la -u | grep 176 >>>>> 176 | Active | 40 | 3.4.3 | >>>>> mvn:org.apache.cxf/cxf-rt-transports-http/3.4.3 >>>>> >>>>> When the bundle with ID 176 ( cxf-rt-transports-http) is stopped then the >>>>> resource /VAADIN/vaadinBoostrap.js is still not found, but I do no longer >>>>> reach the breakpoint in the pax-web-jetty ResourceServlet >>>>> >>>>> The OSGI service that should bring the /VAADIN/boostrap.js resource has >>>>> the following properties: >>>>> >>>>> [com.vaadin.osgi.resources.OsgiVaadinResource] >>>>> ---------------------------------------------- >>>>> osgi.http.whiteboard.context.select = (osgi.http.whiteboard.context.name >>>>> <http://osgi.http.whiteboard.context.name/>=com.vaadin) >>>>> osgi.http.whiteboard.resource.pattern = /VAADIN/vaadinBootstrap.js >>>>> osgi.http.whiteboard.resource.prefix = /VAADIN/vaadinBootstrap.js >>>>> service.bundleid = 237 >>>>> service.id <http://service.id/> = 251 >>>>> service.scope = singleton >>>>> Provided by : >>>>> Vaadin Server (237) >>>>> >>>>> The ServletContext with name com.vaadin has the following properties: >>>>> >>>>> [javax.servlet.ServletContext] >>>>> ------------------------------ >>>>> osgi.web.contextname = com.vaadin >>>>> osgi.web.contextpath = /vaadin-8.12.2 >>>>> osgi.web.symbolicname = com.vaadin.shared >>>>> osgi.web.version = 8.12.2 >>>>> service.bundleid = 238 >>>>> service.id <http://service.id/> = 242 >>>>> service.scope = singleton >>>>> Provided by : >>>>> Vaadin Shared (238) >>>>> Used by: >>>>> OPS4J Pax Web - Runtime (100) >>>>> >>>>> I have the following http-white-board feature installed: >>>>> >>>>> karaf@root()> feature:list | grep -i white >>>>> pax-web-http-whiteboard | 7.3.13 | | >>>>> Uninstalled | standard-4.3.1 | Pax Web OSGi HTTP >>>>> Whiteboard support >>>>> http-whiteboard | 7.3.13 | | >>>>> Uninstalled | standard-4.3.1 | Transition feature for >>>>> backward compatibility >>>>> pax-http-whiteboard | 7.3.13 | | Started >>>>> | org.ops4j.pax.web-7.3.13 | Provide HTTP Whiteboard pattern >>>>> support >>>>> >>>>> I tried also the following http requests: >>>>> >>>>> http://localhost:8181/vaadin-8.12.2/VAADIN/vaadinBootstrap.js >>>>> <http://localhost:8181/vaadin-8.12.2/VAADIN/vaadinBootstrap.js> >>>>> http://localhost:8181/vaadin-8.12.2/vaadinBootstrap.js >>>>> <http://localhost:8181/vaadin-8.12.2/vaadinBootstrap.js> >>>>> http://localhost:8181/VAADIN/vaadinBootstrap.js >>>>> <http://localhost:8181/VAADIN/vaadinBootstrap.js> >>>>> >>>>> All end up with an 404. >>>>> >>>>> What is wrong in my setup? >>>>> >>>>> Regards >>>>> >>>>> Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> <alex_weirig.vcf> >> >
