Is it an acceptible design to implement multilisteners as interfaces?

I have some design problems. In the tool which I work with we have a listener,

public interface SnmpTrapListener {
    boolean processMessage(SnmpMessage message);
}

which basically listen to a socket and when it get notified it processes an SNMP message. This is something which lies deep in the library and the end users does never see this. However, since SNMP normally only processes only events important to the end users, they might want to take certain actions when notified (eg. log the error, start some tests, ...). Due to this it should be possible to define a custom EventListener (local class, not from java.util) to listen to the listener.

Right now it is done in a concrete class implementing SnmpTrapListener, but since this code is being rewritten the plan is to make this more general (to not get stuck with the same listener for all eternity). So I plan to add a method SnmpTrapListener.addEventListener(EventListener e) to the interface.

The risk I see with this implementation is to force implementation of an addListener method without an object to attach it to. This does feel risky. Also, the need to be able to switch Implementation of the SnmpTrapListener is only hypotetical and to make things future proof. So therein lies my question. Is this a reasonable design or will this make the implementation more shaky? Should I implement my multi-listener as an abstract class or concrete class instead? An abstract class cannot be instanciated, so this would still be fairly future proof.