Hmm. There is only ever one ConversationManager for a user session. It
is the ConversationManager that holds a reference to the appropriate
ConversationMessager to use when reporting problems. This ref is
initialised just once, when the conversationManager for a user session
is created.
However Dan wants to be able to run two different frameworks
concurrently - the JSF one for normal requests, and the "basic" one for
his background threads. Each framework needs a different
ConversationMessager:
* for JSF framework, add messages to faces error list
* for basic framework, write to local logfile.
It's a more generic problem, though. Anyone running mixed JSF and JSP
pages will also have this problem; when running a JSF request we want to
report problems via a FacesMessage, and for JSP do something else.
I think the old code was always broken - previously in the
background-thread case we used the JSF messager, which would presumably
crash horribly if the messager was ever used because no FacesContext
exists.
I see two problems to resolve:
1. What object should hold the reference to the conversationMessager,
and
2. The user needs to be able to specify a different class to use for
each different framework.
Sorry, but I don't understand how your suggestions below solve these
issues. Could you perhaps explain a little further?
I see the following options for problem 1:
A. Just retrieve the conversationMessager from the framework adapter
whenever it is needed.
The problem here is that there is only one framework adapter instance of
each type per webapp. Either we return a new instance each time, we
return a shared (ie app-scoped messager) or the framework adapter is
responsible for caching the object in the user session.
B. Leave the ref on ConversationMessager and make stuff running as a
background thread see a different HTTP Session, and therefore a
different ConversationManager.
This makes sense for the background thread case; is really not running
in the context of any particular user. However for cases where JSP and
JSF pages are being mixed this does not make sense; we need two
different messagers but should use the same conversationManager.
3. Make the ConversationManager aware of framework subtypes and have it
keep a map of conversationMessagers.
None of these are really tempting approaches. Can anyone come up with a
different suggestion?
For issue 2, we could change the framework adapter so that it checks for
"magic bean names" before trying to resolve the variable, and if it is a
special name then map it to a new name. For example, a call to
adapter.getBean("conversationMessager")
would be mapped to
resolveVariable(
"org.apache.myfaces.orchestra.
frameworkAdapter.jsf.messager")
That isn't entirely obvious, perhaps, but decent javadoc on the getBean
method should make that clear. I cannot think of any other simple way to
do this - except maybe using filter init params, as each framework has
its own filter config.
Comments?
Regards,
Simon
On Sun, 2007-10-07 at 09:40 +0200, Mario Ivankovits wrote:
> Hi!
>
> Yep, I think we've overseen something here.
>
> Simon, the ConversationManager to use depends on the used
> FrameworkAdapter, but you can have multiple FrameworkAdapters in use in
> your application.
> e.g. one for the local stuff, one for JSF, and in an mixed environment,
> one for Servlets/JSP which means, we can't have a global configuration here.
>
> I tried to allow to inject the instance of a ConversationMessager into
> the FrameworkAdapter by introducing an AbstractFrameworkAdapter and fill
> in the required configuration using injection. I've tried it by keeping
> our magicBeans map, but I think now it comes a little bit complicated to
> achive all this. At least the code no longer looks that nice.
>
> I'd ask if we couldn't switch to the already discussed abstract basis
> class for the FrameworkAdapter stuff where we could have a simple
> get/setConversationMessager pair with an default value setted up by the
> inherited class.
> Still, it might be required to go back to the ConversationMessager init
> parameter to configure the default as we can't inject something into the
> e.g. JsfFramworkAdapter.
>
> Ciao,
> Mario
>
> > Simon, below is my LocalFrameworkAdatper coniguration due your latest
> > changes
> >
> > <bean id="localFrameworkAdapter"
> > class="org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter"
> > autowire="byName"
> > scope="prototype" />
> >
> > <!-- ConversationMessager def needed because we are using the special
> > LocalFrameworkAdapter. -->
> > <bean
> > name="org.apache.myfaces.orchestra.conversation.ConversationMessager"
> >
> > class="org.apache.myfaces.orchestra.conversation.basic.BasicConversationMessager"/>
> >
> >
> > is there another more nature way ? like some thing I can inject into
> > LocalFrameworkAdapater?
> >
> >
> >
> > Mario Ivankovits wrote:
> >
> >> Hi Simon!
> >>
> >> Thanks for the hard work on stabilizing the api and cleanup the
> >> documentation.
> >>
> >> Well, I'll start flying for a release in the next few hours ... if
> >> everything went fine.
> >>
> >>
> >> Ciao,
> >> Mario
> >>
> >>
> >>
> >>
> >
> >
>
