in case of jsf and servlet the filter sets the appropriate framework adapter and there it might be reqired to use different init parameters.
In case of local there is no real session and thus this one do not reuse the servlet session and creates a new convman per lfa. We just have to ensure that the convman do not cache the convmess any more but to look it up from the fa. Mario -----Original Message----- From: simon <[EMAIL PROTECTED]> Date: Sunday, Okt 7, 2007 10:30 am Subject: Re: [orchestra] getting ready for a release To: Reply- "MyFaces Development" <[email protected]>To: MyFaces Development <[email protected]> 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 > >> > >> > >> > >> > > > > > > >
