No, no problem. Please use it. Richard
Am Mi., 5. Mai 2021 um 08:27 Uhr schrieb Jean-Baptiste Onofre < [email protected]>: > Hi Richard, > > Thanks a lot. Do you mind if I take your project and adapt to be added as > a Karaf example ? > > Regards > JB > > Le 5 mai 2021 à 08:01, Richard Hierlmeier <[email protected]> a > écrit : > > Sure, > > I created a demo project on Github: > https://github.com/rhierlmeier/vaadin8_karaf_demo > > Regards > Richard > > Am Di., 4. Mai 2021 um 13:48 Uhr schrieb Jean-Baptiste Onofre < > [email protected]>: > >> Hi Richard, >> >> Thanks for the update. Can you share what you did (for other Vaadin >> users) ? >> >> Regards >> JB >> >> Le 4 mai 2021 à 11:01, Richard Hierlmeier <[email protected]> a >> écrit : >> >> Finally I got my Vaadin 8 application running on Karaf 4.3.1. It brings >> now it's own servlet that handles the /VAADIN/ requests. This work fine. I >> do no longer install the vaadin-osgi-intregration bundle. >> >> >> >> >> Am Mo., 3. Mai 2021 um 16:27 Uhr schrieb Jean-Baptiste Onofre < >> [email protected]>: >> >>> 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]>: >>> >>>> 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> >>>>>> >>>>>> >>>>>> >>>> >>> >> >
