|
From: Ivan R. <iv...@we...> - 2003-09-12 11:49:01
|
Rod Johnson wrote:
> Yes I think this could be useful. I could envisage uses for it.
I will study Spring coding and design standards and
come back with more details.
> I don't quite understand the "integration with the context" you propose.
> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its
> setBeanFactory() method give it access to whatever other beans it needs and
> also kick off its timer/whatever?
>
> Of course it could be configured by its JavaBean properties.
Yes. But there is also a case where you want to schedule events
from your code. There are three ways to achieve this:
1) Explicit configuration, create a scheduler and then give
its reference to every bean that needs it.
2) Have the scheduler as a shared object; other beans have to
be ApplicationContext aware, and use a call to sharedObject()
to retrieve the scheduler reference.
3) Add getScheduler() method to ApplicationContext. I actually
don't like this approach. I only mentioned it because it is
a possibility.
From my point of view, 1 and 2 are acceptable options. The third
option would lead to a fat app. context, and I don't see real
benefit there.
Maybe Spring should define certain names (with or without
a namespace) to be reserved for certain services, e.g.
"service.scheduler". People will certainly do this
themselves, perhaps if we do it on a framework level we
can have greater "portability".
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
|