I have similar problem. In portal environment standard command components rendered by IceFaces (e.g. h:commandLink, h:CommandButton) generate portlet ResourceRequest's and ResourceResponse's (AJAX request/response). But sometimes there is a need to have ActionRequest, ActionResponse objects, for example when portlet mode or portlet window state must be changed. Standard components rendered by default JSF HTML render kit generate such request/response (non AJAX). The possibility of disabling IceFaces rendering for whole page (<icecore:config render="false"/> ) is not good enaugh, because when ActionRequest/ActionResponse is needed there must not be any IceFaces component on the page - if components are present "ICEfaces rendering required" exception is thrown.

In my opinion standard JSF component rendering (e.g. h:commandLink) should be delegated to standard JSF HTML renderer and IceFaces components (e.g. ice:commandLink) should be rendered by IceFaces DOM renderer kit. Developer decides what behaviour is expected.

Rashmi, have you found any solution or workaround for problem you have described?

Pawal,

Your issue is different from the one the JIRA is for. icecore:config render="#

" /> may be used in some inclusion cases described above.

If distinct portlets are inheriting the property from each other, a test case is required.

Please create a new JIRA for your specific issue.

Pawel,

I have not found a wrokaround. We ended up buying IcefacesEE for 1.8. But still many issues we faced persist

Ted,Ken,Deryk,
Pawel n me are facing similar issue. Even i require a actionrequest/response to perform IPC as per JSR286. But icefaces decorates JSF lifecycle, depriving us of ActionRequest/Response, we always receive ResourceRequest/Response.

Rashmi, if you are have and ICEfaces EE 1.8 support subscription, please contact product support with this issue.

Ken,

Yes we have approached Icefaces EE 1.8 support.

But the topic of this issue is with Icefaces 2.0. We bought 1.8 as a temporary solution till we can get 2.0 working.
If you could help us with a solution here it would be very beneficial.

From what we can tell from the descriptions, there are two different issues here:

#1) As I understand of the original JIRA description, there is a desire to have ICEfaces rendering be configurable for only some parts of a View and not others. This isn't necessarily a portlet issue. Any page that had includes as described would have the same behaviour. However, because the icecore:config tag is scoped to the entirety of the current view, it's not currently possible to have the rendering constrained to only some parts of the component tree. The work to be able to support this as a new feature would be fairly substantial. We can open a separate JIRA for this as a new feature but can't promise when it might be considered for inclusion for a future release.

#2) With two separate ICEfaces portlets on a page (and therefore 2 separate Views), it should theoretically be possible to have separate icecore:config settings so that one portlet can be set to false and one true without them overriding each other. The tag information is stored as an attribute of the View. We'll take a look to ensure that there isn't a bug here and try and fix it for the next release. This is more of a portlet-specific problem in that 2 separate and distinct views are on a single page at the same time and therefore each can support their own value for ICEfaces rendering.

I tested the second part as mentioned by Deryk in the previous comment.

Using the ICEfaces 2.0.2 release I added a PhaseListener which prints the blockUIOnSubmit value for the current context:

public void afterPhase(final PhaseEvent event) {
if (event.getPhaseId() == PhaseId.RENDER_RESPONSE)

}

public void beforePhase(final PhaseEvent event) {
}

public PhaseId getPhaseId()

Then I took two portlets and changed its contents by adding the icecore config as well as a config tag containing the blockUIOnSubmit attribute with two different values:

<ice:panelGroup styleClass="componentBox"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ice="http://www.icesoft.com/icefaces/component"
xmlns:icecore="http://www.icefaces.org/icefaces/core">

<icecore:config blockUIOnSubmit="true" />

Using Liferay 6.0.6 I created a portal page containing these two portlets. Interacting with either portlet shows the expected values.

Using ICEfaces 3 I confirmed again that two separate portlets on a portal page can have their own icecore:config configuration. Marking this one as FIXED.