+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 ( > > > > > > >>> > > > > > > > > > > > > > > > > > > > > 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 > > > > > > >
