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

Reply via email to