hi rudy, basically you could provide an alternative producer implementation.
however, +1 for your suggestion. we have to think about the details. if we allow a list of message-handlers, we would have to ignore the qualifiers in this case -> i would prefer only one optional custom implementation which has to use the @Jsf qualifier. if users need multiple implementations, they could use an implementation which aggregates those implementations. -> i would suggest to create a jira issue (improvement). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/28 Rudy De Busscher <[email protected]> > Gerhard, > > Thx for the info, it works. However, i have a few remarks about the > solution: > > Creating a new producer method with another qualifier specification, > requires that you change your already defined injection points. (if you > decide in the middle of the development phase that you need some > additional). This can lead to a mismatch and developers that still use the > Jsf qualifier and not your custom one. > > Plus you don't see the message handler in the configuration dump at > startup. > > Possible solution: > Let the current producer method also add a list of messageHandler's it > get's from the JsfModuleConfig (add another entry there). By default, > nothing in the list. Then a @Specialized version can supply your > messageHandler that you need. (and maybe also add the option to define other > artifacts like MessageResolver, MessageInterpolator, ...) > > WDYT? > > add a jira issue (and path) so that we can include it in the release 0.9.5? > (or is it important enough for this one?) > > Thx > Rudy. > > > On 25 March 2011 17:02, Gerhard Petracek <[email protected]>wrote: > >> hi rudy, >> >> the producer for the message-context with the @Jsf qualifier creates a >> dependent instance. >> since the default implementation (without qualifier) doesn't specify a >> scope (because it's independent of cdi), it's automatically a dependent >> bean. >> >> that means: you can't use the startup event in this case, because you just >> get a dependent bean. >> you can create a custom producer which produces the context in the scope >> of your choice. >> (you can have a look at JsfAwareMessageContextProducer as an example.) >> >> thx for the question! i'll add more information to the documentation. >> >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> 2011/3/25 Rudy De Busscher <[email protected]> >> >>> Hi all, >>> >>> I like to register a new MessageHandler in CODI but it gets never called. >>> >>> On the wiki page (1) I found a description how this could be done. I >>> placed the line of code within a method that observes for StartupEvent like >>> this >>> >>> @Inject >>> private MessageContext context; >>> >>> public void configureErrorMessageListener(@Observes StartupEvent >>> startupEvent) { >>> context.config().change().addMessageHandler(new >>> ErrorMessageHandler()); >>> } >>> >>> But the messageContext injected in the CDI Request bean does contain only >>> the standard JSF aware message handler. >>> Adding the @Jsf Qualifier is also not changing anything. (This i can >>> understand because the method producer created a new config, and is not >>> using the original one) >>> >>> My version is 0.9.4-SNAPSHOT >>> >>> Thx >>> Rudy >>> >>> (1) https://cwiki.apache.org/confluence/display/EXTCDI/Message+DevDoc >>> >> >> >
