You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Asankha C. Perera" <as...@apache.org> on 2009/03/19 06:34:50 UTC
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' <send> 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 <endpoint> level.. I want to
know what others think too..
My suggestions are:
<send>
<property name="BUILD_ENVELOPE" value="true"/>
<... other such properties.../>
<endpoint ...../>
</send>
OR/AND
<send>
<endpoint ....>
<property name="BUILD_ENVELOPE" value="true"/>
<... other such properties.../>
</endpoint>
</send>
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
RE: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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
Posted by indika kumara <in...@gmail.com>.
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
<ch...@gmail.com> 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 <as...@apache.org>
> 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' <send> 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 <endpoint> level.. I want to know what others think too..
>>
>> My suggestions are:
>> <send>
>> <property name="BUILD_ENVELOPE" value="true"/>
>> <... other such properties.../>
>> <endpoint ...../>
>> </send>
>>
>> OR/AND
>>
>> <send>
>> <endpoint ....>
>> <property name="BUILD_ENVELOPE" value="true"/>
>> <... other such properties.../>
>> </endpoint>
>> </send>
>>
>> cheers
>> asankha
>>
>> --
>> Asankha C. Perera
>> AdroitLogic, http://adroitlogic.org
>>
>> http://esbmagic.blogspot.com
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether
to build the envelope before sending or not
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <as...@apache.org>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' <send> 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 <endpoint> level.. I want to know what others think too..
>
> My suggestions are:
> <send>
> <property name="BUILD_ENVELOPE" value="true"/>
> <... other such properties.../>
> <endpoint ...../>
> </send>
>
> OR/AND
>
> <send>
> <endpoint ....>
> <property name="BUILD_ENVELOPE" value="true"/>
> <... other such properties.../>
> </endpoint>
> </send>
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Thu, Mar 19, 2009 at 2:45 PM, Asankha C. Perera <as...@apache.org>
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-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@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
Posted by "Asankha C. Perera" <as...@apache.org>.
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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: SYNAPSE-357 Provide a switch to send mediator to specify whether
to build the envelope before sending or not
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <as...@apache.org>wrote:
> Hi Eric
>
> <send>
> <property name="BUILD_ENVELOPE" value="true"/>
> <... other such properties.../>
> <endpoint ...../>
> </send>
>
>
> +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
>
> <send>
> <endpoint ....>
> <property name="BUILD_ENVELOPE" value="true"/>
> <... other such properties.../>
> </endpoint>
> </send>
>
>
> 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,
> <address uri="endpoint address" [format="soap11|soap12|pox|get"]
> [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
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Eric
>> <send>
>> <property name="BUILD_ENVELOPE" value="true"/>
>> <... other such properties.../>
>> <endpoint ...../>
>> </send>
>>
> +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
>>
>> <send>
>> <endpoint ....>
>> <property name="BUILD_ENVELOPE" value="true"/>
>> <... other such properties.../>
>> </endpoint>
>> </send>
>>
>
> 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,
<address uri="endpoint address" [format="soap11|soap12|pox|get"]
[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
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> My suggestions are:
> <send>
> <property name="BUILD_ENVELOPE" value="true"/>
> <... other such properties.../>
> <endpoint ...../>
> </send>
+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
>
> <send>
> <endpoint ....>
> <property name="BUILD_ENVELOPE" value="true"/>
> <... other such properties.../>
> </endpoint>
> </send>
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