The difficulty withe Seam Mail is that it is often initiated in a bean action, typically attempting to re-use the current FacesContext for email rendering. The current FacesContext has been configured for HTML Ajax rendering, so a conflict results.

A workaround may be possible with a combination of just-ice.jar (so that the ICEFaces renderers are not invoked) and the instantiation of a new FacesContext specifically for the rendering of the email.

I recently created a class to fix this for myself and shared it on the forums - http://www.icefaces.org/JForum/posts/list/8058.page#33826.

I don't know enough about your stack to fix it myself (without breaking something else) but it might be useful.

This example application is based on the seam-mail example from the seam distribution. It has been modified to use jsf-delegation with ICEfaces, but retains the names jboss-seam-mail.jar, war and ear. It will only work with changes made to Seam-2.1.0 post-A1 and trunk dated May 22nd or later. Tested with current trunk of ICEfaces(1.7.1 pre-release), but should also work well with 1.7.0 release.

The use of mail through servlets was not done with this example. Drop it into the /examples folder as the build script requires the use of the examples build script, etc.

See readme.txt in zipped application folder for further info. You will have to set an icefaces.home property in the build script of this sample application.

Have attached the sample application to show how to use jsf-delegation with seam-mail example.

I've attached my workaround for this issue in Seam 2.0

For example that uses jsf-delegation that I have attached, this no longer requires the IceFacesMailProcessor class that was used in Greg's example for Seam-2.0. Just take any reference out of MailExample for this class and it works with any Seam-2.1.x version (I just tested it with Seam-2.1.1.GA). The last 2 methods of the MailExample class in the attached project are remnants from Seam2.0. Since fixes from the 2.1 trunk have been applied to 2.0.2 onwards, I would imagine that this jsf delegation example would also work with the latest releases from the seam 2.0 branch. Hopefully some users will test it out and let us know.

The solution for this bug is confusing for people who don't know its history. Clearly there have been multiple solutions over the years, but its not clear what the correct solution is today. There is information in multiple locations, some of it conflicting. Some locations: 3 pages of replies at http://www.icefaces.org/JForum/posts/list/8058.page, 2 pages of replies at http://www.icefaces.org/JForum/posts/list/11054.page, the comments in this bug, and others.

I'm using the latest production release of all relevant libraries (Seam 2.1.1.GA, IceFaces 1.8.1, Facelets, JSF 1.2.x, etc.)

The following code only works when mail.xhtml has no JSF/IceFaces tags:

Renderer.instance().render("/mail.xhtml"); // synchronous send

Works:

<m:message xmlns="http://www.w3.org/1999/xhtml"
xmlns:m="http://jboss.com/products/seam/mail">
<m:from name="foo" address="foo@google.com" />
<m:to>foo@google.com</m:to>
<m:subject>hello world</m:subject>
<m:body>hello world</m:body>
</m:message>

Does not work (only difference is the use of h:outputText):

<m:message xmlns="http://www.w3.org/1999/xhtml"
xmlns:m="http://jboss.com/products/seam/mail"
xmlns:h="http://java.sun.com/jsf/html">
<m:from name="foo" address="foo@google.com" />
<m:to>foo@google.com</m:to>
<m:subject><h:outputText value="hello world"/></m:subject>
<m:body>hello world</m:body>
</m:message>

An IllegalStateException is thrown from com.icesoft.faces.context.DOMResponseWriter.(DOMResponseWriter.java:126) with the message "ICEfaces requires the PersistentFacesServlet. Please check your web.xml servlet mappings"

1. Should I be using just-ice.jar or icefaces.jar?
2. IsAsynchronousIceFacesMailProcessor.java still relevant? What if I want to send mail synchronously?
3. Judy, could you please definitively explain how to fix this for the latest version of Seam and IceFaces? A lot of focus has been devoted to solving this problem for people still using the legacy Seam 2.0.x codebase, leaving people like me, who keep Seam up-to-date, out in the cold.

Thank you,
Eric

p.s. i get the same error whether i use synchronous or asynchronous sending.