I successfully intigrated the Myfaces CODI (myfaces-extcdi-bundle-jsf20-1.0.1.jar) but the javax.faces.bean.ViewScoped annotation is not working.
So far i know it schould.
For instance, the @ViewAccessScoped annotation of codi works fine.
Why is that ?
This topic has been locked.
8 replies Latest Post - 2013-01-18T13:36:04Z by P.Hackl@curecomp.com
Pinned topic WAS 220.127.116.11 Myfaces CODI @ViewScoped
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-18T13:36:04Z at 2013-01-18T13:36:04Z by P.Hackl@curecomp.com
BobG 1100006RQ5624 PostsACCEPTED ANSWER
Re: WAS 18.104.22.168 Myfaces CODI @ViewScoped2011-09-28T20:14:59Z in response to P.Hackl@curecomp.com@ViewScope should work. Can you better define "not working".
WAS 8 contains an implementation of JSF 2.0. Have you tried with just that (i.e. do not add your own to the project)?
Re: WAS 22.214.171.124 Myfaces CODI @ViewScoped2011-09-29T11:47:24Z in response to BobGWe dont want to use the old and as far as i know buggy version of myfaces shipped by ibm.
And @ViewScoped not working means, that the bean is instantiated every time when a request comes (e.g.: Ajax).
This was my experience.
A college has tried it out to and he says that the bean is instantiated partially when he keeps on the current view.
Means the bean survives over several request and than it is newly instantiated. It seems to be done randomly.
This is a very strange behaviour.
For know we will use @ViewAccessScoped of CODI
RohitK 110000MP6H1 PostACCEPTED ANSWER
Re: WAS 126.96.36.199 Myfaces CODI @ViewScoped2011-09-29T14:13:38Z in response to P.Hackl@curecomp.comDear Peter,
Can you please send us your application via an attachment in the forum response and tell us the steps to reproduce this issue.
Apache Open Web Beans Committer
Re: WAS 188.8.131.52 Myfaces CODI @ViewScoped2011-09-30T16:08:41Z in response to RohitKI will try to reproduce the effect in a sample application but I think that the recreation of the @ViewScoped-Beans is maybe related to the JSTL-Tags that we are using. Maybe these are triggering a view rebuild which has the effect of removing the bean from view and causing a recreation of it. ViewAccessScoped-Beans will survive the view recreation and be stored in the view scope/view root of the next view if used, which is in my opinion what is actually happening. Correct me if I am wrong but I think the problem is not related to the viewscope.
Re: WAS 184.108.40.206 Myfaces CODI @ViewScoped2011-10-02T14:25:56Z in response to P.Hackl@curecomp.comI made a simple sample application and it seems that really the jstl tags are responsible for the recreation of the bean.
For now we need the jstl tag c:forEach.
I add the sample application to this post.
Re: WAS 220.127.116.11 Myfaces CODI @ViewScoped2013-01-18T13:36:04Z in response to P.Hackl@curecomp.comThis occurred because we do use JSTL tags which will cause a rebuild of the view and therefore a reinstantiation of the beans addressed via EL to, on every request regardless if its an intial or partial one.
CODI @ViewAccessScoped overcomes this issue because this annotation allows you to access the former view on the intial request of another view.
view1 -> view2 (can access view1 on initial call)