You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Richard Hierlmeier <rh...@googlemail.com> on 2021/04/28 07:50:35 UTC

Vaadin 8 application on Karaf 4.3.1

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 shows that the patterns are known:

karaf@root()> 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

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Richard Hierlmeier <rh...@googlemail.com>.
No, no problem. Please use it.

Richard



Am Mi., 5. Mai 2021 um 08:27 Uhr schrieb Jean-Baptiste Onofre <
jb@nanthrax.net>:

> 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 <rh...@googlemail.com> 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 <
> jb@nanthrax.net>:
>
>> 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 <rh...@googlemail.com> 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 <
>> jb@nanthrax.net>:
>>
>>> 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 <rh...@googlemail.com>
>>> 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 <
>>> jb@nanthrax.net>:
>>>
>>>> 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 <rh...@googlemail.com>
>>>> 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 Васил Зорев <
>>>> vassil.zorev87@gmail.com>:
>>>>
>>>>> 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 <jb...@nanthrax.net>
>>>>> написа:
>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> Sure, you can send the archive to me.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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* alex.weirig@technolink.luwww.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, Васил Зорев <va...@gmail.com> 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 <
>>>>>> rhierlmeier@googlemail.com> написа:
>>>>>>
>>>>>>> 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 Васил Зорев <
>>>>>>> vassil.zorev87@gmail.com>:
>>>>>>>
>>>>>>>> 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 ч. Васил Зорев <
>>>>>>>> vassil.zorev87@gmail.com> написа:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> rhierlmeier@googlemail.com> написа:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rh...@googlemail.com> a écrit :
> 
> Sure,
> 
> I created a demo project on Github: https://github.com/rhierlmeier/vaadin8_karaf_demo <https://github.com/rhierlmeier/vaadin8_karaf_demo>
> 
> Regards
> Richard
> 
> Am Di., 4. Mai 2021 um 13:48 Uhr schrieb Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>>:
> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> 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 <jb@nanthrax.net <ma...@nanthrax.net>>:
>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> 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 <jb@nanthrax.net <ma...@nanthrax.net>>:
>>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>>> 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 <jb@nanthrax.net <ma...@nanthrax.net>> написа:
>>>> Hi Alex,
>>>> 
>>>> Sure, you can send the archive to me.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> Le 30 avr. 2021 à 07:55, Alex Weirig <alex.weirig@technolink.lu <ma...@technolink.lu>> 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 alex.weirig@technolink.lu <ma...@technolink.lu>
>>>>> 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, Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>>>>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>>>>>> 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 ч. Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> написа:
>>>>>>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>>>>> 
>>>>>>> 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>
>>>> 
>>> 
>> 
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Richard Hierlmeier <rh...@googlemail.com>.
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 <
jb@nanthrax.net>:

> 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 <rh...@googlemail.com> 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 <
> jb@nanthrax.net>:
>
>> 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 <rh...@googlemail.com> 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 <
>> jb@nanthrax.net>:
>>
>>> 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 <rh...@googlemail.com>
>>> 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 Васил Зорев <
>>> vassil.zorev87@gmail.com>:
>>>
>>>> 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 <jb...@nanthrax.net>
>>>> написа:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> Sure, you can send the archive to me.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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* alex.weirig@technolink.luwww.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, Васил Зорев <va...@gmail.com> 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 <
>>>>> rhierlmeier@googlemail.com> написа:
>>>>>
>>>>>> 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 Васил Зорев <
>>>>>> vassil.zorev87@gmail.com>:
>>>>>>
>>>>>>> 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 ч. Васил Зорев <
>>>>>>> vassil.zorev87@gmail.com> написа:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> rhierlmeier@googlemail.com> написа:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>
>>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rh...@googlemail.com> 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 <jb@nanthrax.net <ma...@nanthrax.net>>:
> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> 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 <jb@nanthrax.net <ma...@nanthrax.net>>:
>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>> 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 <jb@nanthrax.net <ma...@nanthrax.net>> написа:
>>> Hi Alex,
>>> 
>>> Sure, you can send the archive to me.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 30 avr. 2021 à 07:55, Alex Weirig <alex.weirig@technolink.lu <ma...@technolink.lu>> 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 alex.weirig@technolink.lu <ma...@technolink.lu>
>>>> 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, Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>>>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>>>>> 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 ч. Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> написа:
>>>>>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>>>> 
>>>>>> 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>
>>> 
>> 
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Richard Hierlmeier <rh...@googlemail.com>.
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 <
jb@nanthrax.net>:

