Ticket #290 (closed Enhancement: fixed)
Server-side event extension facility
Reported by: | jri | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | Release 4.1 |
Component: | DeepaMehta Standard Distribution | Version: | 4.0.11 |
Keywords: | Cc: | dgf, Malte | |
Complexity: | 5 | Area: | Application Framework / API |
Module: | deepamehta-core |
Description
Plugins should be able to define its own events (along with the corresponding listener interfaces).
This would enable the following example scenario (not subject of this ticket): once the Files plugin receives an uploaded file (see #289) it would do nothing but fire a FILE_UPLOAD event. This event is defined and fired by the Files plugin. Once fired, the File Repository plugin (#291) would hop in and store the incoming file in the file repository. Thus, the file upload is decoupled from the file processing.
Change History
comment:2 Changed 12 years ago by jri
This remains to be discussed.
After talking to dgf the current implementation plan diverges from the original description: Core events are not supposed to be extendable. They are opaque to the plugin developer. Instead, general OSGi events could be utilized for plugin specific events.
comment:3 Changed 12 years ago by jri
- Status changed from accepted to closed
- Resolution set to wontfix
comment:4 Changed 11 years ago by jri
- Status changed from closed to reopened
- Resolution wontfix deleted
The topic is opened again through a possible "USER_LOGIN" event fired by the Access Control plugin. See #538.
At the low-level I'm still not sure weather to extend DM (Core) events or to utilize OSGi events. Important is a proper abstraction to provide the DM plugin developer with a unified API for both, event firing and event consumption.
comment:6 Changed 11 years ago by Jörg Richter
Core: extendable server-side events (#290).
A plugin can introduce custom server-side events (and the corresponding listener interfaces).
Other plugins can implement listeners for these events.
Core API:
there is a new base class for all Events: de.deepamehta.core.service.DeepaMehtaEvent.
Introducing a custom event:
package my.cool.plugin; import my.cool.plugin.event.MyEventListener; import de.deepamehta.core.service.DeepaMehtaEvent; import de.deepamehta.core.service.Listener; class MyCoolPlugin extends PluginActivator { static DeepaMehtaEvent MY_EVENT = new DeepaMehtaEvent(MyEventListener.class) { @Override public void deliver(Listener listener, Object... params) { ((MyEventListener) listener).myEventHandler( (MyParamType1) params[0], (MyParamType2) params[1], ... ); } }; }
Specify the listener interface:
package my.cool.plugin.event; import de.deepamehta.core.service.Listener; public interface MyEventListener extends Listener { void myEventHandler(MyParamType1 param1, MyParamType2 param2, ...); }
Listening to custom events is analogous to core events:
package another.plugin; import my.cool.plugin.event.MyEventListener class AnotherPlugin extends PluginActivator implements MyEventListener { @Override public void myEventHandler(MyParamType1 param1, MyParamType2 param2, ...) { ... } }
See #290.
comment:7 Changed 11 years ago by Jörg Richter
comment:8 Changed 11 years ago by Jörg Richter
Access Control: LOGIN and LOGOUT events (#538).
The Access Control module fires custom events once a user logs in or out.
Your plugin can listen to these events analogous to core events:
import de.deepamehta.plugins.accesscontrol.event.PostLoginUserListener; import de.deepamehta.plugins.accesscontrol.event.PostLogoutUserListener; public class TimePlugin extends PluginActivator implements PostLoginUserListener, PostLogoutUserListener { @Override public void postLoginUser(String username) { ... } @Override public void postLogoutUser(String username) { ... } }
Don't forget to put Access Control in your plugin's dependencies (pom.xml):
<dependency> <groupId>de.deepamehta</groupId> <artifactId>deepamehta-accesscontrol</artifactId> <version>4.2-SNAPSHOT</version> </dependency>