stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nirmal Fernando (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (STRATOS-110) Topology Event Message Processors should follow 'chain of responsibility' design pattern
Date Fri, 18 Oct 2013 13:19:42 GMT

    [ https://issues.apache.org/jira/browse/STRATOS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799082#comment-13799082
] 

Nirmal Fernando commented on STRATOS-110:
-----------------------------------------

Fixed in commits:
a7645cd4e60ff8e555fde141fdacf43a39fffc0c
779fa8312434d64813c012270c269c899c9da0d6
ea592fd39f62f822086c3dfeb1ea5eda6add29e8
f2960914f2d3e513ca831d6d8574ae72db8ea7ab
5f9e5a1fb8c48ac291dc9d9e565dd7d5081f6864
6c6cc07a6c727fe3a9f7a3760cac209e54865fb8
06755880ca12a4f9d8c07150209049fe734c729e

> Topology Event Message Processors should follow 'chain of responsibility' design pattern
> ----------------------------------------------------------------------------------------
>
>                 Key: STRATOS-110
>                 URL: https://issues.apache.org/jira/browse/STRATOS-110
>             Project: Stratos
>          Issue Type: Improvement
>    Affects Versions: 4.0.0 M1
>            Reporter: Nirmal Fernando
>            Assignee: Nirmal Fernando
>            Priority: Critical
>             Fix For: 4.0.0 M1
>
>
> Following is the MessageProcessor interface with this change.
> package org.apache.stratos.messaging.message.processor;
> import org.apache.stratos.messaging.domain.topology.Topology;
> /**
>  * Message processor interface. Every Message Processor should implement this.
>  */
> public interface MessageProcessor {
>    
>     /**
>      * Link a message processor and its successor, if there's any.
>      * @param nextProcessor
>      */
>     public abstract void setNext(MessageProcessor nextProcessor);
>     /**
>      * Message processing and delegating logic.
>      * @param type type of the message.
>      * @param message real message body.
>      * @param topology Topology that will get updated.
>      * @return whether the processing was successful or not.
>      */
>     public abstract boolean process(String type, String message, Topology topology);
> }
> I've implemented initial Message Processors:
> ├── ClusterCreatedEventProcessor.java
> ├── ClusterRemovedEventProcessor.java
> ├── CompleteTopologyEventProcessor.java
> ├── MemberActivatedEventProcessor.java
> ├── MemberStartedEventProcessor.java
> ├── MemberSuspendedEventProcessor.java
> ├── MemberTerminatedEventProcessor.java
> ├── ServiceCreatedEventProcessor.java
> └── ServiceRemovedEventProcessor.java
> Now, it is up to the Message Processor Delegator to build the Message processor chain.
>         // instantiate all the relevant processors
>         ServiceCreatedEventProcessor processor1 = new ServiceCreatedEventProcessor();
>         ServiceRemovedEventProcessor processor2 = new ServiceRemovedEventProcessor();
>         ClusterCreatedEventProcessor processor3 = new ClusterCreatedEventProcessor();
>       
>        
>         // link all the relevant processors in the required order
>         processor1.setNext(processor2);
>         processor2.setNext(processor3);
>         processor3.setNext(processor4);
> and also it's a duty of the deligator to start the flow:
> boolean hasProcessed = processor1.process(type, json, TopologyManager.getTopology());
> After the flow started, Processor who is capable of handling the message would eventually
receive it and will process the message and other Processors will simply delegate the message
to its successor.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message