You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OsgiClientResources is the service implementation of ClientResources.
It's intended to get content of client engine file which is located inside flow-client.
WAR application is able to access this resource as a ClassLoader resource.
This doesn't work in OSGi and this is the purpose of ClientResources.
But OSGi allows to get resources from bundles directly without introducing this extra layer: just find the Bundle instance for flow-client bundle and call getResource from this bundle directly.
The logic still needs to handle two cases : no OSGi container and OSGi container.
I suggest to solve this via OSGi Instantiator (which is another issue) : instead checking every time whether we are in OSGi container or not there should be a set of services whose impl is different with OSGi and without. But the interface should be the same.
This ticket should be solved after OSGi Instantiator ticket.
In the result there will be one OSGi service less in flow-client.
A bit offtopic: there is no need to implement OSGiClientStaticResource in flow-client as well. This service may be implemented in any bundle (e.g. in flow-server or flow-osgi if we decide to keep it) . The only thing which is needed from flow-client is the resource in /META-INF/resources/VAADIN/static/client and this again can be solved via the same way as described above.
The text was updated successfully, but these errors were encountered:
OsgiClientResources
is the service implementation ofClientResources
.It's intended to get content of client engine file which is located inside
flow-client
.WAR application is able to access this resource as a ClassLoader resource.
This doesn't work in OSGi and this is the purpose of
ClientResources
.But OSGi allows to get resources from bundles directly without introducing this extra layer: just find the
Bundle
instance forflow-client
bundle and callgetResource
from this bundle directly.The logic still needs to handle two cases : no OSGi container and OSGi container.
I suggest to solve this via OSGi
Instantiator
(which is another issue) : instead checking every time whether we are in OSGi container or not there should be a set of services whose impl is different with OSGi and without. But the interface should be the same.This ticket should be solved after OSGi
Instantiator
ticket.In the result there will be one OSGi service less in
flow-client
.A bit offtopic: there is no need to implement
OSGiClientStaticResource
inflow-client
as well. This service may be implemented in any bundle (e.g. inflow-server
orflow-osgi
if we decide to keep it) . The only thing which is needed fromflow-client
is the resource in/META-INF/resources/VAADIN/static/client
and this again can be solved via the same way as described above.The text was updated successfully, but these errors were encountered: