FacesContext.getCurrentInstance() is null during application startup and this interferes with the initialization of a number of classes. This bug is present in MyFaces 2.0.0 but is verified fixed in the nightly builds, with target 2.0.1

https://issues.apache.org/jira/browse/MYFACES-2730

Incompatibility with commandLink reported to MyFaces:

https://issues.apache.org/jira/browse/MYFACES-2793

The following code change avoids passing the query String part to the MyFaces ResourceHandler. It is not immediately clear from the spec if this is a workaround, or if the MyFaces behavior should be more lenient:

+++ src/main/java/org/icefaces/push/servlet/ICEfacesResourceHandler.java (working copy)
@@ -29,6 +29,7 @@
import org.icefaces.push.http.MimeTypeMatcher;
import org.icefaces.push.http.standard.CompressingServer;

+import javax.faces.application.Resource;
import javax.faces.application.ResourceHandler;
import javax.faces.application.ResourceHandlerWrapper;
import javax.faces.context.ExternalContext;
@@ -188,4 +189,16 @@
set(null);
}
}
+
+ public Resource createResource(String resourceName) {
+ //MyFaces rejects resource names containing "?"
+ String resourcePart = resourceName;
+ if (resourceName.contains("?"))

+
+ return handler.createResource(resourcePart);
+ }
+
}

Compatibility in auction partially verified with modified MyFaces-2.0.1-SNAPSHOT.

Single bid fields are working, as is the chat user name, however chat text is not updating.

MyFaces 2.0.2-SNAPSHOT testing shows the following at the end of each form:

old DOM from initial response:

<input name="chat_SUBMIT" type="hidden" value="1" /><input id="javax.faces.ViewState" name="javax.faces.ViewState" type="hidden" value="TZj0Lp+eI9z2Y2odmFSnnRmezsB7KYDRENbqVrc6OJpi6wxKUdELGNS9Vb10A1u2zNZvMErXRQtV
hsIEaTpzZh60+kHoNs0hn7eEIbxLhW/yar5JBvQOtaMbJ1c=
" /></form>

new DOM from Ajax response:

<input name="chat_SUBMIT" type="hidden" value="1" /></form>

This is in contrast to the mojarra behavior, which does not place the javax.faces.ViewState in the page directly.

The absence of the ViewState key during Ajax responses is due to ViewHandlerImpl:

