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