Community
Participate
Working Groups
Created attachment 231611 [details] Add DI support in @PostConstruct The new message extension in tools.services supports evaluation and execution of a method annotated with @PostConstruct to support similiar functionality as the static init block for OSGi NLS messages. Unfortunately it doesn't support dependency injection, which is supported in other places in the Eclipse application platform. This is described here: http://www.vogella.com/blog/2013/05/22/eclipse-internationalization-part-24-new-message-extension-by-dirk-fauth-and-tom-schindl/ The main reason for this is the knowledge of the context to use for injection. It also could break the caching mechanism if not done right. I already modified the code to also support dependency injection for @PostConstruct annotated methods based on the context of the requestor. Still open is: - configuration of the context to use for injection Usually the application context should be used (or the OSGi context if the application context is not available), as in this case the caching mechanism is working correctly as it is. But you could also configure e.g. the context of the MPerspective so for each perspective you could have your own messages object initialized. In this case the caching needs to be extended for the knowledge of the context. - determine and using the configured context instead of always using the context of the requestor
As the new message extension was moved to the platform, this ticket also needs to be reassigned. Note that the attached patch was created as the new message extension was part of the e4 tools. Therefore it is not quite valid. Since the patch is also not complete and needs some modifications and discussions, it will be updated in the future with a Gerrit patch.
What I'm worried about with DI is that how it plays with the cache let's assume we request Messages the first time on the Window-Context and afterwards on the Part-Context - the @PostConstruct was called on the IEclipseContext of the window the only solution I can think of and which needs to be documented is that @PostConstruct is done on the MApplication context or even OSGi-Context?
Good point. But doesn't ReferenceType.NONE mean that every requestor gets its own Messages instance? So Window and Part would have different instances?