public void writeState(FacesContext context) throws IOException
{
if(context.getPartialViewContext().isAjaxRequest())
return;

The problem is more subtle, however. We make use of ViewRoot attributes for storing the old DOM. With MyFaces, when the following line from our BridgeSetup is executed:

writer.writeAttribute("value", context.getApplication().getStateManager().getViewState(context), null);

the ViewRoot attributes become frozen and cannot be modified. This results in the old DOM remaining the same from the initial request.

auction working with MyFaces 2.0 with following changes (will need to consider whether the ViewState behavior should be configurable):

— core/src/main/java/org/icefaces/event/BridgeSetup.java (revision 22076)
+++ core/src/main/java/org/icefaces/event/BridgeSetup.java (working copy)
@@ -138,22 +138,6 @@

//make sure there's always a form so that ice.singleSubmit and ice.retrieveUpdate can do their job
UIForm retrieveUpdateSetup = new UIForm() {

• public void encodeEnd(FacesContext context) throws IOException {
• ResponseWriter writer = context.getResponseWriter();
• //apply similar fix as for http://jira.icefaces.org/browse/ICE-5728
• if (context.isPostback()) { - writer.startElement("input", this); - writer.writeAttribute("id", "javax.faces.ViewState", null); - writer.writeAttribute("type", "hidden", null); - writer.writeAttribute("autocomplete", "off", null); - writer.writeAttribute("value", context.getApplication().getStateManager().getViewState(context), null); - writer.writeAttribute("name", "javax.faces.ViewState", null); - writer.endElement("input"); - }

  -

• super.encodeEnd(context);
• }
  -
  //ID is assigned uniquely by ICEpush so no need to prepend
  public String getClientId(FacesContext context) {
  return getId();
  Index: core/src/main/java/org/icefaces/application/ExternalContextConfiguration.java
  ===================================================================
  • • core/src/main/java/org/icefaces/application/ExternalContextConfiguration.java (revision 22076)
      +++ core/src/main/java/org/icefaces/application/ExternalContextConfiguration.java (working copy)
      @@ -25,6 +25,7 @@
      import org.icefaces.push.Configuration;
      import org.icefaces.push.ConfigurationException;

+import javax.faces.context.FacesContext;
import javax.faces.context.ExternalContext;

public class ExternalContextConfiguration extends Configuration {
@@ -56,7 +57,7 @@

public String getAttribute(String paramName) throws ConfigurationException {
String attributeName = postfixWith(paramName);

• String value = context.getInitParameter(attributeName);
  + String value = FacesContext.getCurrentInstance().getExternalContext().getInitParameter(attributeName);
  if (value == null) { throw new ConfigurationException("Cannot find parameter: " + attributeName); }

  else {

Several components are functional in component-showcase when ice:form is replaced with h:form.

Modified compat LoadBundle so that it could withstand Serialization. Several member variables are marked transient to avoid Serialization errors, however the component does not function correctly when de-Serialized.

In component-showcase, only the first two user events are functional. The requests from the client are identical except that in the first two requests we have:

iceform_SUBMIT=1

whereas the third request is missing a value for the MyFaces form-marker element:

iceform_SUBMIT=

If the update is small (not encompassing the entire form) this is likely being clobbered by resetHiddenFields().

Serialization problems:

• after the message is shown in Text Entry: java.io.NotSerializableException: javax.faces.application.FacesMessage$Severity
• when a new Chart is selected in Charts: java.io.NotSerializableException: sun.java2d.SunGraphics2D
• when a map city is selected: java.io.NotSerializableException: com.icesoft.faces.component.gmap.GMapLatLng
• when a tree node is selected: java.io.NotSerializableException: org.icefaces.application.showcase.view.bean.examples.component.tree.EmployeeUserObject
• when a number of columns is selected: java.io.NotSerializableException: org.icefaces.application.showcase.view.bean.examples.component.columns.ColumnsBean$CellKey
• when a positionedPanel is moved: java.io.NotSerializableException: org.icefaces.application.showcase.view.bean.examples.layoutPanel.panelPositioned.PostionedPanelPerson
• when a collapsiblePanel is selected: Caused by: java.lang.NullPointerException: value is null for a not available property: iceform:linkPanel
• dynamic tabset: java.io.NotSerializableException: org.icefaces.application.showcase.view.bean.examples.layoutPanel.panelTabset.DynamicTabSetBean$Tab

Drag and drop does not record drop.

Effects function but cause re-ordering of effects panels.

progressBar does not work.

commandSortHeader works but sometimes sends the header to the bottom of the page.

row Selection renders strangely when rows are selected.

static tabset renders strangely after first click.

Exception in Download Resources:

java.lang.NullPointerException
org.apache.myfaces.context.servlet.ServletExternalContextImplBase.getResourceAsStream(ServletExternalContextImplBase.java:128)
org.icefaces.application.showcase.view.bean.examples.component.outputResource.MyResource.open(OutputResourceBean.java:118)
com.icesoft.faces.component.outputresource.RegisteredResource.open(OutputResource.java:460)
com.icesoft.faces.context.ResourceRegistryLocator$DynamicResourceDispatcherAdapter$DynamicResourceAdapter.open(ResourceRegistryLocator.java:116)
org.icefaces.push.DynamicResourceDispatcher$ResourceServer.respond(DynamicResourceDispatcher.java:227)

Making EmployeeUserObject Serializable does not appear straightforward – this is tied to Serializable for IceUserObject.

PostionedPanelPerson implements Serializable resolves one Exception.
DynamicTabSetBean implements Serializable resolves another Exception, however Tab rendering problems remain.
ColumnsBean CellKey together with transient/lazy init resolves another Exception.

Extra javax.faces.ViewState being added to forms is now conditioned on mojarra being present. MyFaces may require a similar hack, however.

It may be possible to configure MyFaces to perform less Object Serialization:

http://myfaces.apache.org/core20/myfaces-impl/webconfig.html

Set of .jar files used with MyFaces component-showcase:

commons-beanutils.jar commons-digester.jar myfaces-api-2.0.2-SNAPSHOT.jar
commons-codec-1.4.jar commons-discovery-0.4.jar myfaces-impl-2.0.2-SNAPSHOT.jar
commons-collections.jar commons-logging.jar

Replace ice:form with h:form in

./compat/samples/component-showcase/web/WEB-INF/includes/content/languageThemeControl.xhtml
./compat/samples/component-showcase/web/WEB-INF/includes/content/navigation.xhtml
./compat/samples/component-showcase/web/WEB-INF/includes/templates/page-template.xhtml

Static and Dynamic tabset now appear to be working, so may be fixed due to other changes in compat. Effects panels still re-order when clicked.
progressBar is not functional, however, this may be due to the lack of a ViewState hack for MyFaces.

Created fine-grained JIRAS.

FacesMessage.Severity is not Serializable; not yet clear how to hack around this:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1766

Removed blocking link to ICE-5969 since ICE-5969 is a general investigation and does not need to be performed before MyFaces compatibility is considered "resolved".

Checked in Serializable versions of auction beans. Push is now working in auction, but interaction fails. JavaScript console shows "myfaces is not defined" so it appears that we require a JavaScript inclusion that is not being activated.

A build parameter has been added, however latest testing against the ICEfaces 2.0 trunk shows several problems.

Better behavior is observed with revision 22517 from October 5.

Cleared cache and verified again with the trunk. The problem is actually that initial clicks on the page fail.

After replacing ice:form with h:form in navigation.xhtml /page-template.xhtml myfaces-impl-2.0.3-20101115.160833-53.jar was verified with ICEfaces trunk. In component-showcase, progressBar does not function and modal popup does not function, but otherwise compatibility seems good.

Tested with MyFaces 2.0.3. auction does not function correctly, but basic appears fine.

I have been working on getting Icefaces and MyFaces to work together lately. The first problem I found I reported as https://issues.apache.org/jira/browse/MYFACES-3132, whose fix is available in MyFaces snapshots. Having gotten past that, I have submitted ICE-6864.

Update: Running with my suggested patch to ICE-6864, I next encountered the problem that IceFaces placed some messages in view scope, triggering the MyFaces bug whereby FacesMessages could not be properly serialized. I filed this issue as https://issues.apache.org/jira/browse/MYFACES-3141, which has been fixed in the MyFaces trunk and should be available in 2.1.0-SNAPSHOT builds by tomorrow.

Thanks for advocating that fix to MyFaces. For ICE-6864 I believe we should determine why the DOM is null and potentially not attempt to render into the DOM during state saving rendering.

Adding this case to be followed up once general MyFaces compatibility is achieved.

Checked in some changes that allow Myfaces to be used against our sample applications. Have been concentrating on the compat Component Showcase to begin with. The main issue was related to inserting the hidden ViewState field into the various forms on the page.

With Mojarra, the strategy was to insert a marker into the form (_{com.sun.faces.saveStateFieldMarker}) which gets replaced later when the response is written out. The reasons for this are related to calling:

String viewState = facesContext.getApplication().getStateManager().getViewState(facesContext);

Each call to this method re-calculates the value of the ViewState which results in performance overhead and different ViewState values for each call (at least during the initial rendering of the page for the first GET request). By putting the marker in, it allows getViewState() to be called only once at the end with the marker being filtered out and replaced by the actual ViewState value when the response is written out. There is more on this in the original case ICE-4555.

Since MyFaces doesn't use this approach, we need to provide a different way of ensuring that the compat FormRenderer class (responsible for including the ViewState when rendering the ice:form markup) was also writing out the ViewState into the forms. For now, we've implemented logic that calls getViewState() for each form. Since may suffer from the same inefficiencies as Mojarra, it will at least allow us to run against MyFaces. Initial testing shows that the approach may not be as problematic as it would be with Mojarra but it should still be reviewed for optimization.

When deltaSubmit is on, the compat Component Showcase does not quite work as intended. Clicking navigation links require 2 clicks to bring up the intended content. I've opened and linked ICE-7017 for this issue.

Based on the strategy to get and insert the ViewState as we've done, the updates that come back now include a separate ViewState update for each form on the page. So for compat Component Showcase, this results in a number of separate ViewState updates. To illustrate, here's a response captured via Firebug showing only the ViewState updates for a single response:

<partial-response>
<changes>
<update id="javax.faces.ViewState"><input id="javax.faces.ViewState" name="javax.faces.ViewState" type="hidden" value="r59gFt2h/81l/nwJBgaDQwGMGQ1fWBCXUXHE3EuPbJf4oMgdno4J18HLtgxdJowej7y1bdKr1R/7 jMViVutGYMNg0pNsYqOWPU5x5Cyn7jGsZc4nZ4+IvQda9Chu7QJCEYrLfQ== " /></update>
<update id="javax.faces.ViewState"><input id="javax.faces.ViewState" name="javax.faces.ViewState" type="hidden" value="r59gFt2h/81l/nwJBgaDQwGMGQ1fWBCXUXHE3EuPbJf4oMgdno4J18HLtgxdJowej7y1bdKr1R/7 jMViVutGYMNg0pNsYqOWPU5x5Cyn7jGsZc4nZ4+IvQda9Chu7QJCEYrLfQ== " /></update>
<update id="javax.faces.ViewState">r59gFt2h/81l/nwJBgaDQwGMGQ1fWBCXUXHE3EuPbJf4oMgdno4J18HLtgxdJowej7y1bdKr1R/7 jMViVutGYMNg0pNsYqOWPU5x5Cyn7jGsZc4nZ4+IvQda9Chu7QJCEYrLfQ== </update>
</changes>
</partial-response>

While this is functional, it's another area to look at optimizing.

I've gone through the individual component examples in the Component Showcase and have the following observations:

Calendar - the pull downs (Month, Year) on the popup calendar revert to original values

Charts - clicking on the image map values generates an NPE
Caused by: java.lang.NullPointerException
at com.icesoft.faces.component.outputchart.OutputChart.getGeneratedImageMapArea(OutputChart.java:414)
at com.icesoft.faces.component.outputchart.OutputChart.decode(OutputChart.java:359)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1204)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1198)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1198)
at javax.faces.component.UIForm.processDecodes(UIForm.java:114)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1198)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1198)
at javax.faces.component.UIViewRoot._processDecodesDefault(UIViewRoot.java:1320)
...

Download Resources - changing file name and tabbing out generates an NPE
Caused by: java.lang.NullPointerException
at com.icesoft.util.CoreComponentUtils.findComponent(CoreComponentUtils.java:72)
at com.icesoft.faces.application.PartialSubmitPhaseListener.afterPhase(PartialSubmitPhaseListener.java:55)
at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
...

GMap - goes nuts and starts looping some kind of request

Menu Bar, Dynamic Menu Bar - Menu Item is not serializable (stored in MenuBarBean which is ViewScoped)

SEVERE: Exiting serializeView - Could not serialize state: com.icesoft.faces.component.menubar.MenuItem
java.io.NotSerializableException: com.icesoft.faces.component.menubar.MenuItem
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.ArrayList.writeObject(ArrayList.java:570)
at sun.reflect.GeneratedMethodAccessor4529.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)

