Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
On Thu, Mar 19, 2009 at 2:45 PM, Asankha C. Perera wrote: > Hi Charith > >> OK,I'll change the patch by introducing a BUILD_ENVELOPE property to send >> mediator.and attatch to this jira issue >> >> Asankha can you please raise a new issue in jira mentioning the new >> changes that you have purposed.Since IMO attaching fixes to them in this >> jira issue is not a good idea(for the users who will need a track in the >> future). >> > Sure, SYNAPSE-522 > > BTW, you can first fix the SYNAPSE-357 using a standard property, and then > address the new JIRA which would only involve generic changes to support any > property > sure i'll attend to that issue too. > thank you, Charith > > cheers > asankha > > -- > Asankha C. Perera > AdroitLogic, http://adroitlogic.org > > http://esbmagic.blogspot.com > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Hi Charith OK,I'll change the patch by introducing a BUILD_ENVELOPE property to send mediator.and attatch to this jira issue Asankha can you please raise a new issue in jira mentioning the new changes that you have purposed.Since IMO attaching fixes to them in this jira issue is not a good idea(for the users who will need a track in the future). Sure, SYNAPSE-522 BTW, you can first fix the SYNAPSE-357 using a standard property, and then address the new JIRA which would only involve generic changes to support any property cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
OK,I'll change the patch by introducing a BUILD_ENVELOPE property to send mediator.and attatch to this jira issue Asankha can you please raise a new issue in jira mentioning the new changes that you have purposed.Since IMO attaching fixes to them in this jira issue is not a good idea(for the users who will need a track in the future). thank you, Charith On Thu, Mar 19, 2009 at 12:36 PM, Asankha C. Perera wrote: > Hi Eric > > > > <... other such properties.../> > > > > > +1 > > I thought exactly the same while reading the original mail. The short name > with "env" could be quite confusing for new users which are not the deeply > involved into the technical details. There is often an association Env --> > Environment. > I also think that the property approach fits well, especially if more > properties will follow. > > > Yep, glad I was able to think like a user :-) ! > > OR/AND > > > > > <... other such properties.../> > > > > > I'm not that sure about this one due to missing use cases in mind. Asankha, > could you give some examples? I wouldn't like this as an replacement of the > above option (OR), but would also not be against it as an alternative (AND). > > > I think this should be an AND too.. just threw the options possible > earlier.. > > Here is something I know will need to be changed, > [optimize="mtom|swa"].> > > I think the format attribute was a bad choice too.. for example to support > PUT, DELETE, OPTIONS etc we may have an issue. Also, I think with other > transports, there would be some valid use cases. Maybe a password that > should be used when talking to that endpoint etc, or the identifier name > from the identity keystore to be used for 2-way SSL.. I'm just thinking out > loud.. > > cheers > asankha > > -- > Asankha C. Perera > AdroitLogic, http://adroitlogic.org > http://esbmagic.blogspot.com > > > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Hi Eric <... other such properties.../> +1 I thought exactly the same while reading the original mail. The short name with "env" could be quite confusing for new users which are not the deeply involved into the technical details. There is often an association Env --> Environment. I also think that the property approach fits well, especially if more properties will follow. Yep, glad I was able to think like a user :-) ! OR/AND <... other such properties.../> I'm not that sure about this one due to missing use cases in mind. Asankha, could you give some examples? I wouldn't like this as an replacement of the above option (OR), but would also not be against it as an alternative (AND). I think this should be an AND too.. just threw the options possible earlier.. Here is something I know will need to be changed, [optimize="mtom|swa"].> I think the format attribute was a bad choice too.. for example to support PUT, DELETE, OPTIONS etc we may have an issue. Also, I think with other transports, there would be some valid use cases. Maybe a password that should be used when talking to that endpoint etc, or the identifier name from the identity keystore to be used for 2-way SSL.. I'm just thinking out loud.. cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com
RE: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Hi, > Do we need configuration changes for this? We can set these properties > using property mediator and then introduces some layer (before sending > message) that do work based on these special properties- special > property handlers. I'm not sure whether the generic approach will always be the best. Increasing the number of properties set in the message context increases also the complexity. Aren't properties in the message context only important if we need them at several different places within the message flow (e.g. at one point in the flow they are set and at totally different location they are read?). I'm not quite sure about this as I'm still in the process to familiarize with Synapse. In our case now, we are talking about properties which apply exactly for one mediator, or? So why using a generic approach, if a direct configuration of a specific mediator would be straight and easy to understand? > Then, we can avoid any configuration changes. Hmm. This point I don't get. Do you mean avoid any change of a specific mediator factory? Or do you refer to the compatibility of existing configurations? I think the latter would not be a problem as we are talking about the addition of an optional property. > be an abstraction that does decoration around sending. I didn’t look > at possibility of doing this. But, I feel it is doable and it > introduce some extensibility. Even for Hessian case, we may able to > use a special property handler. I know you are quite busy, but if have the time could you please detail you thoughts about a possible usage of this concept for the Hessian protocol. The "problem" with the Hessian case is, that a decision has to be done at runtime. Most likely not only Hessian messages may pass a specific sequence, but at least the http transport has to behave differently. So this is quite hard to handle via a static configuration option. Anyway users are always happy for any configuration line to save. Regards, Eric
RE: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
> My suggestions are: > > > <... other such properties.../> > > +1 I thought exactly the same while reading the original mail. The short name with "env" could be quite confusing for new users which are not the deeply involved into the technical details. There is often an association Env --> Environment. I also think that the property approach fits well, especially if more properties will follow. > OR/AND > > > > > <... other such properties.../> > > I'm not that sure about this one due to missing use cases in mind. Asankha, could you give some examples? I wouldn't like this as an replacement of the above option (OR), but would also not be against it as an alternative (AND). Regards, Eric
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Hi Charith Do we need configuration changes for this? We can set these properties using property mediator and then introduces some layer (before sending message) that do work based on these special properties- special property handlers. Then, we can avoid any configuration changes. May be an abstraction that does decoration around sending. I didn’t look at possibility of doing this. But, I feel it is doable and it introduce some extensibility. Even for Hessian case, we may able to use a special property handler. I just throw an idea...I cannot validate Thanks Indika On Thu, Mar 19, 2009 at 11:16 AM, Charith Wickramarachchi wrote: > Hi Asanka, > > I like your Idea of having a property other than an attribute.which i think > is a extendible one.So I would like to do that change. > I'll wait till others give there ideas about this matter. > > thank you, > Charith > > > > On Thu, Mar 19, 2009 at 11:04 AM, Asankha C. Perera > wrote: >> >> Hi Charith >> >> The attribute "buildEnv" may not convey the meaning to someone new.. Also, >> we may have many more such options and thus we should not make this a core >> extension to the languages' mediator. Can we do this, support the >> specifications of one or more such properties within the send mediator - >> I've wanted to do that for quite some time, and things like FORCE_HTTP_1.0, >> POST_TO_PATH etc, could also more naturally be specified there. This could >> even be at the level.. I want to know what others think too.. >> >> My suggestions are: >> >> >> <... other such properties.../> >> >> >> >> OR/AND >> >> >> >> >> <... other such properties.../> >> >> >> >> cheers >> asankha >> >> -- >> Asankha C. Perera >> AdroitLogic, http://adroitlogic.org >> >> http://esbmagic.blogspot.com >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> > > > > -- > Charith Dhanushka Wickramarachchi > http://charithwiki.blogspot.com/ > > - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Hi Asanka, I like your Idea of having a property other than an attribute.which i think is a extendible one.So I would like to do that change. I'll wait till others give there ideas about this matter. thank you, Charith On Thu, Mar 19, 2009 at 11:04 AM, Asankha C. Perera wrote: > Hi Charith > > The attribute "buildEnv" may not convey the meaning to someone new.. Also, > we may have many more such options and thus we should not make this a core > extension to the languages' mediator. Can we do this, support the > specifications of one or more such properties within the send mediator - > I've wanted to do that for quite some time, and things like FORCE_HTTP_1.0, > POST_TO_PATH etc, could also more naturally be specified there. This could > even be at the level.. I want to know what others think too.. > > My suggestions are: > > > <... other such properties.../> > > > > OR/AND > > > > > <... other such properties.../> > > > > cheers > asankha > > -- > Asankha C. Perera > AdroitLogic, http://adroitlogic.org > > http://esbmagic.blogspot.com > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Hi Charith The attribute "buildEnv" may not convey the meaning to someone new.. Also, we may have many more such options and thus we should not make this a core extension to the languages' mediator. Can we do this, support the specifications of one or more such properties within the send mediator - I've wanted to do that for quite some time, and things like FORCE_HTTP_1.0, POST_TO_PATH etc, could also more naturally be specified there. This could even be at the level.. I want to know what others think too.. My suggestions are: <... other such properties.../> OR/AND <... other such properties.../> cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
