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]>:
> 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]> 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. 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
> =com.vaadin)
> osgi.http.whiteboard.resource.pattern = /VAADIN/vaadinBootstrap.js
> osgi.http.whiteboard.resource.prefix = /VAADIN/vaadinBootstrap.js
> service.bundleid = 237
> 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 = 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]>:
>
>> 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]>
>> написа:
>>
>>> Hi Alex,
>>>
>>> Sure, you can send the archive to me.
>>>
>>> Regards
>>> JB
>>>
>>> Le 30 avr. 2021 à 07:55, Alex Weirig <[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 <+35247966127>*Fax* +352 42 88 81*Email*
>>> [email protected]
>>> 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]> 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
>>> ,
>>> 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]> написа:
>>>
>>>> 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]>:
>>>>
>>>>> What Vaadin version do you depend on ? I deployed locally the app by
>>>>> Peter Lehto - 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 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
>>>>> 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
>>>>>
>>>>> 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]>
>>>>> написа:
>>>>>
>>>>>> 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]> написа:
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> 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=com.vaadin)
>>>>>>> osgi.http.whiteboard.resource.pattern = /VAADIN/vaadinBootstrap.js
>>>>>>> osgi.http.whiteboard.resource.prefix = /VAADIN/vaadinBootstrap.js
>>>>>>> service.bundleid = 237
>>>>>>> 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 = 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/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>
>>>
>>>
>>>
>
