Dmitriy,
=20
I've seen that you've added an ApplicationEventPublisher interface plus =
SimpleApplicationEventPublisher implementation, used as base class for =
EventPublicationInterceptor. I'm not sure if those really add value: =
EventPublicationInterceptor *derives* from =
SimpleApplicationEventPublisher, so it doesn't leverage the pluggability =
offered by the ApplicationEventPublisher interface.
=20
If we want to factor out event publishing from the ApplicationContext =
interface, I suggest to add an ApplicationEventPublisher interface to =
the org.springframework.context package, extended by the =
ApplicationContext interface. We've used the same strategy for the =
MessageSource and ResourceLoader interfaces. (Have a look at the =
interfaces that ApplicationContext extends.)
=20
We could then add an ApplicationEventPublisherAware interface, which =
beans can implement to automatically receive a reference to an =
ApplicationEventPublisher (usually the containing ApplicationContext). =
EventPublicationInterceptor can then simply implement that interface, =
rather than ApplicationContextAware, allowing it to be used with any =
ApplicationEventPublisher.
=20
For a comparison, have a look at the =
ReloadableResourceBundleMessageSource's implementation: It implements =
ResourceLoaderAware to automatically receive a containing =
ApplicationContext as ResourceLoader. Additionally, it has a =
DefaultResourceLoader as default, to allow for usage outside an =
ApplicationContext too. You could also pass in a custom ResourceLoader =
implementation.
=20
What do you think? If my suggested redesign fits your needs, I'm happy =
to apply it before the 1.1.1 release.
=20
Juergen
=20
|