> 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 <rh...@googlemail.com> 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 <
> jb@nanthrax.net>:
>
>> 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 <rh...@googlemail.com> 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 Васил Зорев <
>> vassil.zorev87@gmail.com>:
>>
>>> 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 <jb...@nanthrax.net>
>>> написа:
>>>
>>>> Hi Alex,
>>>>
>>>> Sure, you can send the archive to me.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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* alex.weirig@technolink.luwww.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, Васил Зорев <va...@gmail.com> 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 <
>>>> rhierlmeier@googlemail.com> написа:
>>>>
>>>>> 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 Васил Зорев <
>>>>> vassil.zorev87@gmail.com>:
>>>>>
>>>>>> 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 ч. Васил Зорев <va...@gmail.com>
>>>>>> написа:
>>>>>>
>>>>>>> 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 <
>>>>>>> rhierlmeier@googlemail.com> написа:
>>>>>>>
>>>>>>>>
>>>>>>>> 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>
>>>>
>>>>
>>>>
>>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rh...@googlemail.com> 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 <jb@nanthrax.net <ma...@nanthrax.net>>:
> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>> 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 <jb@nanthrax.net <ma...@nanthrax.net>> написа:
>> Hi Alex,
>> 
>> Sure, you can send the archive to me.
>> 
>> Regards
>> JB
>> 
>>> Le 30 avr. 2021 à 07:55, Alex Weirig <alex.weirig@technolink.lu <ma...@technolink.lu>> 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 alex.weirig@technolink.lu <ma...@technolink.lu>
>>> 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, Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>>>> 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 ч. Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> написа:
>>>>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>>> 
>>>>> 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>
>> 
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Richard Hierlmeier <rh...@googlemail.com>.
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 <
jb@nanthrax.net>:

> 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 <rh...@googlemail.com> 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 Васил Зорев <
> vassil.zorev87@gmail.com>:
>
>> 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 <jb...@nanthrax.net>
>> написа:
>>
>>> Hi Alex,
>>>
>>> Sure, you can send the archive to me.
>>>
>>> Regards
>>> JB
>>>
>>> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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* alex.weirig@technolink.luwww.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, Васил Зорев <va...@gmail.com> 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 <
>>> rhierlmeier@googlemail.com> написа:
>>>
>>>> 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 Васил Зорев <
>>>> vassil.zorev87@gmail.com>:
>>>>
>>>>> 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 ч. Васил Зорев <va...@gmail.com>
>>>>> написа:
>>>>>
>>>>>> 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 <
>>>>>> rhierlmeier@googlemail.com> написа:
>>>>>>
>>>>>>>
>>>>>>> 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>
>>>
>>>
>>>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rh...@googlemail.com> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
> 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 <jb@nanthrax.net <ma...@nanthrax.net>> написа:
> Hi Alex,
> 
> Sure, you can send the archive to me.
> 
> Regards
> JB
> 
>> Le 30 avr. 2021 à 07:55, Alex Weirig <alex.weirig@technolink.lu <ma...@technolink.lu>> 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 alex.weirig@technolink.lu <ma...@technolink.lu>
>> 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, Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>>> 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 ч. Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> написа:
>>>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>>> 
>>>> 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>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Richard Hierlmeier <rh...@googlemail.com>.
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 Васил Зорев <
vassil.zorev87@gmail.com>:

> 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 <jb...@nanthrax.net>
> написа:
>
>> Hi Alex,
>>
>> Sure, you can send the archive to me.
>>
>> Regards
>> JB
>>
>> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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* alex.weirig@technolink.luwww.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, Васил Зорев <va...@gmail.com> 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 <
>> rhierlmeier@googlemail.com> написа:
>>
>>> 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 Васил Зорев <
>>> vassil.zorev87@gmail.com>:
>>>
>>>> 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 ч. Васил Зорев <va...@gmail.com>
>>>> написа:
>>>>
>>>>> 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 <
>>>>> rhierlmeier@googlemail.com> написа:
>>>>>
>>>>>>
>>>>>> 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>
>>
>>
>>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Васил Зорев <va...@gmail.com>.
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 <jb...@nanthrax.net>
написа:

> Hi Alex,
>
> Sure, you can send the archive to me.
>
> Regards
> JB
>
> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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* alex.weirig@technolink.luwww.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, Васил Зорев <va...@gmail.com> 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 <
> rhierlmeier@googlemail.com> написа:
>
>> 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 Васил Зорев <
>> vassil.zorev87@gmail.com>:
>>
>>> 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 ч. Васил Зорев <va...@gmail.com>
>>> написа:
>>>
>>>> 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 <
>>>> rhierlmeier@googlemail.com> написа:
>>>>
>>>>>
>>>>> 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>
>
>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Alex,

