On Sun, 2007-10-07 at 19:36 +0200, Mario Ivankovits wrote: > Hi! > >> We just have to ensure that the convman do not cache the convmess any more > >> but to look it up from the fa. > >> > > > > This is just a partial answer to my question (1) below. You don't want > > the conversationManager to manage the messager lifetime any more. Ok, > > but what now does? > I'd think the lifetime of the ConversationMessager could be the same as > of the FA. > If one needs a different lifetime it would be easy to just create a > bridge which will access the bean of any scope then.
ok. The javadoc on ConversationMessager currently says that the implementation must be threadsafe. I'll add the requirement that it be stateless too. > > > Question 2 also still exists: how does the user specify for each fa (eg > > a JSF one and a JSP one) which messager to use? Via a filter config > > parameter? Or one of my suggestions below? > > > Both will make it, but in this case I'd go the filter-config way. Then > we do not need any parameter name tangling. Ok. So no ability to configure the object via dependency injection. That's a shame, but I agree that the extra complexity is probably not worth it. > > Possibly the jsf filter could > > use JSF variable resolution which would be effectively the same thing. > > However what would be the equivalent for the > > BasicFrameworkAdapterFilter? > > > I think we should make the FA more spring friendly by providing the > required getter/setter, effectively the pair for the ConversationMessager. > If one sets them, we take it, if not, we try to look it up using any > init configuration (if possible). For this, I'd set the "filter config" > to those FA which are running in such an environment. Well, how about we just implement this in the LocalFrameworkAdapter for now? I cannot see how this can be used in any other case. Are we still looking at returning the messager from the getBean method, or adding a method to the FrameworkAdapterInterface? I still like the idea of using getBean as it provides a standard interface for framework-specific resource lookup no matter what resources we discover we need later. But it does get kludgy if we are not intending to actually try to look the bean up in the DI framework at all.. Regards, Simon Regards, Simon
