0

I'm trying to implement a service that asynchronously performs polling via a thread and then notifies a list of observers.

The architecture is as follows: multiple concurrent jsf session beans can register to the singleton service and be notified by the thread in case of new data updates available. When notified, each jsf session bean performs some actions, by accessing to other session-scoped spring beans (which are services defined in the context.xml).

The problem I'm facing now is that the update thread cannot access those session-scoped spring beans, because their proxy cannot be resolved from the update thread, which is understandable since the thread is instantiated outside the application context and has no visibility on the available beans. But then, how can I implement such a mechanism in Spring?

I also tried using a task executor bean, hoping for Spring to make it somehow part of the current context, but it failed (the session-scoped spring beans called by the notified jsf session beans cannot be resolved).

Any help would be much appreciated. Thank you.

EDIT: Added some more information about the communication flow.

Everytime a new user generates a new session, a corresponding jsf session bean is created. This bean (once it is bound to the http session) is then registered to a spring service (a singleton). This service will activate the polling mechanism when at least one jsf session bean is registered (therefore when there's at least one observer). When the service finds out a new update is available, it will notify the registered observers, by calling their "update()" method. Inside this method each observer (or jsf session bean) will perform some actions via some other spring session beans, which are available as proxies. This is the point where "communication" fails, because the original polling thread (the one in the update service) doesn't know how to resolve the spring proxies. Is there a way to make this information available to the polling thread? Thanks.

1 Answers1

0

How about using an object that is known the both the JSF and Spring session bean as the observer? You would need to poll that object on each request. But in that case you might as well just poll the original source.

sourcedelica
  • 23,940
  • 7
  • 66
  • 74
  • Thanks for your reply. I didn't completely get what you said. I've edited the above question with more details about the communication flow in my web-app, so maybe you can have a look at it and let me know. Thanks! – Antonio de Donato Jun 27 '11 at 14:09