I guess the HTTP(S) restriction is there for the case where Synapse is used as an HTTP proxy. I don't see how we would get a similar behavior with any other transport, so this actually looks right (but should be better documented in the code).
Andreas On Thu, Apr 2, 2009 at 07:59, Ruwan Linton <ruwan.lin...@gmail.com> wrote: > Yes, I fixed the handler module.... but what I am referring is the normal > synapse behavior, not the handler module. > > For the message mediation case I think we shouldn't restrict the transports. > > Thanks, > Ruwan > > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <indika.k...@gmail.com> wrote: >> >> Hi Runwan >> >> HTTP and HTTPS for synapse message mediation (_SynapseService) >> setting was there in the previous code (Proxy service only had the per >> service transports ) . I actually only did refractor - cut and paste >> and change only organization. Synapse as Handler module can be >> deployed without much effort... may three , four line ........ >> >> Thanks >> Indika >> >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ruwan.lin...@gmail.com> >> wrote: >> > I went through the new synapse startup logic and it seems OK but this >> > makes >> > the following concrete changes to the synapse architecture >> > >> > Synapse can no longer be deployed just as a pure module in axis2, it >> > requires much more work. >> > The message mediation is restricted to HTTP and HTTPS, which I am not >> > sure >> > whether we want to keep it as it is. >> > >> > But still this new logic even doesn't address the original problem in >> > the >> > discussion. In the new logic transport listeners starts even before the >> > mediators getting loaded into synapse. >> > >> > I think we need to improve this, and to me Eric's point is completely a >> > valid point. I will further look into resolving this and will keep the >> > list >> > posted. >> > >> > Thanks, >> > Ruwan >> > >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva <supu...@gmail.com> >> > wrote: >> >> >> >> Hi Indika, >> >> >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <indika.k...@gmail.com> >> >> wrote: >> >>> >> >>> If the synapse is run top on axis2 or any other, it should be properly >> >>> initialized and started before initialize synapse. >> >> >> >> >> >> We are talking about two things here. Initialization and startup. I >> >> agree >> >> synapse should inilialize after axis2. Also Synapse should start after >> >> Axis2. But at the moment it seems that Synapse is starting even before >> >> it >> >> initializes. The way Synapse is written it is perfectly normal to >> >> assume >> >> that it is started when Axis2 is started. But if we do it in the >> >> current >> >> way, this assumption is broken and can lead to failures as Eric said. >> >> If >> >> Axis2 is initialize properly we can initialize Synapse. As Eric said if >> >> both >> >> are successfully initialized we can start Axis2 transports, which >> >> automatically starts Synapse. >> >> >> >> Thanks, >> >> Supun. >> >> >> >> >> >>> >> >>> It is a well known >> >>> semantic that system should be in consistent state before use it. You >> >>> can refer [1] and it says why I did. >> >> >> >> >> >> >> >> >> >>> >> >>> The way message get in to synapse and mediation engine (main behavior) >> >>> are two different aspects and definitely should have two different >> >>> decision designs as it is wrong if main behavior depend on other >> >>> behavior. The starting, shutdown --- simply state (consistent) >> >>> management of mediation should not depend any thing. Axis2 Hander is >> >>> make way to get message into in to synapse and for good design, >> >>> mediation engine should separate from this design decision. Managing >> >>> mediation engine should be independent from axis2 or any other. >> >>> >> >>> If it is needed to avoid effect of started listeners if the synapse >> >>> mediation engine started up is failed, then only applicable >> >>> transaction semantic is compensation transaction. In order to enforce >> >>> that, it is needed to properly shutdown listeners, etc --- some how >> >>> need to move into a consistent state before system startup. >> >>> >> >>> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html >> >>> >> >>> Thanks >> >>> Indika >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> >>> For additional commands, e-mail: dev-h...@synapse.apache.org >> >>> >> >> >> >> >> >> >> >> -- >> >> Software Engineer, WSO2 Inc >> >> http://wso2.org >> >> supunk.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 >> > >> >> --------------------------------------------------------------------- >> 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