Progress Bar - appears to run and do the push requests but does not display/update the actual progress bar (captured in ICE-5967); interacting with it afterwards leads to:

Caused by: java.lang.NullPointerException
at com.icesoft.util.CoreComponentUtils.findComponent(CoreComponentUtils.java:72)
at com.icesoft.faces.application.PartialSubmitPhaseListener.afterPhase(PartialSubmitPhaseListener.java:55)
at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
... 18 more

Rich Text - resources (including ckeditor.js) are not loading during initial page get which prevents proper operation

Data Exporter - clicking to download the resource leads to:

5-Jul-2011 11:06:18 AM org.apache.myfaces.renderkit.ServerSideStateCacheImpl serializeView
SEVERE: Exiting serializeView - Could not serialize state: com.icesoft.faces.context.FileResource
java.io.NotSerializableException: com.icesoft.faces.context.FileResource
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.HashMap.writeObject(HashMap.java:1001)

There are a few other "not serializable" issues that occur but I haven't pinned down yet. At least some occur when we call getViewState() in order to write it into our forms:

4-Jul-2011 4:54:58 PM org.apache.myfaces.renderkit.ServerSideStateCacheImpl serializeView
SEVERE: Exiting serializeView - Could not serialize state: org.apache.myfaces.context.servlet.ServletExternalContextImpl
java.io.NotSerializableException: org.apache.myfaces.context.servlet.ServletExternalContextImpl

