Hi CDI implementations does not require to provide anything to JSF in order to make @FlowScoped to work. The code has been tested against OWB and Weld and it works in both cases.
But the flow stuff relies on the new ClientWindow API, and that could cause a conflict with CODI, because CODI provides a solution for this part too. In fact, the solution introduced in the standard comes from CODI. In your particular case, the best option is provide a custom ClientWindowFactory / ClientWindow that implements ClientWindow.getId() method and grab the value generated by CODI. Theorically there is no need of the custom PhaseListener, because the "attachWindow" step is done in CODI. I haven't tried it but I suppose a custom ClientWindow will work. regards, Leonardo Uribe 2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr <l.pe...@senat.fr>: > On 11/02/2014 14:51, l.pe...@senat.fr wrote: >> >> On 11/02/2014 10:28, l.pe...@senat.fr wrote: >>> >>> On 11/02/2014 03:30, Leonardo Uribe wrote: >> >> >> [...] >>>> >>>> @FlowScoped annotation is for CDI only, so it will not work for JSF >>>> managed beans. In your case, I believe the bean is instantiated but it >>>> is not stored in any context, so once is created is discarded, giving >>>> the impression that the bean is working but it is not. >>>> >>>> In MyFaces it is possible to create a custom flow scope annotation for >>>> other containers that works just like @FlowScoped, implementing >>>> org.apache.myfaces.spi.FacesFlowProvider SPI interface. You are >>>> already in CDI, so you don't need to bother about that. >>>> >>>> I have seen @Named annotation working with Spring, so it is not >>>> something specific for CDI, but @FlowScoped depends of CDI API. >>> >>> I am using CODI 1.0.5 (I heavily use its @ViewAccessScoped annotation) >>> with OpenWebBeans 1.2.1. >>> >>> So, I thought was ok on the CDI side... >>> >>> ...but after reading your mail, it seems to me that this CDI >>> implementation was provided before JSF 2.2 release, and so that it must not >>> include proper @FacesFlow support. >>> >>> Should I switch to another implementation, like DeltaSpike ? >>> >>> I must have misunderstood your mail from Sep 26 2013 ( >>> http://myfaces.10567.n7.nabble.com/JSF-2-2-status-amp-snapshot-usage-td115852.html >>> ) inviting us to try Faces Flows in MyFaces 2.2. >> >> After some debugging, I found that : >> * beans are discovered and processed ok by >> org.apache.myfaces.flow.cdi.FlowScopeCDIExtension >> * -flow.xml is detected and processed with no errors ; >> * if I use an empty -flow.xml file, an exception is raised line 716 of >> org.apache.myfaces.config.DefaultFacesConfigurationProvider (on >> facesConfig.getFacesFlowDefinitions().add(flow); ) >> * if I add a breakpoint in >> org.apache.myfaces.flow.FlowHandlerImpl#clientWindowTransition, I can see : >> ** my flow registered in _flowMapById (with "flow1" key) >> ** my flow registered in _flowMapByDocumentId (with an empty key) >> ** that _facesFlowProvider is null > > > ok, I think I got it. And, as I feared, it seems to be CODI related. > > In JSF2.2, a call to > > //JSF 2.2: attach window > _lifecycle.attachWindow(facesContext); > > has been added line 193 of javax.faces.webapp.FacesServlet > > When you use CODI, _lifecycle is an instance of > > org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper > > This wrapper has been designed for JSF 2.0 and 2.1. So, it does not wrap the > call to attachWindow. And Lifecycle#attachWindow, which does nothing, is > called. > > Later, when JSf tries to find my @FlowScoped bean, it fails in > > org.apache.myfaces.flow.FlowHandlerImpl#getCurrentFlow , because client > windos is null > > (line 165 and following) : > ClientWindow clientWindow = > context.getExternalContext().getClientWindow(); > if (clientWindow == null) > { > return null; > } > > So, I guess that I have to write a custom PhaseListener to solve this little > glitch. > > If you have a better solution, I will gladly take it. > > > Best regards, > > Ludovic > | > | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. > | >
