rju
commented
3 days ago author André van Hoorn -- Thu, 24 Nov 2011 14:34:03 +0100
I agree, that we should think about tweaking this concept in a later step --- e.g. adding, as alternatives, your proposed solution or the support of using Java annotations (as detailed below).
In general I think that our current implementation supports these extensions in later steps.
Replying to
KIEKER-1047
Done
:
> Better would be an automatic delegation of each incoming call on a port to a method like:
> void newEvent(IInputPort inPort, Object event)
> This method would be enforced by the AbstractAnalysisPlugin and a concrete default implementation of the AbstractInputPort could provide the delegation.
This would result in a switch/case block or if-then-else cascade in the newEvent method, right?
Could be implemented by special input ports (e.g.) created by a factory in the super class. These input ports transparently redirect the incoming event to the common handler function of the plugin.
> A remaining problem is, when to tell the OutputPort where to deliver its messages. You must not let this escape during the construction of the Plugin.
I don't see the problem here. The plugin (implementation) knows best when to deliver records to the right output port(s).
> Another approach might be the move of the construction of ports into the Abstract Super class (in registerInputPort). Thus this class is simply called several times with the names (or whatever) of the wanted ports and then correctly creates them.
Some time ago, we thought about using Java annotations for this purpose. These would be used to mark and configure input ports, e.g.:
InputPort(name="myInputPort", types={MonitoringRecord.class})
public void newEvent(Object event) {
}
In a later step, we might support this as an alternative way of declaring input ports. What do you think?
JIRA Issue: KIEKER-1047 Delegation of InputPort to AnalysisPlugin Original Reporter: Jan Waller
In the current implementation, each AnalysisPlugin has one or more InputPorts. These Ports are triggered on incoming data.
The result of this implementation method is: Each Plugin does nothing by itself, instead in contains one or more anonymous classes, doing all its work.
This is (in my opinion) bad style.
1. Anonymous classes are harder to read and understand.
2. They weaken private visibility (for each access the compiler generates a new access$XXXX() method, making a private member visible)
3. The Plugin should (conceptually) implement its own work.
Better would be an automatic delegation of each incoming call on a port to a method like:
void newEvent(IInputPort inPort, Object event)
This method would be enforced by the AbstractAnalysisPlugin and a concrete default implementation of the AbstractInputPort could provide the delegation.
A remaining problem is, when to tell the OutputPort where to deliver its messages. You must not let this escape during the construction of the Plugin.
Another approach might be the move of the construction of ports into the Abstract Super class (in registerInputPort). Thus this class is simply called several times with the names (or whatever) of the wanted ports and then correctly creates them.