Seam Mail (sending) and Message-Driven Beans?

[aschneid75]

I've looked through the forums, documentation, and even the Seam eBook rough cut, but have not really found the answer to my question.

I've got an MDB that builds and sends an email based on the message it receives. I would like to leverage the Seam mail functionality and use Facelet templates for these emails. I can retrieve the addresses to send the emails to, and they are named objects used in other portions of the application with Seam. My problem is, obviously, by default an MDB is not participating in a Seam context. Is there a way to get the MDB into a context so that my retrieved mail address objects can be used by the renderer to render the Facelet template and send the email?

I saw this post:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=103226

but it really does not answer my question.

Thanks for any help,
Andrew

[pmuir]

With JBoss AS 4.0.5, you won't get any bijection or lifecycle stuff automatically in an MDB (except for JMS ones) - you have to it manually with Lifecycle.beginCall() and then Component.getInstance. This is a bug in EJB3.

It should be fixed in 4.2.0.CR1 though I haven't confirmed this, so I suggest trying 4.2

[aschneid75]

Thanks...so I guess my question would be, as long as I define my variables in the MDB with an @Out annotation, then in the onMessage method do the Lifecycle calls, the renderer should be able to use the objects I create in my MDB to render the facelet and send the email?

I don't really need any components from Seam in my MDB, just want to make sure the objects created in the MDB are available for the email.

Thanks.

[pmuir]

No, bijection won't work on MDBs in 4.0.5 - really the best answer is to use 4.2.0.CR1 I think. Or use Contexts.getEventContext().set(...,...);

[gavin.king]

The workaround for 4.0.5 is to have the MDB call a Seam stateless session bean, and do the work in the SLSB.

[aschneid75]

The workaround for 4.0.5 is to have the MDB call a Seam stateless session bean, and do the work in the SLSB.

Thanks Gavin,

That would probably be a little cleaner than the above solution. I actually was able to get it to work using the Lifecycle.beginCall/endCall and using the contexts.

We are still determining if 4.2 is a viable option at this point, so I will probably leave the code as is until that decision is made. Otherwise, I will probably implement as a SLSB.