Open amedranogil opened 6 years ago
Isn't that what (one of) the classes in utilities.ioc is doing? Are you proposing to "move" the classes from utilities.ioc to mw.container (thereby deleting utilities.ioc)?
There is also the SharedObjectConnector in my container enhancement proposal that I sent around a few weeks ago via mail. These new classes from your proposal could be (nested) subclasses of this SharedObjectConnector.
I did not think of utilities.ioc, it is a good point. They are more a high-level solution for the problem, and really all modules should use them to truly address the issue. My thought was more on a low level synchronisation which would mitigate to certain extent the problem.
Actually utilities.ioc defines 3 different ways to address the issue; and the fact that we have these 3 means that the solution might depend on the requester structure and needs. I have just added this javadoc.
I think utilities.ioc should only be moved to container in the case middleware modules really need it.
Looking into some issues, and analysing the way OSGi container manages the sharing mechanisms; maybe we should think in making it more robust.
As a first proposal, consider the implications of synchronous calls to fetchSharedObject, if the Object is not yet shared (for whatever reason), it will return null. This is indeed the typical problem in OSGi, and it is solved with asynchronous calls. most of our modules make use of fethSharedObject expecting something (probably because the Javadoc does not even mention the result could be a null, nor the concurrency problems). Maybe fetchSharedObject should handle the "asynchronicity" automatically and attempt to always return the object, even if it means waiting (probably limited by a configurable timeout).