Berin Loritsch wrote:
The Input/Output/Manipulator interfaces need to be really simple, that encourage processing one Transaction at a time, and handling one Response at a time. There is also the question of whether we want another component called the Notifier. The Notifier's responsibilities would be to handle the Responses and send notifications if there are errors. Anyway, here is the first cut at interfaces:
interface Input { void setDestination( Output out ); }
interface Output { Response processTransaction( Transaction trans ); }
interface Manipulator extends Input, Output {}
Honestly, I think tha (Input).setDestination(Output) is very confusing, especially for users, and semantically incorrect.
I am planning for each Job to have it's own dedicated Container, and its own dedicated Thread. For that reason each Input, Output, and Manipulator will be completely isolated from the corresponding components in other Jobs. That will help with the Manipulators having two methods that need to be called in a particular order as opposed to just one. The Job pipeline will have to be built backwards because when a pure Input has its destination set, it will start sending Transactions down the Pipeline:
manip2.setDestination( out ); manip1.setDestination( manip2 ); in.setDestination( manip 1 );
Here the sfromentioned problem shows.
If we have a Notifier component it would look like this:
interface Notifier { void handleResponse( Response resp ); }
There is already a Notifier Component in Cocoon.
It was intended to notify in a generic way, and do (Notifier).notify(Notifying).
In this way You don't even have to give a response, it could be anything.
I think that most of it can be reused in this context, and the result used both here and in Cocoon.
Internally it would determine if the response is worthy of notifying someone else, and if so would perform the steps required such as paging someone, sending an email, etc.
Separating out the Notifier would allow us to dynamically set up how we respond to bad transactions, etc.
Yes, this is good.
Thoughts? Input?
Morphos is a project to do what a "Manipulator" does. It already works with XSLT and POI HSSF.
We had a long discussion on commons-dev over the interfaces. Here is the result:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/morphos/src/java/org/apache/commons/morphos/
public interface Morpher { /**
* Construct a "call method" rule with the specified method name.
*
* @param input The associated Digester
*/
void setInput(Object input) throws ObjectFlavorException;
void setOutput(Object output) throws ObjectFlavorException;
/**
* Execute the morph.
* Usually it's needed to have setInput(Object input)
* and setOutput(Object output)
* called before.
*/
void morph() throws MorphException;/* TDB
void addNotificationListener(NotificationListener nl);
void removeNotificationListener(NotificationListener nl);
void clearNotificationListeners();
*/
} public interface MorpherPipeline extends Morpher { /**
* Construct a "call method" rule with the specified method name.
*
* @exception MorphException? FIXME if the nextMorpher
* cannot be added
*
*/
void addStage(Morpher nextMorpher);
}If we make the two compatible, InfoMover will be able to use all of Morphos' components, and extend on simple pipelines (Manipulators) for a complete infomover system.
Eventually we can make Morphos, Infomover and Cocoon share the same components.
Comments?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
