skuzzle / jeve Goto Github PK

SynchronousEventProviders should keep track of the nested events using a Stack. Before firing a SynchronousEvent, the user can choose to prevent cascaded events

EventProviders are not made to be used within try resources blocks. Its not even mandatory to close them (like it is for Streams and further IO classes). Extending AutoClosable also causes useless 'resource leak' warnings in some IDEs.

This should better be replaced by a Disposable interface which could be implemented by stores and providers.

This provider should dispatch events in parallel but block the calling thread until all listeners have been notified.

There are some parts where logging would make sense, like when an Exception thrown by an ExceptionCallback is swallowed

The dispatching EventProvider should be passed to the exception call back. A new default method exception(EventProvider<?> provider, Exception e, Listener source, Event<?, ?> cause) should be added to the ExceptionCallback interface, which calls the old exception method when not being overridden.

Wiki is out of date and should be updated for the 3.0 release

For extending legacy events where you can not extend the original code, the Event class should get a map to assign arbitrary properties to it

When a listener only has one listening method, it is redundant to specify this method when calling EventProvider.dispatch. Instead, a new sub class of Event could statically specify the method reference to call. THis would reduce the dispatch call to

eventProvider.dispatch(new SampleEvent(this));

Has been deprecated since 2.0.2

Stores should by default always be implemented without thread locking, to allow higher runtime performance. Instead of locking, they should provide a method which returns a synchronized view of the store which can be accessed concurrently without causing problems.

The ListenerStore interface should be split into ListenerStore and ListenerSource, where the latter contains the Stream<Listener> get() method. This is because EventProviders must not necessarily know how listeners are added or removed but only how they are retrieved.

Implement a ListenerStore which gets its listeners injected instead of requiring to add each listener manually.

This probably should be implemented as extension artifact to not pollute jeve dependencies with any DI frameworks.

Either replace with Optional or force to always specify a source

EventProviders should get a generic parameter which denotes the super type of events it is able to dispatch. This would allow compiler checked separation of event categories. E.g. a frontend EventProvider would not be able to fire a back end event and vice versa.

Current 'DefaultTargetEvent' is clumsy to use because of the extra type parameter. Instead, normal events should have a defaultDispatch method which calls a dispatch method on a passed eventprovider

DefaultTargetEvent and EventProvider.dispatch(DefaultTargetEvent) and EventProvider.dispatch(DefaultTargetEvent, ExceptionCallback) will be marked deprecated. Will be removed as of #13

The registered listeners should not be a property of the EventProvider itself. Instead, Providers should get a reference to a ListenerStore at which listeners are registered.
This would allow different EventProviders to share a ListenerStore and to customize the delivery of the listeners to the Provider.

Enhancement to #8: If an event has been prevented, the flag will be set to true.

The unregister method is not called on the removed listeners upon closing

The new ListenerSource abstraction is a great way to build a chain of responsibilty in which listeners participate in a predefined order. This is a more safe way of notifying listeners in a certain order than using a PriorityListenerStore

As a ListenerSource can be shared by multiple providers, it makes no sense closing it when a provider is closed, because this would affect the other providers too.

Add add(Listener) and remove(Listener) which automatically determine the ListenerClasses

That provider should dispatch all Events within a single dedicated thread. As only a single thread is used, this provider could also implement the new prevention mechanism.

Adding the generic type of the used listener store to the event provider was a bad design decision. The user of the provider should not care what kind of store it uses. Thus, the generic parameter should be removed entirely again.

See #10

An event might be caused by another event. Therefore events may hold a reference to their cause if any.

The skip method may register types of classes which should not be notified during the current dispatch action. For example event.skip(UserManager.class) would not notify sub classes of the UserManager