• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to access JSF Application Scoped Bean from a Scheduled Job?

 
Devon Hillard
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am coming from a Seam 2 and ATG background, and working on re-writing an old Seam 2 application using JSF 2 on Tomcat 8. I've run into a snag:

I have an application scoped managed bean, let's call it EMail. It holds a collection of Email objects, and does some other stuff.

I have an IMAPClient, which is currently setup as an application scoped managed bean (mostly to simply configuration, etc...).

I need to call a method on the IMAPClient to go check email every X seconds (let's call it 60 seconds), and add any new email into the Email managed bean's collection of email. In Seam 2 this was easy with the @Asynchronous annotation. In JSF 2 I can't figure out how to do it. I've tried using Quartz, which will happily run my IMAPCheckJob every 60 seconds, but I am so far unable to figure out how the IMAPCheckJob can get access to either the IMAPClient or the EMail beans.. There's no dependency injection into the Quartz Job, and since it's not executing in a HTTP request flow, there's no Faces context available.

It seems like there has to be some way to allow for scheduling and still have access to the benefits of the Application scoped managed bean DI system...

Or do I need to give up and move to JBoss with EJBs and CDI instead of JSF beans?

Would appreciate any guidance! Thanks!

Devon
 
Devon Hillard
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Update - just read that JSF managed bean stuff is all deprecated now? Sounds like CDI is the way of the future, so I guess I start over with Wildfly and CDI + EJB Timers... Unless I'm missing something?
 
Tim Holloway
Bartender
Posts: 18412
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have not jumped on board the CDI bandwagon myself. CDI clashes with some of my Spring stuff. Which is annoying, since Spring was well and popularly established when CDI was designed and it would have made more sense to make the 2 compatible. So I still have ManagedBean and ManagedProperty annotations.

In fact, Spring is better suited for stuff like what you're describing than CDI appears to be, because Spring's Bean factories can supply (and inject) singleton global-scope objects of general types (not just JEE-specific) into JSF Managed Properties. The Spring global scope is similar to application scope but is even wider, even though such as scope doesn't officially exist in J2EE or JEE. And I very definitely use it for things like email services. For one thing, Spring's JSF-like IoC wiring mechanism means that I can easily swap out the live mailer with a simulated testing mailer for unit-testing.

One of the problems with using application-scope objects is that not only is application scope not available outside of the HTTP processing context, but that the objects can be added or removed from Application scope at unpredictable times. So for cases like that, something less mutable may be better. You could simply make the necessary items be static properties within the batch-processed thread objects, but that also limits their accessibility. If you want to make them more accessible you need a friendly access mechanism that can locate and/or inject such objects. Spring handles that quite well.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!