It’s a pretty simple type - there’s a blog post here <http://blog.vogella.com/2017/02/13/control-osgi-ds-component-instances/>. Fundamentally it lets you get an instance of a service on demand, but you have to release it when you’re done with it. This is good for Vaadin UIs and Views because they are user specific.
Tim > On 2 Jul 2018, at 11:27, Paul F Fraser <pa...@a2zliving.com> wrote: > > On 2/07/2018 7:52 PM, Tim Ward wrote: >> Hi Paul, >> >> Is the QUIProvider instance being used by Vaadin the same as the instance >> managed by DS? You cannot simply pass the QUIProvider.class to Vaadin for >> this to work, you need to be able to register the specific component >> instance. You can see this happening here >> <https://github.com/opensecuritycontroller/osc-core/blob/master/osc-ui/src/main/java/org/osc/core/ui/UiServlet.java#L88> >> in OSC where the instance is passed. >> > I am doing that, Tim, > > As long as the code I included is OK I can check further for a cause. > > There does not seem to be much information available about instantiating > PROTOTYPE instances. Eclipsecon talks and OSGi Alliance blogs only mention > using the PROTOTYPE scope and go no further. > Info on ComponentServiceObjects is also a bit light on. I know I can always > read the spec...for me the Videos/Slides are the best learning method. > > Thanks, > > Paul >> >>> On 2 Jul 2018, at 10:47, Paul F Fraser via osgi-dev <osgi-dev@mail.osgi.org >>> <mailto:osgi-dev@mail.osgi.org>> wrote: >>> >>> Thanks to the clues obtained from code in the OpenSecurityController >>> project I am making some serious progress in handling the Vaadin OSGi >>> situation. >>> The one sticking point now is related to creating the instances of >>> PROTOTYPE services. >>> In the code below, when the component is activated the >>> ComponentServiceObjects factory is not null. When it comes to create the >>> instance the factory is null. >>> How should this be handled? >>> >>> @Component(service=QUIProvider.class) >>> public class QUIProvider extends UIProvider { >>> >>> @Reference(scope=ReferenceScope.PROTOTYPE) >>> ComponentServiceObjects<QMainSiteUI> factory; >>> >>> @SuppressWarnings("unchecked") >>> @Override >>> public Class<? extends UI> getUIClass(UIClassSelectionEvent event) { >>> return (Class<? extends UI>) QMainSiteUI.class; >>> } >>> >>> @Override >>> public UI createInstance(UICreateEvent event) { >>> QMainSiteUI mainSiteUI = this.factory.getService(); >>> UI ui = (UI) mainSiteUI; >>> ui.addComponentDetachListener(x -> >>> factory.ungetService(mainSiteUI)); >>> return ui; >>> } >>> >>> } >>> >>> Thanks, >>> >>> Paul Fraser >>> >>> >>> On 28/06/2018 7:49 PM, Tim Ward wrote: >>>> Hi Paul, >>>> >>>> I’m glad to hear that this is working. It does look like it could use a >>>> little tidying up though. The overall approach seems similar to that used >>>> in the OpenSecurityController project, although that is even more >>>> decomposed into services, and might be a better model follow up. >>>> >>>> The UI instance is provided as a service >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/ui/UiServlet.java#L59> >>>> using a provider >>>> The UI provider uses Prototype scope service instances >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/broker/view/MainUIProvider.java#L34> >>>> to create a UI instance per session. These are released when the UI >>>> detaches >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/broker/view/MainUIProvider.java#L45> >>>> The UI then uses Prototype scope service instances to create views >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/broker/view/MainUI.java#L138> >>>> and passes them to a view provider >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/broker/view/MainUI.java#L195>. >>>> The view provider ensures the view service is released when it is >>>> detached >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L63> >>>> >>>> This model allows an incredibly flexible UI to be built entirely from OSGi >>>> services, right down to the views. This means that the individual view >>>> instances can be DS components, and therefore simply injected with >>>> business services >>>> <https://github.com/opensecuritycontroller/osc-core/blob/534d035033804d360bd6fc253eaad4cda49a2d59/osc-ui/src/main/java/org/osc/core/broker/view/ApplianceView.java>. >>>> This saves you from having huge hellish constructors, and from having a >>>> UI component that has all the dependencies for every one of its views. >>>> >>>> I hope this helps to demonstrate some of the awesome power that you can >>>> get from leveraging the OSGi service model. >>>> >>>> Best Regards, >>>> >>>> Tim >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
