ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

The constructor for HtmlResponseWriter changed in... I forget which version. Obviously, the one you are running. You just need to drop the final argument off the constructor call.

i.e. facesContext.setResponseWriter(new HtmlResponseWriter(writer, "text/html", RIConstants.CHAR_ENCODING));

I just double-checked the Seam source and there is indeed a import org.jboss.seam.ui.util.JSF and it contains the method stated. It is in the jboss-seam-ui.jar rather than the main jboss-seam.jar.

For the other refrences you need to add the following jar to your classpath:
jsf-impl.jar

It is in the Seam lib directory.

Ah. I'd forgotten about that. The posted version has the imports for Seam 2.0.0. You need to change the import for 2.0.2 from

import org.jboss.seam.util.JSF;
to
import org.jboss.seam.ui.util.JSF;

It's working fine in 2.0.2SP1 for me, as posted. What error are you getting?

The key thing in the wrap method is that it resets the responseWriter from a DOMResponseWriter, which would try to do the cast you are mentioning, to a basic HTMLResponseWriter which does not do this cast.

As for the email not sending, I would check whatever email logs you have available to see if it got sent. Most such errors in my testing came from the email getting stuck in someones spam filter. Perhaps look at using Meldware to handle the delivery.

Newlukai wrote:

I just had a debug session. Using ICEfaces, the renderers for <h:> tags are replaced by renderers provided by ICEfaces. Those renderers make use of DOMResponseWriter which expects a BridgeFacesContext as parameter. This parameter is somewhere in the call stack taken from FacesContext.getCurrentInstance(). But since the UIMessage calls MailFacesContextImpl.start() which replaces FacesContext's instance by itself and makes your MockBridgeFacesContext to a member, the cast to (BridgeFacesContext) can't be done in DOMResponseWriter.

I'm puzzled why you get this error. The issue you describe is exactly what this workaround is working around. Are you sure that the you have the latest code? have you debugged into the workaround code? In the context.wrap at the start of the emailSend method it sets the responseWriter to an HtmlResponseWriter. If you step through it with the debugger, is this happening? It can't be or you would not see the error you describe...

Hmmm...

How are you calling the emailSend method? Can you post the relevant code? Also, what is the extra mapping for?
Code:

   	<servlet-mapping>
   		<servlet-name>Persistent Faces Servlet</servlet-name>
   		<url-pattern>/inc/mail_developerAndValidator.xhtml</url-pattern>
   	</servlet-mapping>

Did you download the latest version (about halfway down this page)? One of the earlier versions had a bug like you are describing...

I've attached my workaround for this issuein the JIRA

I finally got some time to investigate this issue, sorry for the slow response.

It looks like there is some issue with Seam and Quartz involved. The code works fine for me with the default scheduler but not with Quartz. I found mention of a similar Quartz issue on the Seam forums
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116377&postdays=0&postorder=asc&start=0

Anyway, I worked out a solution for this also and have attached it. This has been tested in Seam2.0.2SP1 and JBoss 4.2.2

I haven't had much time to look at this due to a tight deadline at work. I did some quick tests but couldn't duplicate the error. I would think something like this would fix it though:

In the wrap method right before the MockBridgeFacesContext is created, try setting the application factory.

The code would look like this:

if (PersistentFacesState.getInstance() != null) {
...
}
else {
try {
FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY));
} catch (IllegalStateException ex) {
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
}

BridgeFacesContext bfc = new MockBridgeFacesContext(viewId); bfc.setCurrentInstance();
}

Let me know if that works for you. If it does I will add it to the code. If not I will try to get some time to investigate it this week.

I'm not sure if I would call this an IceFaces bug or a Seam bug, but it's a crash, so I thought I'd inform someone.

If you use a commandLink with <f:param name="conversationPropagation".../> and a commandButton in the same form, then clicking the button will crash.

The problem is that IceFaces FormRenderer adds a hidden field for the conversationPropagation field in the form with no value. The link sets the value in it's onclick, but the button has no idea the field is there so it submits it with no value (actually "" when it gets to the backend). When Seam processes this it tries to figure out the conversation propagation from this value and throws an exception. This happens in ConversationPropagation.java line 159.

The easy workaround is to use Seam's s:link instead of the commandLink. This works fine, so it's pretty low priority.

I actually saw that exception the first time I tested this, but it disappeared the next time I deployed and I haven't seen it since. If you can reproduce it let me know and post some details and I'll see if I can figure it out.

Whoops!

My aplogies to anyone who downloaded the code over the last couple of days. I just realized that I posted an old version. Sorry, my bad. I was working on a released branch of my own project rather than the trunk and didn't think about that when I uploaded the file.

The version I uploaded previously was my first attempt, which did get Seam mail working and you could do basic EL expressions but faces tags would not work due to an instanceof check in the IceFaces renderer. i.e. you could do Dear #{person.firstname} but not Dear <h:outputText value="#{person.firstname}"/>

Anyway, the version attached here fixes that. You still can't do Icefaces tags but basic faces tags should work fine, at least the ones I've tested.

Again, sorry for the confusion.

I decided to log an issue over at java.net against the facelets library.

https://facelets.dev.java.net/issues/show_bug.cgi?id=310