There are two separate issues here - most likely having different causes:

1. init/destroy not always firing when needed (inconsistent behavior)
2. other lifecycle events never firing at all

I spent some time looking at init/destroy issue. Seems like the page bean doesn't always get added to the servlet request attribute map. If it does, the listener handles delivery of the init event to the bean correctly. Also in case it is added and init is fired, i always see corresponding destroy firing ok.

Hi LLia,

I could build a pre-release bundle this week. Would you like to try it ... Let me know, I coud attach to this jira.

thanks,
Frank

Hi Frank, did you fix the problem? I am asking because I looked at svn but didn't see any commits marked with this jira number. I can test the new bundle against the little test project that i described in this jira as soon as you tell me that the problem is fixed. Thanks a lot, ILIA

jira has a limit of 10M, so I post it on forum instead. The problem is fixed within netbeans bundle. It is nightly build bundle. thanks,

Frank, the night build that you attached to the forum post is performing better but still has some problems - see the log below. I am running the same 2-page project TestIcefaces (attached to the forum post).

– original request to Page1
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@1b3e93
@ICE view id=/Page1.iface
Constructor() TestIcefaces.Page1@6e8791
init() TestIcefaces.Page1@6e8791
beforeRenderResponse
prerender() TestIcefaces.Page1@6e8791
afterRenderResponse
destroy() TestIcefaces.Page1@6e8791
destroy() TestIcefaces.Page1@6e8791 ------------------------------ why second destroy call on the same bean?

– button on Page1 clicked
Constructor() TestIcefaces.Page1@1560d4c ---------------------- no init() after this constructor
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@1b3e93
@ICE view id=/Page1.iface
preprocess() TestIcefaces.Page1@1560d4c
button1_action() TestIcefaces.Page1@1560d4c
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@832b87
@ICE view id=/Page2.jsp
Constructor() TestIcefaces.Page2@19ebfd1 ---------------------- no init() after this constructor
prerender() TestIcefaces.Page2@19ebfd1
destroy() TestIcefaces.Page1@1560d4c
destroy() TestIcefaces.Page2@19ebfd1

– button on Page2 clicked
Constructor() TestIcefaces.Page2@d1f3c3 ---------------------- no init() after this constructor
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@832b87
@ICE view id=/Page2.jsp
preprocess() TestIcefaces.Page2@d1f3c3
button1_action() TestIcefaces.Page2@d1f3c3
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@1dac112
@ICE view id=/Page1.jsp
Constructor() TestIcefaces.Page1@b9ba02 ---------------------- no init() after this constructor
prerender() TestIcefaces.Page1@b9ba02
destroy() TestIcefaces.Page1@b9ba02
destroy() TestIcefaces.Page2@d1f3c3

Frank, just for completeness, i ran the project with standardRequestScope = false. Here is the log:

– original request to Page1
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@167a209
@ICE view id=/Page1.iface
Constructor() TestIcefaces.Page1@6f5ae2
init() TestIcefaces.Page1@6f5ae2
beforeRenderResponse
prerender() TestIcefaces.Page1@6f5ae2
afterRenderResponse
destroy() TestIcefaces.Page1@6f5ae2
destroy() TestIcefaces.Page1@6f5ae2

– button on Page1 clicked
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@167a209
@ICE view id=/Page1.iface
preprocess() TestIcefaces.Page1@6f5ae2
button1_action() TestIcefaces.Page1@6f5ae2
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@1930089
@ICE view id=/Page2.jsp
Constructor() TestIcefaces.Page2@860ba
prerender() TestIcefaces.Page2@860ba
destroy() TestIcefaces.Page1@6f5ae2
destroy() TestIcefaces.Page2@860ba

– button on Page2 clicked
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@1930089
@ICE view id=/Page2.jsp
preprocess() TestIcefaces.Page2@860ba
button1_action() TestIcefaces.Page2@860ba
@ICE view=com.icesoft.faces.component.NamespacingViewRoot@1f12248
@ICE view id=/Page1.jsp
prerender() TestIcefaces.Page1@6f5ae2
destroy() TestIcefaces.Page1@6f5ae2
destroy() TestIcefaces.Page2@860ba

