committed the first cut and open for review :-) Thanks, Ruwan
On Tue, Apr 7, 2009 at 7:05 PM, Ruwan Linton <ruwan.lin...@gmail.com> wrote: > I've completed most of the implementation of the first cut... and waiting > on this fix [1] in axis2 to make it 100% accurate. :-) > > Thanks, > Ruwan > > [1] - https://issues.apache.org/jira/browse/AXIS2-4304 > > > On Mon, Apr 6, 2009 at 10:18 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: > >> I am in the process of implementing this.... >> >> I found a few issues and had to take a few decisions. >> >> Issues :- The existing approach doesn't prevent messages to be flowing >> into synapse before deploying proxies and so on, because the message >> interception handlers are attached through the module while the synapse >> initialization is handled out of the module initialization. >> >> I found it impossible to implement the listener manager initialization and >> startup to be different, even though I was planing to do so. >> >> Decisions :- Add the start and stop methods to the ManagedLifecycle >> No need of an post start method to the controller, but inside the >> controller.start, call the ManagedLifecycle.start() >> >> Will be able to commit the first cut soon. >> >> Thanks, >> Ruwan >> >> >> On Mon, Apr 6, 2009 at 9:39 AM, indika kumara <indika.k...@gmail.com>wrote: >> >>> Ruwan >>> >>> I never said that suggested approach is bad. if you have confidence >>> that approach will work , then it is good . Generally , a problem have >>> many solutions. I just say what I like. >>> You will go on your way. If it can achieve what we need , then it is a >>> good solution. >>> >>> Thanks >>> Indika >>> >>> On Sun, Apr 5, 2009 at 3:07 PM, Ruwan Linton <ruwan.lin...@gmail.com> >>> wrote: >>> > Indika, >>> > >>> > If we are going for such a change it has to go into axis2 and I think >>> it is >>> > late to get this to axis2 1.5, and I think this is much cleaner.... can >>> you >>> > point any issue with this approach? Any reasoning to not to add a start >>> > method.... >>> > >>> > Thanks, >>> > Ruwan >>> > >>> > On Sun, Apr 5, 2009 at 12:24 PM, indika kumara <indika.k...@gmail.com> >>> > wrote: >>> >> >>> >> Runwan >>> >> >>> >> I personally like, if there are some fixes need to be done on >>> >> transport layer, if it could be done. >>> >> >>> >> BTW, it is good if we can cope (by the implementation we are going to >>> >> do) transparently with current and future behaviors of transports as >>> >> synapse always operate top on that. >>> >> >>> >> Thanks >>> >> Indika >>> >> >>> >> On Sun, Apr 5, 2009 at 11:33 AM, Ruwan Linton <ruwan.lin...@gmail.com >>> > >>> >> wrote: >>> >> > Indika, >>> >> > >>> >> > I think having a start method is much cleaner than this, because >>> >> > >>> >> > listener manager doesn't support adding the transport in the >>> maintenance >>> >> > mode... >>> >> > if we try to start and then put the transport into the maintenance >>> mode >>> >> > even >>> >> > then there is a time where the transports are exposed to the >>> external >>> >> > users >>> >> > before synapse initialization >>> >> > Not all the transports support maintenance mode >>> >> > >>> >> > So I would go with the above proposed approach, which is much >>> cleaner. >>> >> > >>> >> > Thanks, >>> >> > Ruwan >>> >> > >>> >> > On Sun, Apr 5, 2009 at 10:57 AM, indika kumara < >>> indika.k...@gmail.com> >>> >> > wrote: >>> >> >> >>> >> >> Hi All >>> >> >> >>> >> >> I am not sure but could we achieve following event sequence? >>> >> >> >>> >> >> Initializing……………. >>> >> >> >>> >> >> Initialized and start transport on graceful mode >>> >> >> Create synapse configuration >>> >> >> Create synapse environment >>> >> >> Initialized synapse configuration >>> >> >> Change the mode of listeners to fully active >>> >> >> >>> >> >> Shouting down ………………. >>> >> >> >>> >> >> Signal to change the mode of transport into graceful >>> >> >> destroy synapse configuration and synapse environment >>> >> >> Signal to completely destroy transport >>> >> >> >>> >> >> Could we achieve what we need with above order sequence of events? >>> If >>> >> >> it can, I feel we never want to change any API. >>> >> >> >>> >> >> Thanks >>> >> >> Indika >>> >> >> >>> >> >> >>> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >>> >> >> For additional commands, e-mail: dev-h...@synapse.apache.org >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Ruwan Linton >>> >> > Senior Software Engineer & Product Manager; WSO2 ESB; >>> >> > http://wso2.org/esb >>> >> > WSO2 Inc.; http://wso2.org >>> >> > email: ru...@wso2.com; cell: +94 77 341 3097 >>> >> > blog: http://ruwansblog.blogspot.com >>> >> > >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >>> >> For additional commands, e-mail: dev-h...@synapse.apache.org >>> >> >>> > >>> > >>> > >>> > -- >>> > Ruwan Linton >>> > Senior Software Engineer & Product Manager; WSO2 ESB; >>> http://wso2.org/esb >>> > WSO2 Inc.; http://wso2.org >>> > email: ru...@wso2.com; cell: +94 77 341 3097 >>> > blog: http://ruwansblog.blogspot.com >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >>> For additional commands, e-mail: dev-h...@synapse.apache.org >>> >>> >> >> >> -- >> Ruwan Linton >> Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb >> WSO2 Inc.; http://wso2.org >> email: ru...@wso2.com; cell: +94 77 341 3097 >> blog: http://ruwansblog.blogspot.com >> > > > > -- > Ruwan Linton > Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