Sure, you can send the archive to me.

Regards
JB

> Le 30 avr. 2021 à 07:55, Alex Weirig <al...@technolink.lu> 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 alex.weirig@technolink.lu <ma...@technolink.lu>
> 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, Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
>>> 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 ч. Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> написа:
>>> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
>>> 
>>> 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>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Alex Weirig <al...@technolink.lu>.
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* alex.weirig@technolink.lu 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, Васил Зорев 
>> <va...@gmail.com> 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 
>> <rh...@googlemail.com> написа:
>>
>>     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 OsgiVaadinResourceservices 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 Васил Зорев
>>     <va...@gmail.com>:
>>
>>         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 ч. Васил Зорев
>>         <va...@gmail.com> написа:
>>
>>             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
>>             <rh...@googlemail.com> написа:
>>
>>
>>                 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 shows that the patterns are known:
>>
>>                 karaf@root()> 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/vaadinBootstrap.js �
>>
>>                 http://localhost:8181/VAADIN/vaadinBootstrap.js �
>>
>>                 All end up with an 404.
>>
>>                 What is wrong in my setup?
>>
>>                 Regards�
>>
>>                   Richard
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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, Васил Зорев <va...@gmail.com> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
> 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 Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>>:
> 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 ч. Васил Зорев <vassil.zorev87@gmail.com <ma...@gmail.com>> написа:
> 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 <rhierlmeier@googlemail.com <ma...@googlemail.com>> написа:
> 
> 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 shows that the patterns are known:
> 
> karaf@root()> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Васил Зорев <va...@gmail.com>.
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 <
rhierlmeier@googlemail.com> написа:

> 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 Васил Зорев <
> vassil.zorev87@gmail.com>:
>
>> 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 ч. Васил Зорев <va...@gmail.com>
>> написа:
>>
>>> 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 <
>>> rhierlmeier@googlemail.com> написа:
>>>
>>>>
>>>> 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 shows that the patterns are known:
>>>>
>>>> karaf@root()> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Alex Weirig <al...@technolink.lu>.
Hi Richard,

I wonder if this is what you are looking for ...

Somebody from the VAADIN team had provided me that fix many years ago. 
With every new Vaadin release I just updated the version in pom and 
rebuild the jar file and deployed it into karaf.

I think this is also the fix that allows you to create you UIs as OSGi 
components and then to use the @Reference to get services (backend) 
injected into your UI or to compose you UI dynamically by deploying 
"sub-UIs" (pages, ...) into Karaf.

I've used this intensively in the past for a Vaadin 8 OSGi application.

Basically, I had no issues running Vaadin 8 in Karaf after I used this fix.

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* alex.weirig@technolink.lu 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 29/04/2021 13:29, Richard Hierlmeier wrote:
> 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 OsgiVaadinResourceservices 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 Васил Зорев 
> <va...@gmail.com>:
>
>     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 ч. Васил Зорев
>     <va...@gmail.com> написа:
>
>         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
>         <rh...@googlemail.com> написа:
>
>
>             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 shows that the patterns are known:
>
>             karaf@root()> 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/vaadinBootstrap.js �
>             http://localhost:8181/VAADIN/vaadinBootstrap.js �
>
>             All end up with an 404.
>
>             What is wrong in my setup?
>
>             Regards�
>
>               Richard
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Richard Hierlmeier <rh...@googlemail.com>.
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 Васил Зорев <
vassil.zorev87@gmail.com>:

> 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 ч. Васил Зорев <va...@gmail.com>
> написа:
>
>> 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 <
>> rhierlmeier@googlemail.com> написа:
>>
>>>
>>> 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 shows that the patterns are known:
>>>
>>> karaf@root()> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Васил Зорев <va...@gmail.com>.
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 ч. Васил Зорев <va...@gmail.com>
написа:

> 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 <
> rhierlmeier@googlemail.com> написа:
>
>>
>> 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 shows that the patterns are known:
>>
>> karaf@root()> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

Re: Vaadin 8 application on Karaf 4.3.1

Posted by Васил Зорев <va...@gmail.com>.
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 <
rhierlmeier@googlemail.com> написа:

>
> 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 shows that the patterns are known:
>
> karaf@root()> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>