Community
Participate
Working Groups
When writing custom object suppliers it is handy to get access to the requestor and primary object supplier. Both informations are already part of the Requestor so its only that we provide them as API
John (asking you as the component lead) is there any plan to handle this? AFAIK Tom has a patch and this is a real killer for multi-user projects if they want to use for example DI event brokering. I did an override for UIEventObject and EventObject supplier for a multi-instance scenario (vaadin renderers on e4) but if I pop another session events from 1 go to 2 -> killer. If instead I use event handler it works ok (with an overridden event broker). Fixing this would open the road to fix bug 392991. Would be good to know if this will be in or not because if not, I know for good that DI events are dead in multiuser. If yes a milestone would be great even though the patch is ready if I'm not mistaken.
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
This bug only ask to provide something in the public API which is already there in the internal one. Yes it can be used to fix the ExtendedObjectSupplier but that's not the only reason. See for example the @Translation implementation which would be in need of getting access to the Injector. So all I ask here for is that the IRequestor provides 2 API methods which are currently only available internally. I'll comment on the object supplier in the bug that bug 392991
(In reply to comment #3) > This bug only ask to provide something in the public API which is already > there in the internal one. What if we decide to mutate the Injector or primary object supplier in order to fix the scoping issue (supplier tied to EclipseContext instead of provided globally, for example)? That's why I want to understand (not even get to the implementation of) the proper fix for a multi-user env before publish the low level API. PW
What about the following, so that people like the RAP-Team and Sopot can go on work with e.g. my solution to the problem. All we'd need to do is to add public PrimaryObjectSupplier getPrimaryObjectSupplier() { return primarySupplier; } to Requestor.java. So this is then only internal API but those guys can cast to the internal object and play with it. Once we provide a proper solution they need update their code. Today their only work-around is to use reflection to get the primarySupplier.
(In reply to comment #4) > (In reply to comment #3) > > This bug only ask to provide something in the public API which is already > > there in the internal one. > > What if we decide to mutate the Injector or primary object supplier in order > to fix the scoping issue (supplier tied to EclipseContext instead of > provided globally, for example)? That's why I want to understand (not even > get to the implementation of) the proper fix for a multi-user env before > publish the low level API. > > PW I'm not sure what modifying the Injector or ObjectSupplier should help to solve the problem, if you are not providing state informations about the current injection to the ExtendedObjectSupplier the only other option is to scope the ExtendedObjectSupplier (each IEclipseContext would have its own one) which means it can't be contributed through OSGi anymore but what you contribute is an ExtendedObjectSupplierFactory which creates a ExtendedObjectSupplier. My initial approach to solve bug 392990 was this (never attached it as a patch) but it would make the single user case much more heavy weight (any IEclipseContext would get a lot for more objects) so I opted to the lightweight one providing access to the Injector and ObjectSupplier so that I can create objects (for events and preferences those are listeners) in the scope of the injection.
(In reply to comment #5) > What about the following, so that people like the RAP-Team and Sopot can go > on work with e.g. my solution to the problem. All we'd need to do is to add > > public PrimaryObjectSupplier getPrimaryObjectSupplier() { > return primarySupplier; > } Sure, that sounds fine. PW
(In reply to comment #7) > (In reply to comment #5) > > What about the following, so that people like the RAP-Team and Sopot can go > > on work with e.g. my solution to the problem. All we'd need to do is to add > > > > public PrimaryObjectSupplier getPrimaryObjectSupplier() { > > return primarySupplier; > > } > > Sure, that sounds fine. > > PW Great I'll prepare a patch for that.
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. If you have further information on the current state of the bug, please add it. 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.
