myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <simon.kitch...@chello.at>
Subject Re: [orchestra] getting ready for a release
Date Sun, 07 Oct 2007 18:51:27 GMT
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


Mime
View raw message