I have created a bundle that registers a ServiceFactory object because I
want to control how the service is actually created.
I have created a further two bundles that are consumers of this service
and I use Aries blueprint to instantiate these consumers. What I have
found is that the ServiceFactory.getService() method is never called
when binding the service. Instead a proxy object is provided.
I would have thought that even though a proxy object is being provided,
Aries would still call through to the ServiceFactory object prior to
binding it to consumers. I created an example of what I am trying to
achieve here: https://github.com/jtkb/serviceexample. How does/should
Aries work with ServiceFactory objects?
This looks like this essentially the same question that you posted on StackOverflow: https://stackoverflow.com/questions/45659019/create-a-service-and-allow-only-one-bundle-to-hold-that-service-at-any-time.
The Blueprint proxy will not try to bind the back-end service until you actually invoke a method on the service. I did say this in my comments on the StackOverflow, did you try it?
Thanks for replying and yes it is along similar lines although it's more of a question of what Aries does/interprets the OSGi spec.
I have tried as you suggested and invoke a method on the service and it appears that the ServiceFactory.setService() method is never called. When calling a method on the service it calls the object backing the proxy. Interestingly though when uninstalling the consumer bundle the ServiceFactory.getService() IS called. I used my code here https://github.com/jtkb/serviceexample to test this out.
Assuming my code/test is valid then it appears Aries is not using the Factory interface to create a service, which is a bit of a worry. That aside, my hope was that any blueprint implementation would call a ServiceFactory method when it could back it's proxy object with a real one prior to binding it. This way, for my use case it could 'fail fast' and not cause the service to be bound. I would rather that than allow the service to be bound only for the consumer to cause an exception to be thrown when it tries to use it.
The alternative is to do as you said on StackOverflow and encapsulate the 'Stage' object and implement the 'Whiteboard' pattern. Any bundle wanting to use the Stage object would provide a service offering up 'Scene' objects which can be loaded into the Stage. I've implemented this currently as a simple first-come-first-served basis but it obviously wouldn't be hard to include some sort of SceneObjectSelection manager.
On 20/08/17 14:57, Neil Bartlett wrote:
After re-reading my email, just to clarify, I meant getService()
is never called and ungetService() is called when disposing of a
On 22/08/17 19:14, Kerry wrote:
|Free forum by Nabble||Edit this page|