FolksThe synapse-dev team have a request for Axis2. We would like an interface SOAPMessageContext that is a subset of the MessageContext model. The subset we would like is just the getters/setters for the envelope, message addressing properties and the property bag. We would also like the MessageCo
respond to axis-dev@ws.apache.org
To:axis-dev@ws.apache.org
cc:
Subject:[Axis2] SOAPMessageContext
Folks
The synapse-dev team have a request for Axis2. We would like an interface
SOAPMessageContext that is a subset of the MessageContext model. The subset
we would like is just the getters
one other option is to have the interface separate and wrap the message context
with a adapter.
I neutral (in apache votes 0 :) ) on making our message context implement this
Thanks
Srinath
On 11/11/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Folks
>
> The synapse-dev team have a request for
Whoa ... what we agreed was that SOAPMessageContext would be a strict
subset of the MessageContext in Axis2. The idea is to let Synapse rule
engine and mediator programmers only have to look at stuff actually
related to the message.
As such I don't think its an option to tweak it in any inconsiste
45:58
>
>Please respond to axis-dev@ws.apache.org
>
>To:axis-dev@ws.apache.org
>cc:
>Subject:[Axis2] SOAPMessageContext
>
>
>Folks
>
>The synapse-dev team have a request for Axis2. We would like an interface
>SOAPMessageContext that is a subset of the
n 11/11/2005 10:45:58>>Please respond to axis-dev@ws.apache.org
>>To:axis-dev@ws.apache.org>cc:>Subject:[Axis2] SOAPMessageContext>>>Folks>>The synapse-dev team have a request for Axis2. We would like an interface
>SOAPMessageContext that is a subset of the Mess
Paul Fremantle wrote:
>Ok folks
>
>1) I will remove processingFault and inFaultFlow.
>2) I think we can remove MessageInformationHeaders from the interface
>3) I'm not sure I agree that the isResponse is never useful in a pure Axis2
>context. Is it not an aspect of a pure SOAP message which dire
Hi all,
I see that folks have different views on putting this particular
SOAPMessageContext, most probably as part of Axis2 itself would be
slightly inappropriate since Axis2 can survive nicely without it :).
Here's my plan to make both worlds happy. Instead of just
creating message contexts insi
AjithWe are doing this for efficiency. We don't want to have to copy from an AxisMC into a SynapseMC. And I don't agree that this is not a useful *general* concept. It is nothing special to Synapse. It is simply a view of the MC that doesn't expose the internals of the programming model. In fact, t
On Fri, 2005-11-11 at 20:11 +0600, Sanjiva Weerawarana wrote:
> Whoa ... what we agreed was that SOAPMessageContext would be a strict
> subset of the MessageContext in Axis2. The idea is to let Synapse rule
> engine and mediator programmers only have to look at stuff actually
> related to the messa
EranIf I am in Synapse I am looking at a message on the wire. And I have to decide which way it is going. So in general I have a complex calculation to make:1. Look at the transport (i.e. is it an HTTP response)
2. See if it has a relatesTo header3. Look at the To: header (maybe it is anon)etc.If
On Fri, 2005-11-11 at 07:40 -0800, Ajith Ranabahu wrote:
> Hi all,
> I see that folks have different views on putting this particular
> SOAPMessageContext, most probably as part of Axis2 itself would be
> slightly inappropriate since Axis2 can survive nicely without it :).
> Here's my plan to mak
Another BuilderExtensions theory ?
;-)
Ajith Ranabahu wrote:
Hi all,
I see that folks have different views on putting this particular
SOAPMessageContext, most probably as part of Axis2 itself would be slightly
inappropriate since Axis2 can survive nicely without it :).
Here's my plan to m
Sanjiva +1 to your points. I agree with all of these.PaulOn 11/11/05, Sanjiva Weerawarana <[EMAIL PROTECTED]
> wrote:On Fri, 2005-11-11 at 07:40 -0800, Ajith Ranabahu wrote:> Hi all,
> I see that folks have different views on putting this particular> SOAPMessageContext, most probably as part of Axi
[mailto:[EMAIL PROTECTED]
Sent: Friday, November 11, 2005
9:46 AM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2]
SOAPMessageContext
Ajith
We are doing this for efficiency. We don't want to have to copy from an AxisMC
into a SynapseMC. And I don't agree that this is not a usefu
Hi Paul,
> If I am in Synapse I am looking at a message on the wire. And I have
> to decide which way it is going. So in general I have a complex
> calculation to make:
>
> 1. Look at the transport (i.e. is it an HTTP response)
> 2. See if it has a relatesTo header
> 3. Look at the To: header (m
Ok, I don't want to look like the mad scientist who comes up with the
craziest theory always but I humbly think I'm talking about the same
issue of allowing the SOAPMsgCtx to co-exist without corrupting (or
rather effecting) the Axis2 system. However I also feel that I lack
knowledge of some discus
Oh, now I understand. What I meant was not a copying mechanism.
The factory registered for the Axis system (in this case it happens to
be the synaspse context factory) will be directly providing the right
context. No copying!
This is exactly the thing done in DOM - Change the factory and the used
AjithIf I want to use Axis2MC as the implementation, then the Axis2 MC has to be marked as an implementation of the interface SOAPMC. Otherwise I can't cast it. So we have to move the interface SOAPMC into Axis2. The alternative is to have a dependency from Axis2 onto a Synapse interface. Or a wrap
e
this as reinventing Axis2 or wasteful inefficient doubling up of method
calls,looks more like standard OO design to me.
...ant
Ajith Ranabahu <[EMAIL PROTECTED]> on 13/11/2005 05:51:59
Please respond to axis-dev@ws.apache.org
To:axis-dev@ws.apache.org
cc:
Subject:Re: [Axi
On Sun, 2005-11-13 at 09:55 +, Anthony Elder wrote:
> Ajith, I don't think you're deeply mislead, it seems there's quite a lot of
> us who can't understand what's wrong with having a Synapse specific message
> which delegates some calls to an Axis2 MessageContext.
>
> interface SynapseMessage
On Sun, 2005-11-13 at 11:51 +0600, Ajith Ranabahu wrote:
> Ok, I don't want to look like the mad scientist who comes up with the
> craziest theory always but I humbly think I'm talking about the same
> issue of allowing the SOAPMsgCtx to co-exist without corrupting (or
> rather effecting) the Axis2
So I think the approach will work, but we are introducing a performance overhead straight away. I know its just a method call. I would like to try the approach proposed, and if it breaks lets fix it. Of course if the Axis2 community -1s it then we can say its broken.
I personally still think that t
+1 to separating the programming model from the implementation model.
AnneOn 11/13/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
So I think the approach will work, but we are introducing a performance overhead straight away. I know its just a method call. I
would like to try the approach proposed,
Hi all,
Sorry If I sounded rude. Now I understand the exact problem you guys are trying to solve.
Hmmm.. In this case (where MsgCtxt seems to have too many items and
extending it would not be recommended) I'll sadly have to agree that
the factory approach would not be the solution.
So are we going
On Sun, 2005-11-13 at 08:06 -0500, Anne Thomas Manes wrote:
> +1 to separating the programming model from the implementation model.
+1 in principle but let's remember the different levels of PMs we have:
- handler/module author: clearly needs the full MC as they need to know
the whole story of wh
.
I am wondering why this is so
controversial?
--
Tom Jordahl
Macromedia Server Development
From: Paul Fremantle
[mailto:[EMAIL PROTECTED]
Sent: Sunday, November 13, 2005
7:49 AM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2]
SOAPMessageContext
So I think the approach
On Wed, 2005-11-16 at 11:22 -0500, Tom Jordahl wrote:
> +1 to creating the SOAPMessageContext interface for Synapse.
...
> I am wondering why this is so controversial?
Its not on the Axis2 side .. the synapse side isn't agreed on whether to
do this or whether to embed Axis2's MC inside a "SynapseM
28 matches
Mail list logo
