• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic