On Feb 12, 2014 1:40 AM, "Karl Kildén" <[email protected]> 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 <[email protected]> wrote: > > > How mature is DeltaSpike? It's only at 0.05. +1 good question. > > > > On Tuesday, February 11, 2014, Thomas Andraschko < > > [email protected]> wrote: > > > > > Can't you just switch to DS? > > > > > > > > > 2014-02-11 18:46 GMT+01:00 Leonardo Uribe <[email protected] <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 [email protected] <[email protected]>: > > > > > On 11/02/2014 14:51, [email protected] wrote: > > > > >> > > > > >> On 11/02/2014 10:28, [email protected] 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 > >
