SpringDM笔记10-Listening to extender events with the whiteboard pattern
1. THE SPRING DM EVENT MECHANISM
??? The available events are Java classes in the org.springframework.osgi.context.event package and
??? they’re listed below:
??? (1)OsgiBundleContextRefreshedEvent: Published when an application context is successfully started
??? or? refreshed.
??? (2)OsgiBundleContextFailedEvent: Published when the creation of an application context fails.
??? (3)OsgiBundleContextClosedEvent: Published when an application context is closed, usually when
??? a Spring-powered bundle is stopped.
2. Spring Container Event与SpringDM Event的区别
??? (1)相同点：Spring DM’s OsgiBundleContextRefreshedEvent is raised when the refresh method of the
??? ConfigurableApplicationContext interface is called, which is the same point in the lifecycle that the
??? Spring ContextRefreshedEvent is raised.
??? (2)不同点：Spring’s standard event system propagates container events to interested beans in the
??? same application context , whereas Spring DM propagates events outside the containing??
??? application context,possibly betwwen bundles .
??? (3)Spring’s standard event mechanism:
??? The Spring lightweight container comes with a built-in event mechanism that allows beans to be
??? notified of lifecycle steps in their parent application context. Beans interested in receiving events
??? need to implement the ApplicationListener interface,? and the application context will register
??? them as listeners when it creates them. They will be notified of events such as the application
??? context starting, stopping, or closing. Spring also allows beans to raise their own events, which
??? will be propagated the same way as built-in ones. This makes it easy to use an event-driven
??? approach in Spring applications, which would normally be enough for simple use cases.
3. 注册SpringDM Event监听器
??? By declaring a bean that implements the OsgiBundleApplicationContextListener interface and then
??? publishing it as an OSGi service. Spring DM will automatically detect it and add it to the list of
??? managed listeners. The listener interface declares only one method, onOsgiApplicationEvent, with
??? the event as the only parameter.
??? An OSGi bundle application listener:
??? package com.manning.sdmia.ch04;
??? import org.springframework.osgi.context.event.OsgiBundleApplicationContextEvent;
??? import org.springframework.osgi.context.event.OsgiBundleApplicationContextListener;
??? import org.springframework.osgi.context.event.OsgiBundleContextClosedEvent;
??? import org.springframework.osgi.context.event.OsgiBundleContextRefreshedEvent;
??? public class ApplicationContextObserver implements?
??????? OsgiBundleApplicationContextListener<OsgiBundleApplicationContextEvent> {
??????? private transient int countRefreshed = 0;
??????? private transient int countClosed = 0;
??????? public void onOsgiApplicationEvent(OsgiBundleApplicationContextEvent evt) {
??????????? if(evt instanceof OsgiBundleContextRefreshedEvent) {
???????????????? countRefreshed++;
??????????? } else if(evt instanceof OsgiBundleContextClosedEvent) {
???????????????? countClosed++;
??????????? }
??????? }
??????? public? int getCountRefreshed() {
??????????? return countRefreshed;
??????? }
??????? public int getCountClosed() {
??????????? return countClosed;
??????? }
??? }
??? Declaring and exporting a listener:
??? <?xml version="1.0" encoding="UTF-8"?>
??? <beans xmlns="http://www.springframework.org/schema/beans"
??????????????? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
??????????????? xmlns:osgi="http://www.springframework.org/schema/osgi"
??????????????? xsi:schemaLocation="http://www.springframework.org/schema/beans
??????????????? http://www.springframework.org/schema/beans/spring-beans.xsd
??????????????? http://www.springframework.org/schema/osgi
??????????????? http://www.springframework.org/schema/osgi/spring-osgi.xsd">
?????????? <bean id="observer" />
?????????? <osgi:service ref="observer" interface="org.springframework.osgi.context.event.
??????????????????? OsgiBundleApplicationContextListener"/>
???? </beans>
4. THE WHITEBOARD PATTERN
??? The whiteboard pattern is more about “event-based” communication, so that’s why we don’t use
??? the exact same vocabulary as with the observer pattern: observables become event producers,
??? and observers become listeners or consumers.
??? In an OSGi environment, event-based communication between components can be implemented
??? by following the observer pattern, but the dynamic nature of OSGi becomes a real hindrance to
??? its use. The difficulty mainly consists in maintaining consistent linkages between producers and
??? consumers, because to provide modular interbundle connections, they should be OSGi services,
??? and as such, they can disappear or reappear at any moment. A producer would have to maintain
??? its own collection of listeners, usually with the use of a ServiceTracker. Even if this solution could
??? work well, it would be cumbersome and error prone.
?
??? Another solution might consist of using some kind of middle tier to decouple producers and??
??? listeners. Listeners would register with this middle tier, and producers could retrieve listeners from
??? it in a totally safe manner. The intricacies we described previously would now be handled by this
??? middle tier. Luckily for us, this middleware already exists in OSGi, in the shape of the service
??? registry!
?
??? In the whiteboard pattern, each time a producer wants to send an event to its listeners, it?
??? retrieves it from the whiteboard and proceeds with the event dispatch. The collection of listeners
??? it receives from the registry can be seen as a snapshot of the listeners that are registered at the
??? moment the event is dispatched. The producer relies on the service registry to correctly maintain
??? the collection of listeners. The usual way to retrieve listeners is to track them through their
??? interface with a ServiceTracker and use the getServices method.
?
?