Calendar issues was fixed as per ICE-7020.

MenuBar and DynamicMenuBar issues fixed by altering the Compat Component Showcase so that the MenuBarBean holds lazy and transient references to the internal MenuItems. MyFaces, by default, likes to serialize views to the session and since components are usually serializable, I made the reference transient and the moved the creation of the MenuItems array from the bean constructor to the getter.

Added the addtional null check as per ICE-6864.

Fixed the Download Resource issue by adjusting the OutputResourceBean$MyResource class of the application. The error I originally reported was misleading. There was a problem with MyFaces wanting to serialize the view to the session and the MyResource class was storing a reference to the ExternalContext.

This problem was manifesting the last issue I documented:

4-Jul-2011 4:54:58 PM org.apache.myfaces.renderkit.ServerSideStateCacheImpl serializeView
SEVERE: Exiting serializeView - Could not serialize state: org.apache.myfaces.context.servlet.ServletExternalContextImpl
java.io.NotSerializableException: org.apache.myfaces.context.servlet.ServletExternalContextImpl

Which has now gone away with this fix.

Fixed the Data Exporter issue by making FileResource implement Serializable. It was difficult to find where exactly the DataExporter was adding the FileResource reference into the view but making FileResource serializable works and should be safe as the only thing it stores is a File reference (which is also Serializable).

Opened ICE-7097 to cover the issues with Chart and Progress Bar components which are related to the timing and strategy used for state saving.

Added ICE-7099 to address the problem with GMap where selecting a city from the drop down menu causes a recursive form submission when running with MyFaces.

Also explored the problem with the Rich Input Text component. Turns out that the problem only occurs if you clear the cookies and try and reload the page. Opened ICE-7100 to capture it. The problem is not confined to MyFaces so is not linked to this case.

In running the scopes test, the view-scoped beans were not behaving properly with MyFaces. Turns out that the problem is due to a subtle interaction between inheritance and serialization.

The test contains a view-scoped bean declared as:

public class ViewScopedCounter extends Counter implements Serializable

the Counter superclass did not originally implement Serializable

public class Counter

It turns out that:

"When the super class is not serialized, when deserializing the instance of the sub class, the constructor of the super is called."

Because of this, the counter would always be set back to it's original value. By implementing Serializable on the superclass, the view-scoped beans work the same as they do in Mojarra.

public class Counter implements Serializable

Linking in ace:ajax listener issue.

The integration of MyFaces with the core framework and our sample applications is pretty much complete. From here on, individual issues that are MyFaces specific can be captured in their own distinct JIRAs.