On Sun, 2007-10-07 at 11:17 +0200, Mario Ivankovits wrote: > 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. Agreed. The local adapter case is actually simpler than the "mixed jsp/jsf" case, because we can assume a different fa instance is used in each case. > > 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? Is it the responsability of the fa to cache the relevant instance in the user session? Or cache an instance per-request? Or should the fa return a new instance each time? Or should an fa allocate only one instance ever, shared among all users? The current behaviour is effectively per-user, because it is held by conversationManager. 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? 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. We still couldn't allow the fa to be a Spring bean though, unless the filters become spring-specific. 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? Regards, Simon > > 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?
