Community
Participate
Working Groups
Please reconsider implementation of the CommandServiceCreationFunction. It stores CommandServiceImpl both in a local variable and in the "root" context. The CommandServiceCreationFunction is essentially a singleton hence after it is called once, the CommandServiceImpl will always be taken from a local variable. Is there some reason why this function has to have such strange implementation? If it has some special requirements, I'd be happy to assist; but from a quick looks we just need CommandServiceImpl added to the application context like other services.
it needs to provide 2 things for the commands/handlers to work, ECommandService and CommandManager in the context. But yes, they need to be singletons. ECommandService is an interface, so I guess I could turn that into an OSGi service by itself. If CommandManager is a class, can I still make that an OSGi service? PW
How about addding them in the E4Application#createDefaultContext() ? (I don't see any benefit from adding extra layers by using DS, but I am not familiar with the commands code.)
(In reply to comment #2) > How about addding them in the E4Application#createDefaultContext() ? > Everything that was added in there was failure ... i.e. we were supposed to create a modular set of services, but we added them there when we couldn't figure out the lifecycle stuff correctly. PW
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.
