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 the SMC concept has value in the world of Axis2, and I think we've never done enough in Axis1 or 2 to separate out the customer's programming model from the implementation model. That's what the SMC is doing as I see it.
Paul
On 11/13/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
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 system. However I also feel that I lack
> knowledge of some discussions which were in the mailing lists (Silly
> me) so I won't push the msgCtxtFactory theory anymore.
Ajith, the problem with the context factory approach is that Synapse
requires something that'll allow Axis2 to continue to work. We can of
course introduce a factory, but in order for whatever that's produces to
enable Axis2 to work, it needs to extend the current Axis2 message
context (right?).
That's precisely the problem: there's too much stuff in there for
Synapse users to care/worry about.
> BTW is this SOAPMC needed to be implemented as part of Axis2 ? The
> original mail seems to imply that the SOAP specific methods were
> specifically for Synapse, in which case the particular 'Ctxt' needs to
> be part of Synapse and not Axis2!
> Am I deeply mislead or missing a crucial piece of logic here ?
I much prefer Ant's suggestion in reply to your mail - create a new type
and embed Axis2's MC inside it.
Ant, you seem to imply that that approach was suggested earlier and
rejected .. what I was arguing against earlier was creating an
*alternate* MC; you are not suggesting an alternate but rather embedding
the Axis2 MC and use delegation to expose what Synapse finds useful. I
like that approach.
Sanjiva.