Test logs for Feb 19, 2008 build - still a lot of problems:

============= standardRequestScope = true (should behave exactly like standard JSF) ================

– original request to Page1
Constructor() TestIcefaces.Page1@1b3aac6
init() TestIcefaces.Page1@1b3aac6
prerender() TestIcefaces.Page1@1b3aac6
destroy() TestIcefaces.Page1@1b3aac6

– button on Page1 clicked
Constructor() TestIcefaces.Page1@adb210 ---------------------- no init() after this constructor
preprocess() TestIcefaces.Page1@adb210
button1_action() TestIcefaces.Page1@adb210
Constructor() TestIcefaces.Page2@1854518
prerender() TestIcefaces.Page2@1854518
--------------------------------------------------------------------------------- no destroy() for either of the beans

– button on Page2 clicked
Constructor() TestIcefaces.Page2@1663cf4 ---------------------- no init() after this constructor
preprocess() TestIcefaces.Page2@1663cf4
button1_action() TestIcefaces.Page2@1663cf4
Constructor() TestIcefaces.Page1@e76547
prerender() TestIcefaces.Page1@e76547
--------------------------------------------------------------------------------- no destroy() for either of the beans

============= standardRequestScope = false ================

– original request to Page1
Constructor() TestIcefaces.Page1@d78fb4
init() TestIcefaces.Page1@d78fb4
prerender() TestIcefaces.Page1@d78fb4
destroy() TestIcefaces.Page1@d78fb4 ------------------------------- why destroy(), if this instance of the bean is not actually destroyed?

– button on Page1 clicked
preprocess() TestIcefaces.Page1@d78fb4
button1_action() TestIcefaces.Page1@d78fb4
Constructor() TestIcefaces.Page2@13a30bd ---------------------- no init() after this constructor
prerender() TestIcefaces.Page2@13a30bd

– button on Page2 clicked
preprocess() TestIcefaces.Page2@13a30bd
button1_action() TestIcefaces.Page2@13a30bd
prerender() TestIcefaces.Page1@d78fb4

This issue of a great concern and is delaying the development; it is slated to be released in the version 1.7.1, however the status is still unresolved. What is the status on this issue?

generic problem reassigned

NetBeans projects make use of the following listener variants:

com.sun.rave.web.ui.appbase.servlet.LifecycleListener
com.sun.rave.web.ui.appbase.faces.ActionListenerImpl
com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl

The LifecycleListener receives Servlet-level events, such as for Session and Request attribute changes.

The ActionListener receives JSF Action Events.

The ViewHandler intercepts JSF rendering and execution to produce call the prerender() and preprocess() callbacks. Although JSF has an extension mechanism (decorator pattern) for ViewHandlers, generally different ViewHandlers will conflict and the resolution is to integrate the functionality of the different ViewHandlers. We will evaluate this approach for the rave ViewHandler (as well as decoration; it does work in some circumstances, but it is very sensitive to the order that the ViewHandlers are loaded). Further, the other two listeners (which should not present substantial complication on their own) require interaction with the rave ViewHandler.

Frank, could you comment on how we already integrate with each of the three listeners?

(For each of the three listeners, please comment on the specific things we are currently doing.)

Using Visual Web Project and NB 6.1, the following project is created:
http://10.18.39.25:8888/svn/repo/tools/ide/netbeans/6.1/jsf12/samples/jira/2667

From the logging, the following cases lifeCylce works as expected
http://localhost:8080/2667/Page1.iface

One case subject to discussion is that

Using the jsp mapping (since Page flow in design time only works with jsp page)
http://localhost:8080/2667/Page2.jsp

Go to Page3.jsp

LifeCycle in the above case need to be investigated further ...

This issue appeared to have been, at least partially, addressed in NB6.1 and ICEfaces 1.7.1.
However with NB6.5 and ICEfaces 1.7.2, it appears to have reappeared.

It looks like the prerender() method is not being called when the page is navigated to.