myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [orchestra] getting ready for a release
Date Sun, 07 Oct 2007 17:36:44 GMT
>> 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.

> The current
> behaviour is effectively per-user, because it is held by
> conversationManager.
Our implementations are all stateless ... so no problem to treat them
like a singleton.

> 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.

> The messager is only used rarely (we hope), so I guess performance is
> not an issue. 

> Alternatively, should we create a separate fa instance per request? The
> fa could then cache it as a member, implicitly making it cache
> per-request.
I think it is not required to anticipate the scope one might use. All is
possible by providing custom implementations, but ours are stateless at
all so we are fine with have the same lifetime as the filter.

>  We still couldn't allow the fa to be a Spring bean though,
> unless the filters become spring-specific.
Yep, that is true ... unhappily :-(

> 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.


View raw message