Which ideals? Also, it shouldn't be terrible for someone to extend Seam Mail with another template provider and use JSF.

I think current mail support can be accepted...I used it in my projects now(Velocity as template)...But I have some questions about this.

1. Is there an example for sending Mail
asynchronously and schedule(CRON), and batch mail sending?

2. In my Seam2 application, I can use a PDF(Seam2 pdf rendering) as attachment directly, how to do this in Seam3?

I have filed the Mail template migrating issue in Seam Mail, but it is rejected. The pdf, rss, xsl, pdf have their own jsf renderkit, these are not available in Seam3.

1. Async is probably not the correct way to go about sending email as there are plenty of documented issues with regards to which scope(s) is active/available in an async thread. Think instead of creating a MailTransporter which can store the message to memory or to disk and then send at a given interval via a timer (EJB/Quartz etc). This gets you protection from the smtp server down as well as near instant send from a client perspective (no blocking of the UI). I can probably work up a blog post shortly with how I'm currently handling this in my apps.

2. JSF style PDF (Seam 2) rendering is not currently a feature of Seam 3. This all relates back to not having a way to render the JSF outside of a web request. Currently you can create a PDF in pure java via iText or other PDF libraries and attach using one of the many attach methods of mail.

Once someone decides to conquer the headless jsf issue, a Templating impl should be able to integrate easily into Seam Mail. See http://java.net/jira/browse/JAVASERVERFACES-1456 and https://issues.jboss.org/browse/SEAMFACES-12 for further info.

The easiest thing would be to look at Seam 2.3 and use what's there and port it over to EE6.

That depends on how you're going to use it. If you're going to do it outside of a JSF request, yes it's a problem. If you're doing it outside of a request, yes it's a problem because JSF was not meant to be used outside of an HTTP request. In Seam2 a very poor mock was used. Something similar could be done, but it's not really a correct way of doing it. The fact that it works, is probably simply coincidental.

A major block was needing to mock the JSF request to support rendering outside a JSF request. For example a large amount of my messages are sent from ejb timers.

Hi guys,

Mocking together with classloading was actualy the biggest problem with JSF templating, it would be a big problem if you would wan't to send mail from EJB component that has noting to do with web, there ware lots of hacks and workaround to support this scenarios...

There was some discussion with Mojarra guys to add some mojarra specific apis, that would enable to properly bootstraping of JSF framework without needing to bind it to web lifecycle.

Don't know how far has this come, as when this was disscused it was planed for Mojarra 2.1.  Pete would know more on this topic...

Given that if this is now possible to do like that, it would be easy to use JSF for templating even in seam 3...

--

tomaz

Tomaz I think you are refering to JAVASERVERFACES-1456 which appears to be stalled waiting for a community member to take it over.

Cody, yeah, that is the one... couldn't find it earlyer...

Anyhow, this would be the proper way to implement jsf templating, anything else is just hacks with workarounds

--

tomaz