Hi Richard,

agree, fragment is another option, similar to private package approach
as it goes in the same bundle classloader.

Regards
JB

On 23/10/2018 08:24, Richard Hierlmeier wrote:
> I found an example on Github that solves the problem be providing OSGI
> fragment for javax.websocket-api bundle.
> see
> https://github.com/arotnov/sandbox/blob/master/vaadin-osgi-websockets/websocket-api/pom.xml
> 
> 
> Am Do., 11. Okt. 2018 um 10:01 Uhr schrieb Jean-Baptiste Onofré
> <j...@nanthrax.net <mailto:j...@nanthrax.net>>:
> 
>     Hi Richard,
> 
>     You can use the ServiceMix OSGi Locator that deals with
>     SPI/ServiceLoader.
> 
>     Another workaround would be to embed all as private-package.
> 
>     Regards
>     JB
> 
>     On 11/10/2018 08:44, Richard Hierlmeier wrote:
>     >
>     > I tried to deploy a Vaadin war with websocket support into Karaf
>     4.1.6.
>     > Internally Vaadin uses Atmosphere for websocket communication. This
>     > library fails to create a websocket connection because the
>     > classjavax.websocket.server.ServerEndpointConfig$Configurator uses
>     > java.util.ServiceLoader. However the OSGI manifest of
>     > javax.websocket-api does not declare the required capabilities for
>     > serviceloader. When adding the following lines the the OSGI header the
>     > websocket support works fine:
>     >
>     > Require-Capability:
>     osgi.extender;filter:="(osgi.extender=osgi.servicelo
>     >
>      ader.processor)",osgi.serviceloader;filter:="(osgi.serviceloader=javax.
>     >
>      websocket.server.ServerEndpointConfig$Configurator)";resolution:=option
>     >  al;cardinality:=multiple
>     >
>     > Is this a known problem? Is there any workarround possible?
>     >
>     > Richard
>     >
> 
>     -- 
>     Jean-Baptiste Onofré
>     jbono...@apache.org <mailto:jbono...@apache.org>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
> 

Reply via email to