1 of 1 people found this helpful
Try firing a CDI event from from your EJB timer, and listening to that in a WAR class that publishes the push notification. A nice separation of concerns.
Yeah, that would be great. I've already split the code into a session scoped manager and a "delay element", a stateless session bean that houses the @Timeout method. So triggering a "wakeup" event the SFSB manager bean can respond to sounds perfect.
But I have another question that I can't wrap my head around: the timer information includes the user principal name that caused the timer start. I want to deliver the event only to the manager attached to a session for this user. If there isn't one, I want the @Timeout method or a fallback event handler to persist the event information until the bean becomes available. The SFSB will have an appropiate @PostConstruct method to read past notifications and push them to the client. I haven't found a way to make this work with Seam Events, do you have an idea to do this with CDI?
Matti Bickel wrote:
I want the @Timeout method or a fallback event handler to persist the event information until the bean becomes available.
Sounds like you pulled that requirement out of the JMS spec to me... Setting up JMS isn't *that* bad - at least it's one time task.
Yeah, I realized the requirement sounded exactly like a durable topic or maybe even a queue. My opposition is mainly based on not wanting such a big system with it's own terminology and concepts for this task. But yeah, I'll bite the bullet.