Community
Participate
Working Groups
Unfortunately bug #390346 and bug #389863 got fixed in a way that they are still broken in a multi-user environment. bug #392990 requests a new API to the IInjector so that if the platform decides it is not necessary to fix this - multi-env frameworks (RAP) can fix this themselves. This bug is also related to bug #309868.
Paul Webster on bug #392990 This needs more thought. We already have a "localization" of supplied objects in Eclipse4, and that's through the EclipseContext. It seems that the preference and event object supplier have globals and expects to be the only one. That causes problems. And the system only creates one object supplier for a given annotation, there's no scoping involved at all. That seems like a place to focus design efforts, to understand if we can involve any of our standard scoping mechanisms. PW
I've studied the problem domain a bit and its not a problem that the ExtendedObjectSupplier is a singleton instance. You can see it as factory to create or look up informations. When an object is requested from the ExtendedObjectSupplier this request for an object happens is a very clear "EclipseContext" which is passed in and even used e.g. by the event system to cache e.g. listeners to not created them when they are already there. Unfortunately Oleg never told me what is wrong with my fix in the referenced bug so maybe I'm off the road who knows.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
