Re: @FlowScoped, @Named and @ManagedBean
Thank you.
I guess many users would have the same problem, given that this is the case in
Oracle JEE7 tutorial :
http://docs.oracle.com/javaee/7/tutorial/doc/jsf-configure003.htm
Thanks again, lots of users of proprietary products will be jealous of such
quick fixes. :)
Ludoviv
On 20 février 2014 03:01:17 UTC+01:00, Leonardo Uribe lu4...@gmail.com wrote:
Hi
I also did some changes in the navigation to deal with the case when
the nodeId has the same name as the flow in:
https://issues.apache.org/jira/browse/MYFACES-3859
Please note in a normal case click to enter into a flow twice (enter
into a flow, navigate and try to enter into the same flow again) cause
get out of the flow and enter into the flow again, which is expected.
But in this case, the resulting flow will not have that behavior and
instead the navigation goes to the node identified as start node
without exit from the flow.
regards,
Leonardo Uribe
2014-02-19 20:05 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
Hi
I forgot to say what's wrong in the xml file is define the start
node.
I have created and fixed this issue on:
https://issues.apache.org/jira/browse/MYFACES-3858
regards,
Leonardo Uribe
2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
On 13/02/2014 19:01, Leonardo Uribe wrote:
Hi
Thanks for the example. It helps to clarify the problem. The
definition of the flow has a problem:
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder
flowBuilder)
{
String flowId = flux;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
/*flowBuilder.returnNode(returnFromFlux).
fromOutcome(#{flowScopedBean.return});*/
return flowBuilder.getFlow();
}
In this part:
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
you are using the flow id as a viewNodeId. That confuses the
navigation algorithm because the spec says that an outcome can be a
flowId, and in that sense a flowId is a global identifier that
cannot
be reused. The fix is just set another id:
flowBuilder.viewNode(start,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
The example only requires some small changes in FlowScopedBean and
that's
it.
ok for this one, I will try it tomorrow. And can you tell me what
was wrong
with XML file (or the empty XML file) ?
Thank you,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
Hi
I forgot to say what's wrong in the xml file is define the start node.
I have created and fixed this issue on:
https://issues.apache.org/jira/browse/MYFACES-3858
regards,
Leonardo Uribe
2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
On 13/02/2014 19:01, Leonardo Uribe wrote:
Hi
Thanks for the example. It helps to clarify the problem. The
definition of the flow has a problem:
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
{
String flowId = flux;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
/*flowBuilder.returnNode(returnFromFlux).
fromOutcome(#{flowScopedBean.return});*/
return flowBuilder.getFlow();
}
In this part:
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
you are using the flow id as a viewNodeId. That confuses the
navigation algorithm because the spec says that an outcome can be a
flowId, and in that sense a flowId is a global identifier that cannot
be reused. The fix is just set another id:
flowBuilder.viewNode(start,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
The example only requires some small changes in FlowScopedBean and that's
it.
ok for this one, I will try it tomorrow. And can you tell me what was wrong
with XML file (or the empty XML file) ?
Thank you,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
Hi
I also did some changes in the navigation to deal with the case when
the nodeId has the same name as the flow in:
https://issues.apache.org/jira/browse/MYFACES-3859
Please note in a normal case click to enter into a flow twice (enter
into a flow, navigate and try to enter into the same flow again) cause
get out of the flow and enter into the flow again, which is expected.
But in this case, the resulting flow will not have that behavior and
instead the navigation goes to the node identified as start node
without exit from the flow.
regards,
Leonardo Uribe
2014-02-19 20:05 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
Hi
I forgot to say what's wrong in the xml file is define the start node.
I have created and fixed this issue on:
https://issues.apache.org/jira/browse/MYFACES-3858
regards,
Leonardo Uribe
2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
On 13/02/2014 19:01, Leonardo Uribe wrote:
Hi
Thanks for the example. It helps to clarify the problem. The
definition of the flow has a problem:
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
{
String flowId = flux;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
/*flowBuilder.returnNode(returnFromFlux).
fromOutcome(#{flowScopedBean.return});*/
return flowBuilder.getFlow();
}
In this part:
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
you are using the flow id as a viewNodeId. That confuses the
navigation algorithm because the spec says that an outcome can be a
flowId, and in that sense a flowId is a global identifier that cannot
be reused. The fix is just set another id:
flowBuilder.viewNode(start,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
The example only requires some small changes in FlowScopedBean and that's
it.
ok for this one, I will try it tomorrow. And can you tell me what was wrong
with XML file (or the empty XML file) ?
Thank you,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
Hi
Thanks for the example. It helps to clarify the problem. The
definition of the flow has a problem:
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
String flowId = flux;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
/*flowBuilder.returnNode(returnFromFlux).
fromOutcome(#{flowScopedBean.return});*/
return flowBuilder.getFlow();
}
In this part:
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
you are using the flow id as a viewNodeId. That confuses the
navigation algorithm because the spec says that an outcome can be a
flowId, and in that sense a flowId is a global identifier that cannot
be reused. The fix is just set another id:
flowBuilder.viewNode(start,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
The example only requires some small changes in FlowScopedBean and that's it.
regards,
Leonardo Uribe
2014-02-13 6:03 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
On 13/02/2014 01:44, Leonardo Uribe wrote:
[...]
This is an edge case. Theorically it should work. Could you please provide
the
stack trace, so I can investigate it further?.
Please find attached a mini maven project reproducing the «bug» (or maybe a
PBKAC there :-) ).
If you just build and debug it, you will be in the situation I just
described.
If you disable the Flux description bean (I just comment the @Produces and
@FlowDefinition annotations to do that) and rename
src/main/webapp/flux/flux-flow-empty.xml
or
src/main/webapp/flux/flux-flow-simple.xml
to
src/main/webapp/flux/flux-flow.xml
you will be able to test the other situations I described.
Thanks again !
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
On 13/02/2014 19:01, Leonardo Uribe wrote:
Hi
Thanks for the example. It helps to clarify the problem. The
definition of the flow has a problem:
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
String flowId = flux;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
/*flowBuilder.returnNode(returnFromFlux).
fromOutcome(#{flowScopedBean.return});*/
return flowBuilder.getFlow();
}
In this part:
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
you are using the flow id as a viewNodeId. That confuses the
navigation algorithm because the spec says that an outcome can be a
flowId, and in that sense a flowId is a global identifier that cannot
be reused. The fix is just set another id:
flowBuilder.viewNode(start,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
The example only requires some small changes in FlowScopedBean and that's it.
ok for this one, I will try it tomorrow. And can you tell me what was
wrong with XML file (or the empty XML file) ?
Thank you,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
On 12/02/2014 00:42, Thomas Andraschko wrote:
Can't you just switch to DS?
I gave a look to «migrate codi 1.x to deltaspike 0.5» by someone who
seems to know a bit on this topic, posts on this mailing list and is
also known a Gerhard Petracek :-)
http://os890.blogspot.fr/2013/10/migrate-codi-1x-to-deltaspike-05.html
And so I try to apply the dependenc changes from
https://raw.github.com/os890/tomee_mf_stack_001/master/pom.xml
to
https://raw.github.com/os890/tomee_mf_stack_001/codi2ds/pom.xml
I was however stopped at build time by the lack of
- @ProjectStageActivated
- @Advanced
I can easily live without @ProjectStageActivated (used to activate a
phase listener in debug, something which help me a lot when I started to
pla with JSF but that I do not need anymore) and I am now trying to
figure how not to use @Advanced.
I am using this annotation to make converters and validators eligible
injection targets. I think I can also retrieve beans by EL-expressions,
with simple code such as
public class MyHelperClass {
public static T T findBean(String name) {
if ((name == null) || name.isEmpty()) {
return null;
}
return evaluateExpression(#{ + name + });
}
@SuppressWarnings(unchecked)
public static T T evaluateExpression(String expr) {
if ((expr == null) || expr.isEmpty()) {
return null;
}
FacesContext fc = FacesContext.getCurrentInstance();
return (T) fc.getApplication().evaluateExpressionGet(fc,
expr, Object.class);
}
}
MyHelperClass.findBean(toto);
I will try that and keep you posted.
Thanks,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
hi ludovic,
@ProjectStageActivated is called @Exclude in deltaspike and you can just
drop @Advanced.
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-02-12 9:29 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr:
On 12/02/2014 00:42, Thomas Andraschko wrote:
Can't you just switch to DS?
I gave a look to «migrate codi 1.x to deltaspike 0.5» by someone who seems
to know a bit on this topic, posts on this mailing list and is also known a
Gerhard Petracek :-)
http://os890.blogspot.fr/2013/10/migrate-codi-1x-to-deltaspike-05.html
And so I try to apply the dependenc changes from
https://raw.github.com/os890/tomee_mf_stack_001/master/pom.xml
to
https://raw.github.com/os890/tomee_mf_stack_001/codi2ds/pom.xml
I was however stopped at build time by the lack of
- @ProjectStageActivated
- @Advanced
I can easily live without @ProjectStageActivated (used to activate a phase
listener in debug, something which help me a lot when I started to pla with
JSF but that I do not need anymore) and I am now trying to figure how not
to use @Advanced.
I am using this annotation to make converters and validators eligible
injection targets. I think I can also retrieve beans by EL-expressions,
with simple code such as
public class MyHelperClass {
public static T T findBean(String name) {
if ((name == null) || name.isEmpty()) {
return null;
}
return evaluateExpression(#{ + name + });
}
@SuppressWarnings(unchecked)
public static T T evaluateExpression(String expr) {
if ((expr == null) || expr.isEmpty()) {
return null;
}
FacesContext fc = FacesContext.getCurrentInstance();
return (T) fc.getApplication().evaluateExpressionGet(fc,
expr, Object.class);
}
}
MyHelperClass.findBean(toto);
I will try that and keep you posted.
Thanks,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
On 12/02/2014 10:22, Gerhard Petracek wrote: hi ludovic, @ProjectStageActivated is called @Exclude in deltaspike and you can just drop @Advanced. ok, thank you. I still had the same situation with deltaspike (0.5 + your os890-cdi-ext-jsf2-module-api and os890-cdi-ext-jsf2-module-impl or 0.6-SNAPSHOT). So, I digged the clientwindow topic... I read in https://weblogs.java.net/blog/edburns/archive/2013/10/07/jsf-22-clientwindow-links-and-open-new-tab that « Because the Faces Flows feature entirely depends on|ClientWindow|, the usage of Faces Flows will automatically enable|ClientWindow|if it is not enabled already» However, it is not in my case. So I explicitly enabled this with adding context-param param-namejavax.faces.CLIENT_WINDOW_MODE/param-name param-valueurl/param-value /context-param in web.xml. It there some other required config that I should check ? Thanks in avdance, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
hi ludovic, once you enable the window-handling for jsf 2.2+, deltaspike v0.6+ will use it automatically. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-12 10:37 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr: On 12/02/2014 10:22, Gerhard Petracek wrote: hi ludovic, @ProjectStageActivated is called @Exclude in deltaspike and you can just drop @Advanced. ok, thank you. I still had the same situation with deltaspike (0.5 + your os890-cdi-ext-jsf2-module-api and os890-cdi-ext-jsf2-module-impl or 0.6-SNAPSHOT). So, I digged the clientwindow topic... I read in https://weblogs.java.net/blog/edburns/archive/2013/10/07/ jsf-22-clientwindow-links-and-open-new-tab that « Because the Faces Flows feature entirely depends on|ClientWindow|, the usage of Faces Flows will automatically enable|ClientWindow|if it is not enabled already» However, it is not in my case. So I explicitly enabled this with adding context-param param-namejavax.faces.CLIENT_WINDOW_MODE/param-name param-valueurl/param-value /context-param in web.xml. It there some other required config that I should check ? Thanks in avdance, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. +1 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. When I experimented with CODI, I used 1.0.6 snapshot and had the same thing in mind and then i heard that CODI was dead project, and most likely 1.0.6 would not be released. And I did hear and recognize that deltaspike is recommended instead of CODI. Someone, please confirm. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. +1 good question. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : 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 _lifecy -- ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: @FlowScoped, @Named and @ManagedBean
@howard: (as announced back then) codi is in maintenance-mode, because new features will be added to deltaspike. you might have seen the latest updates for using it with ee7. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-12 11:33 GMT+01:00 Howard W. Smith, Jr. smithh032...@gmail.com: On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. +1 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. When I experimented with CODI, I used 1.0.6 snapshot and had the same thing in mind and then i heard that CODI was dead project, and most likely 1.0.6 would not be released. And I did hear and recognize that deltaspike is recommended instead of CODI. Someone, please confirm. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. +1 good question. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : 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
Re: @FlowScoped, @Named and @ManagedBean
This question has been raised on the mailing list several times. The answer is always the same: Released functionality is mature and stable. 0.X indicates that the API might change but so far this has happened like 1-2 times I think and probably took 2 minutes to fix for depending projects. The actual impl is stable though. By following the discussion on the mailing list it's quite clear that they put effort into not only porting CODI but to enhance it as well. I have Deltaspike in production for many, many months with no issues (all though not 0.6-SNAPSHOT). And you can assume it's going to be more tested then code you include yourself to do something similar. The parts regarding JSF is stable for 0.6 so getting the support from a SNAPSHOT right now and replace with stable release later is not a very adventurous. These are the docs for getting started: http://deltaspike.apache.org/jsf.html cheers On 12 February 2014 11:33, Howard W. Smith, Jr. smithh032...@gmail.comwrote: On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. +1 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. When I experimented with CODI, I used 1.0.6 snapshot and had the same thing in mind and then i heard that CODI was dead project, and most likely 1.0.6 would not be released. And I did hear and recognize that deltaspike is recommended instead of CODI. Someone, please confirm. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. +1 good question. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : 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
Re: @FlowScoped, @Named and @ManagedBean
On Wed, Feb 12, 2014 at 5:40 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @howard: (as announced back then) codi is in maintenance-mode, because new features will be added to deltaspike. you might have seen the latest updates for using it with ee7. +1 thanks Gerhard
Re: @FlowScoped, @Named and @ManagedBean
+1 thanks Karl. That is all good to know and good to hear from one of the users. :) And for the record, if Thomas recommends it, I know it's a good recommendation. On Wed, Feb 12, 2014 at 5:48 AM, Karl Kildén karl.kil...@gmail.com wrote: This question has been raised on the mailing list several times. The answer is always the same: Released functionality is mature and stable. 0.X indicates that the API might change but so far this has happened like 1-2 times I think and probably took 2 minutes to fix for depending projects. The actual impl is stable though. By following the discussion on the mailing list it's quite clear that they put effort into not only porting CODI but to enhance it as well. I have Deltaspike in production for many, many months with no issues (all though not 0.6-SNAPSHOT). And you can assume it's going to be more tested then code you include yourself to do something similar. The parts regarding JSF is stable for 0.6 so getting the support from a SNAPSHOT right now and replace with stable release later is not a very adventurous. These are the docs for getting started: http://deltaspike.apache.org/jsf.html cheers On 12 February 2014 11:33, Howard W. Smith, Jr. smithh032...@gmail.com wrote: On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. +1 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. When I experimented with CODI, I used 1.0.6 snapshot and had the same thing in mind and then i heard that CODI was dead project, and most likely 1.0.6 would not be released. And I did hear and recognize that deltaspike is recommended instead of CODI. Someone, please confirm. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. +1 good question. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : 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 (
Re: @FlowScoped, @Named and @ManagedBean
On 12/02/2014 10:37, l.pe...@senat.fr wrote:
On 12/02/2014 10:22, Gerhard Petracek wrote:
hi ludovic,
@ProjectStageActivated is called @Exclude in deltaspike and you can just
drop @Advanced.
ok, thank you.
I still had the same situation with deltaspike (0.5 + your
os890-cdi-ext-jsf2-module-api and os890-cdi-ext-jsf2-module-impl or
0.6-SNAPSHOT).
So, I digged the clientwindow topic... I read in
https://weblogs.java.net/blog/edburns/archive/2013/10/07/jsf-22-clientwindow-links-and-open-new-tab
that
« Because the Faces Flows feature entirely depends
on|ClientWindow|, the usage of Faces Flows will automatically
enable|ClientWindow|if it is not enabled already»
However, it is not in my case.
So I explicitly enabled this with adding
context-param
param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
param-valueurl/param-value
/context-param
in web.xml.
It there some other required config that I should check ?
ok, so with:
* deltaspike 0.6-SNAPSHOT
* org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-{api,impl}
:1.0.5_0.5_01}
* javax.faces.CLIENT_WINDOW_MODE = url
... it is starting to work.
In fact, I could trigger flow transitions only using a h:link for now.
So neither
* p:menuitem value=Let's test outcome=flow1 / in a PF p:menubar
* p:commandButton value=Let's test 2 action=flow1 /
* h:commandButton value=Let's test 3 action=flow1 /
* h:commandButton value=Let's test 4 action=/flow1 /
* h:commandButton value=Let's test 5 action=/flow1/flow1 /
* a direct transition to /flow1/flow1.xhtml (by typing the URL in the
brower url bar)
work.
But
* h:link outcome=flow1Test 6/h:link
* h:link outcome=/flow1/flow1.xhtmlTest 7/h:link
do work.
By working, I mean that the FlowHandler.FLOW_ID_REQUEST_PARAM_NAME
(jffi) is defined, a transition is detected and FlowHandlerImpl
processes it.
I found only one place defining it in myfaces 2.2 impl source,
myfaces-impl-2.2.0/org/apache/myfaces/shared/renderkit/html/util/OutcomeTargetUtils.java:145
, in
OutcomeTargetUtils.getOutcomeTargetHref .
Either I missed something big, either it does not fit my requirements.
When I read «Java EE 7 tutorial - 16.3 Using Faces Flows»
http://docs.oracle.com/javaee/7/tutorial/doc/jsf-configure003.htm
syntaxes such as
h:commandButton value=Exit Flow action=returnFromCheckoutFlow/
seemed supported.
Moreover, I state that it works because I see a flow transition taking
place. But I could not figure how to make it finally work (without ).
When I try to use an empty flow1-flow.xml, or to use a flow1-flow.xml
such as
?xml version=1.0 encoding=UTF-8?
faces-config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://xmlns.jcp.org/xml/ns/javaee'
xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
version='2.2'
flow-definition id=flow1
display-nameTest display name/display-name
descriptionTest description/description
flow-return id=success
from-outcome/accueil.xhtml/from-outcome
/flow-return
flow-return id=error
from-outcome/versions.xhtml/from-outcome
/flow-return
/flow-definition
/faces-config
(dummy test returns...)
there is a problem at the outcome computation step.
When I use a configuration class such as
public class Flow1 implements Serializable {
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
String flowId = flow1;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
return flowBuilder.getFlow();
}
}
there is a first transition from no flow (being on /accueil.xhtml) to
flow1 (going to /flow1/flow1.xhtml). flow1 is correctly stacked at
this step.
But then, another transition from /flow1/flow1.xhtml to
/flow1/flow1.xhtml is immediatly triggered by an automatically generated
(I think) navigation case. During this transition, flow1 is popped from
stack and a null pointer exception occurs.
Any help welcomed... I would be glad to have a look at simple test cases
using MyFaces 2.2.
But I might switch back to good old @ViewAccessScoped for the time being
- spent some days on this Faces Flows stuff already.
Thanks for the help and work anyway. It is quite normal to me to have
this kind of troubleshooting on new stuff...
Best regards,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
hi ludovic,
the add-on is for: codi 1.0.5 - deltaspike 0.5 (that's the reason for:
1.0.5_0.5_01)
please don't use it with 0.6 (currently only @ViewAccessScoped is missing
in ds)
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-02-12 14:38 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr:
On 12/02/2014 10:37, l.pe...@senat.fr wrote:
On 12/02/2014 10:22, Gerhard Petracek wrote:
hi ludovic,
@ProjectStageActivated is called @Exclude in deltaspike and you can just
drop @Advanced.
ok, thank you.
I still had the same situation with deltaspike (0.5 + your
os890-cdi-ext-jsf2-module-api and os890-cdi-ext-jsf2-module-impl or
0.6-SNAPSHOT).
So, I digged the clientwindow topic... I read in
https://weblogs.java.net/blog/edburns/archive/2013/10/07/
jsf-22-clientwindow-links-and-open-new-tab
that
« Because the Faces Flows feature entirely depends on|ClientWindow|,
the usage of Faces Flows will automatically enable|ClientWindow|if it is
not enabled already»
However, it is not in my case.
So I explicitly enabled this with adding
context-param
param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
param-valueurl/param-value
/context-param
in web.xml.
It there some other required config that I should check ?
ok, so with:
* deltaspike 0.6-SNAPSHOT
* org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-{api,impl}
:1.0.5_0.5_01}
* javax.faces.CLIENT_WINDOW_MODE = url
... it is starting to work.
In fact, I could trigger flow transitions only using a h:link for now.
So neither
* p:menuitem value=Let's test outcome=flow1 / in a PF p:menubar
* p:commandButton value=Let's test 2 action=flow1 /
* h:commandButton value=Let's test 3 action=flow1 /
* h:commandButton value=Let's test 4 action=/flow1 /
* h:commandButton value=Let's test 5 action=/flow1/flow1 /
* a direct transition to /flow1/flow1.xhtml (by typing the URL in the
brower url bar)
work.
But
* h:link outcome=flow1Test 6/h:link
* h:link outcome=/flow1/flow1.xhtmlTest 7/h:link
do work.
By working, I mean that the FlowHandler.FLOW_ID_REQUEST_PARAM_NAME
(jffi) is defined, a transition is detected and FlowHandlerImpl processes
it.
I found only one place defining it in myfaces 2.2 impl source,
myfaces-impl-2.2.0/org/apache/myfaces/shared/renderkit/html/
util/OutcomeTargetUtils.java:145 , in
OutcomeTargetUtils.getOutcomeTargetHref .
Either I missed something big, either it does not fit my requirements.
When I read «Java EE 7 tutorial - 16.3 Using Faces Flows»
http://docs.oracle.com/javaee/7/tutorial/doc/jsf-configure003.htm
syntaxes such as
h:commandButton value=Exit Flow action=returnFromCheckoutFlow/
seemed supported.
Moreover, I state that it works because I see a flow transition taking
place. But I could not figure how to make it finally work (without ).
When I try to use an empty flow1-flow.xml, or to use a flow1-flow.xml such
as
?xml version=1.0 encoding=UTF-8?
faces-config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://xmlns.jcp.org/xml/ns/javaee'
xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
version='2.2'
flow-definition id=flow1
display-nameTest display name/display-name
descriptionTest description/description
flow-return id=success
from-outcome/accueil.xhtml/from-outcome
/flow-return
flow-return id=error
from-outcome/versions.xhtml/from-outcome
/flow-return
/flow-definition
/faces-config
(dummy test returns...)
there is a problem at the outcome computation step.
When I use a configuration class such as
public class Flow1 implements Serializable {
@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
{
String flowId = flow1;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
return flowBuilder.getFlow();
}
}
there is a first transition from no flow (being on /accueil.xhtml) to
flow1 (going to /flow1/flow1.xhtml). flow1 is correctly stacked at this
step.
But then, another transition from /flow1/flow1.xhtml to /flow1/flow1.xhtml
is immediatly triggered by an automatically generated (I think) navigation
case. During this transition, flow1 is popped from stack and a null
pointer exception occurs.
Any help welcomed... I would be glad to have a look at simple test cases
using MyFaces 2.2.
But I might switch back to good old @ViewAccessScoped for the time being -
spent some days on this Faces Flows stuff already.
Thanks for the help and work anyway. It is quite normal to me to have this
kind of troubleshooting on new
Re: @FlowScoped, @Named and @ManagedBean
On 12/02/2014 15:13, Gerhard Petracek wrote: hi ludovic, the add-on is for: codi 1.0.5 - deltaspike 0.5 (that's the reason for: 1.0.5_0.5_01) please don't use it with 0.6 (currently only @ViewAccessScoped is missing in ds) ok, I will do that as I do not need clientwindow support as long as I do not use Faces Flows And I will keep an eye on https://issues.apache.org/jira/browse/DELTASPIKE-487 ;-) Thx, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
Thanks for the info, Karl. Good to know. On Wednesday, February 12, 2014, Karl Kildén karl.kil...@gmail.com wrote: This question has been raised on the mailing list several times. The answer is always the same: Released functionality is mature and stable. 0.X indicates that the API might change but so far this has happened like 1-2 times I think and probably took 2 minutes to fix for depending projects. The actual impl is stable though. By following the discussion on the mailing list it's quite clear that they put effort into not only porting CODI but to enhance it as well. I have Deltaspike in production for many, many months with no issues (all though not 0.6-SNAPSHOT). And you can assume it's going to be more tested then code you include yourself to do something similar. The parts regarding JSF is stable for 0.6 so getting the support from a SNAPSHOT right now and replace with stable release later is not a very adventurous. These are the docs for getting started: http://deltaspike.apache.org/jsf.html cheers On 12 February 2014 11:33, Howard W. Smith, Jr. smithh032...@gmail.comjavascript:; wrote: On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. +1 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. When I experimented with CODI, I used 1.0.6 snapshot and had the same thing in mind and then i heard that CODI was dead project, and most likely 1.0.6 would not be released. And I did hear and recognize that deltaspike is recommended instead of CODI. Someone, please confirm. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. +1 good question. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : 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. -- ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: @FlowScoped, @Named and @ManagedBean
Hi Here some answers: LP In fact, I could trigger flow transitions only using a h:link for now. LP LP So neither LP * p:menuitem value=Let's test outcome=flow1 / in a PF p:menubar LP * p:commandButton value=Let's test 2 action=flow1 / LP * h:commandButton value=Let's test 3 action=flow1 / LP * h:commandButton value=Let's test 4 action=/flow1 / LP * h:commandButton value=Let's test 5 action=/flow1/flow1 / LP * a direct transition to /flow1/flow1.xhtml (by typing the URL in the brower url bar) LP LP work. LP LP But LP * h:link outcome=flow1Test 6/h:link LP * h:link outcome=/flow1/flow1.xhtmlT LP est 7/h:link LP LP do work. LP LP By working, I mean that the FlowHandler.FLOW_ID_REQUEST_PARAM_NAME LP (jffi) is defined, a transition is detected and FlowHandlerImpl processes it. It is ok. h:link triggers a GET request, so the request parameter is added. In the other cases, the transition is done when NavigationHandler.handleNavigation(...) is processed. p:menuitem don't implement the new spec related to calculate the outcome in case of a flow (check not null on navigationCase.getToFlowDocumentId() and add the request parameters). One partial solution could be add the required request parameter manually. LP When I try to use an empty flow1-flow.xml, or to use a flow1-flow.xml such as ... LP there is a problem at the outcome computation step. There is a small bug when an empty flow is used, which was already fixed on: https://issues.apache.org/jira/browse/MYFACES-3845 In the xml you need to define the start node. But looking JSF 2.2 section 11.4.3.3 it says: ... The following conventions apply to flows defined in this manner. Any flow definition in the corresponding -flow.xml file will override any of the conventions in the case of a conflict - Every vdl file in that directory is a view node of that flow. - The start node of the flow is the view whose name is the same as the name of the flow. - Navigation among any of the views in the directory is considered to be within the flow. - The flow defining document id is the empty string. ... Checking the code it seems the conditions has been applied but only when the empty flow is provided. It is a bug. Please create an issue under jira and I'll fix it. LP there is a first transition from no flow (being on /accueil.xhtml) to flow1 LP (going to /flow1/flow1.xhtml). flow1 is correctly stacked at this step. LP But then, another transition from /flow1/flow1.xhtml to /flow1/flow1.xhtml LP is immediatly triggered by an automatically generated (I think) navigation case. LP During this transition, flow1 is popped from stack and a null pointer exception occurs. This is an edge case. Theorically it should work. Could you please provide the stack trace, so I can investigate it further?. regards, Leonardo 2014-02-12 11:44 GMT-05:00 Kito Mann kito.m...@virtua.com: Thanks for the info, Karl. Good to know. On Wednesday, February 12, 2014, Karl Kildén karl.kil...@gmail.com wrote: This question has been raised on the mailing list several times. The answer is always the same: Released functionality is mature and stable. 0.X indicates that the API might change but so far this has happened like 1-2 times I think and probably took 2 minutes to fix for depending projects. The actual impl is stable though. By following the discussion on the mailing list it's quite clear that they put effort into not only porting CODI but to enhance it as well. I have Deltaspike in production for many, many months with no issues (all though not 0.6-SNAPSHOT). And you can assume it's going to be more tested then code you include yourself to do something similar. The parts regarding JSF is stable for 0.6 so getting the support from a SNAPSHOT right now and replace with stable release later is not a very adventurous. These are the docs for getting started: http://deltaspike.apache.org/jsf.html cheers On 12 February 2014 11:33, Howard W. Smith, Jr. smithh032...@gmail.comjavascript:; wrote: On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote: Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. +1 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. When I experimented with CODI, I used 1.0.6 snapshot and had the same thing in mind and then i heard that CODI was dead project, and most likely 1.0.6 would not be released. And I did hear and recognize that deltaspike is recommended instead of CODI. Someone, please confirm. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. +1 good question. On Tuesday, February 11, 2014, Thomas Andraschko
Re: @FlowScoped, @Named and @ManagedBean
On 11/02/2014 03:30, Leonardo Uribe wrote:
Hi
Thank you for your quick reply.
2014-02-10 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
Dear all,
I am starting to really use JSF 2.2. I am trying to use Faces Flows. I am
starting with a very simple flow, whose name is flow1.
So, under src/main/webapp, I have a flow1 directory containing
flow1-flow.xml
flow1.xhtml
flow1b.xhtml
flow1-flow.xml contains :
?xml version=1.0 encoding=UTF-8?
faces-config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://xmlns.jcp.org/xml/ns/javaee'
xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
version='2.2'
flow-definition id=flow1
flow-return id=returnFromFlow1
from-outcome/accueil/from-outcome
/flow-return
/flow-definition
/faces-config
With such a simple config, using conventions would be a better choice than
configuration, but I plan to add more things to it... :-)
I use a @FlowScoped bean declared this way :
@Named
@FlowScoped(flow1)
public class MinintFileContext implements Serializable {
}
and it does not work. I have the following exception :
javax.servlet.ServletException: javax.servlet.ServletException:
javax.el.ELException: javax.enterprise.context.ContextNotActiveException:
WebBeans context with scope type annotation @FlowScoped does not exist
within current thread
To make it work, I have to use @ManagedBean instead of @Named.
My first question is : I do not understand why... In my (obviously wrong)
understanding, @Named was a super-set of CDI-managed beans, including
@ManagedBean-s.
@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.
Thanks again,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
DeltaSpike is not a CDI implementation but a helper library.
I think OWB supports FlowScoped at least it has been tested in TomEE
AFAIK, anyone can confirm?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-11 10:28 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr:
On 11/02/2014 03:30, Leonardo Uribe wrote:
Hi
Thank you for your quick reply.
2014-02-10 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
Dear all,
I am starting to really use JSF 2.2. I am trying to use Faces Flows. I am
starting with a very simple flow, whose name is flow1.
So, under src/main/webapp, I have a flow1 directory containing
flow1-flow.xml
flow1.xhtml
flow1b.xhtml
flow1-flow.xml contains :
?xml version=1.0 encoding=UTF-8?
faces-config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://xmlns.jcp.org/xml/ns/javaee'
xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
version='2.2'
flow-definition id=flow1
flow-return id=returnFromFlow1
from-outcome/accueil/from-outcome
/flow-return
/flow-definition
/faces-config
With such a simple config, using conventions would be a better choice
than
configuration, but I plan to add more things to it... :-)
I use a @FlowScoped bean declared this way :
@Named
@FlowScoped(flow1)
public class MinintFileContext implements Serializable {
}
and it does not work. I have the following exception :
javax.servlet.ServletException: javax.servlet.ServletException:
javax.el.ELException: javax.enterprise.context.ContextNotActiveException:
WebBeans context with scope type annotation @FlowScoped does not exist
within current thread
To make it work, I have to use @ManagedBean instead of @Named.
My first question is : I do not understand why... In my (obviously wrong)
understanding, @Named was a super-set of CDI-managed beans, including
@ManagedBean-s.
@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.
Thanks again,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: @FlowScoped, @Named and @ManagedBean
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 All suggestions welcomed ! Best regards, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
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.
|
Re: @FlowScoped, @Named and @ManagedBean
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.
|
Re: @FlowScoped, @Named and @ManagedBean
Can't you just switch to DS?
2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com:
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.
|
Re: @FlowScoped, @Named and @ManagedBean
How mature is DeltaSpike? It's only at 0.05. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : 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 _lifecy -- ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: @FlowScoped, @Named and @ManagedBean
Deltaspike modules have consistently been usable off the shelf and would be a far better solution then doing tricks to make CODI work. However using JSF stuff would require you to use 0.6-SNAPSHOT. I would actually just use @SessionScoped, write a TODO and wait for 0.6 release if I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed for 0.6 afaik. On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote: How mature is DeltaSpike? It's only at 0.05. On Tuesday, February 11, 2014, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.comjavascript:; : 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 _lifecy -- ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
@FlowScoped, @Named and @ManagedBean
Dear all,
I am starting to really use JSF 2.2. I am trying to use Faces Flows. I
am starting with a very simple flow, whose name is flow1.
So, under src/main/webapp, I have a flow1 directory containing
flow1-flow.xml
flow1.xhtml
flow1b.xhtml
flow1-flow.xml contains :
?xml version=1.0 encoding=UTF-8?
faces-config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://xmlns.jcp.org/xml/ns/javaee'
xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
version='2.2'
flow-definition id=flow1
flow-return id=returnFromFlow1
from-outcome/accueil/from-outcome
/flow-return
/flow-definition
/faces-config
With such a simple config, using conventions would be a better choice
than configuration, but I plan to add more things to it... :-)
I use a @FlowScoped bean declared this way :
@Named
@FlowScoped(flow1)
public class MinintFileContext implements Serializable {
}
and it does not work. I have the following exception :
javax.servlet.ServletException: javax.servlet.ServletException:
javax.el.ELException:
javax.enterprise.context.ContextNotActiveException: WebBeans context
with scope type annotation @FlowScoped does not exist within current thread
To make it work, I have to use @ManagedBean instead of @Named.
My first question is : I do not understand why... In my (obviously
wrong) understanding, @Named was a super-set of CDI-managed beans,
including @ManagedBean-s.
Another question...
I am using PrimeFaces p:menubar . I noticed that I can not use /flow1
as the outcome of a menuitem
Ex : p:menuitem value=Blah blah blah outcome=/flow1 /
I have to use
p:menuitem value=Blah blah blah outcome=/flow1/flow1 /
Why ? This might be a PF-specific question.
Finally, I am failing to use the flow-return configuration.
I tried
p:commandButton value=Terminer action=returnFromFlow1/
and
h:commandButton value=Terminer action=returnFromFlow1/
But it just does not work.
So, I tried to change the config to
flow-return id=returnFromFlow1
from-outcome#{minintFileContext.returnValue}/from-outcome
/flow-return
and added a
public String getReturnValue() {
return /accueil;
}
method to he MinintFileContext bean, but it does not work better.
Any idea ?
Thanks in advance
I have the following JSF-related or generic dependencies (I mean that I
remove in-house dependencies from the following tree) :
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @
faces-dependencies ---
[INFO] fr.senat:faces-dependencies:jar:4.0.0-SNAPSHOT
[INFO] +- commons-lang:commons-lang:jar:2.6:compile
[INFO] +- org.apache.commons:commons-lang3:jar:3.1:compile
[INFO] +- org.apache.tomcat:tomcat-catalina:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-servlet-api:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-juli:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-annotations-api:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-api:jar:7.0.47:provided
[INFO] | \- org.apache.tomcat:tomcat-util:jar:7.0.47:provided
[INFO] +- org.apache.myfaces.core:myfaces-api:jar:2.2.0:compile
[INFO] +- org.apache.myfaces.core:myfaces-impl:jar:2.2.0:compile
[INFO] | +- commons-collections:commons-collections:jar:3.2:compile
[INFO] | +- commons-codec:commons-codec:jar:1.3:compile
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.8.3:compile
[INFO] | | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] | \- commons-digester:commons-digester:jar:1.8:compile
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-api:jar:1.0.5:compile
[INFO] | \-
org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-api:jar:1.0.5:compile
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-impl:jar:1.0.5:runtime
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jpa1-module-api:jar:1.0.5:compile
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jpa1-module-impl:jar:1.0.5:runtime
[INFO] | \-
org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-impl:jar:1.0.5:runtime
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-bv1-module-api:jar:1.0.5:compile
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-bv1-module-impl:jar:1.0.5:runtime
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-scripting-module-api:jar:1.0.5:compile
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-scripting-module-impl:jar:1.0.5:runtime
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-api:jar:1.0.5:compile
[INFO] +-
org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-impl:jar:1.0.5:runtime
[INFO] +-
org.apache.geronimo.specs:geronimo-atinject_1.0_spec:jar:1.0:compile
[INFO] +-
Re: @FlowScoped, @Named and @ManagedBean
Hi
2014-02-10 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
Dear all,
I am starting to really use JSF 2.2. I am trying to use Faces Flows. I am
starting with a very simple flow, whose name is flow1.
So, under src/main/webapp, I have a flow1 directory containing
flow1-flow.xml
flow1.xhtml
flow1b.xhtml
flow1-flow.xml contains :
?xml version=1.0 encoding=UTF-8?
faces-config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://xmlns.jcp.org/xml/ns/javaee'
xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
version='2.2'
flow-definition id=flow1
flow-return id=returnFromFlow1
from-outcome/accueil/from-outcome
/flow-return
/flow-definition
/faces-config
With such a simple config, using conventions would be a better choice than
configuration, but I plan to add more things to it... :-)
I use a @FlowScoped bean declared this way :
@Named
@FlowScoped(flow1)
public class MinintFileContext implements Serializable {
}
and it does not work. I have the following exception :
javax.servlet.ServletException: javax.servlet.ServletException:
javax.el.ELException: javax.enterprise.context.ContextNotActiveException:
WebBeans context with scope type annotation @FlowScoped does not exist
within current thread
To make it work, I have to use @ManagedBean instead of @Named.
My first question is : I do not understand why... In my (obviously wrong)
understanding, @Named was a super-set of CDI-managed beans, including
@ManagedBean-s.
@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.
Another question...
I am using PrimeFaces p:menubar . I noticed that I can not use /flow1 as
the outcome of a menuitem
Ex : p:menuitem value=Blah blah blah outcome=/flow1 /
I have to use
p:menuitem value=Blah blah blah outcome=/flow1/flow1 /
Why ? This might be a PF-specific question.
Try in this way:
p:menuitem value=Blah blah blah outcome=flow1 /
If you put /flow1 as outcome, the navigation algorithm will
interpret this as a normal navigation to a page (/flow1.xhtml), so the
flow scope will not be activated and the bean will not be instantiated
correctly. It should work without any changes in primefaces, because
the outcome should be calculated using
ConfigurableNavigationHandler.getNavigationCase(...).
Finally, I am failing to use the flow-return configuration.
I tried
p:commandButton value=Terminer action=returnFromFlow1/
and
h:commandButton value=Terminer action=returnFromFlow1/
But it just does not work.
So, I tried to change the config to
flow-return id=returnFromFlow1
from-outcome#{minintFileContext.returnValue}/from-outcome
/flow-return
and added a
public String getReturnValue() {
return /accueil;
}
method to he MinintFileContext bean, but it does not work better.
Any idea ?
Try it again, maybe the reason is that it seems you are inside the
flow but it is not. You can check if you are in the flow using
facesContext.getApplication().getFlowHandler().isActive(...).
regards,
Leonardo Uribe
Thanks in advance
I have the following JSF-related or generic dependencies (I mean that I
remove in-house dependencies from the following tree) :
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @
faces-dependencies ---
[INFO] fr.senat:faces-dependencies:jar:4.0.0-SNAPSHOT
[INFO] +- commons-lang:commons-lang:jar:2.6:compile
[INFO] +- org.apache.commons:commons-lang3:jar:3.1:compile
[INFO] +- org.apache.tomcat:tomcat-catalina:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-servlet-api:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-juli:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-annotations-api:jar:7.0.47:provided
[INFO] | +- org.apache.tomcat:tomcat-api:jar:7.0.47:provided
[INFO] | \- org.apache.tomcat:tomcat-util:jar:7.0.47:provided
[INFO] +- org.apache.myfaces.core:myfaces-api:jar:2.2.0:compile
[INFO] +- org.apache.myfaces.core:myfaces-impl:jar:2.2.0:compile
[INFO] | +- commons-collections:commons-collections:jar:3.2:compile
[INFO] | +- commons-codec:commons-codec:jar:1.3:compile
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.8.3:compile
[INFO] | | \-
