Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 33618 invoked from network); 22 Apr 2008 17:50:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Apr 2008 17:50:20 -0000 Received: (qmail 75970 invoked by uid 500); 22 Apr 2008 17:50:15 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 75919 invoked by uid 500); 22 Apr 2008 17:50:15 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 75881 invoked by uid 99); 22 Apr 2008 17:50:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Apr 2008 10:50:14 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ruwan.linton@gmail.com designates 209.85.142.188 as permitted sender) Received: from [209.85.142.188] (HELO ti-out-0910.google.com) (209.85.142.188) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Apr 2008 17:49:21 +0000 Received: by ti-out-0910.google.com with SMTP id d10so878815tib.18 for ; Tue, 22 Apr 2008 10:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=sHIw0kSRKAQ/GjlBzzYNnNjvF3aDsOHnsrNNsiU0N0s=; b=S6znOlclRmdTSjz5kgaQmMRG5CxCSD8OS33S0lVWJYwEI+3Au47XG1i74b76fYFNw44X1LGwQTe3zXr+IV4vbu0tqbyJQEVj5e8TEHfxqD3NKzgav9pXd0pBOx7Evrt0jvHfqtTVhYw4BEvFaOooz/EK+uM5dcC3zje6fXf0CqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tiNPXaVCHwhT6e0tVO39mCJ8wfHo6MiSGTrK+7BIAFEyr+xjw61noiBs3Z2Q8LyiqaXD060U5CsBvmtmVBdNSreTOFmSmfqmr5vesclJkzGU3d264aJ7OXO2wnhYJ8i+KYnPSHFzP0qDoWl20w35VfVUM8DFdrt0w43+C2ZLiS8= Received: by 10.110.11.10 with SMTP id 10mr45106tik.44.1208886579600; Tue, 22 Apr 2008 10:49:39 -0700 (PDT) Received: by 10.110.53.4 with HTTP; Tue, 22 Apr 2008 10:49:39 -0700 (PDT) Message-ID: <672a01200804221049x4776f919rb070cf2b874e8bb9@mail.gmail.com> Date: Tue, 22 Apr 2008 23:19:39 +0530 From: "Ruwan Linton" To: axis-dev@ws.apache.org Subject: Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse In-Reply-To: <672a01200804221046v637cedf8k218a53b4cc952665@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6547_29215791.1208886579590" References: <480DDAC0.8070603@gmail.com> <480DDC0C.3020305@gmail.com> <480DE7DB.2090501@thoughtcraft.com> <480DE83B.1050503@gmail.com> <480DECF8.1050706@gmail.com> <480E0A4E.7010707@wso2.com> <480E1736.8040008@thoughtcraft.com> <480E1DF2.7000203@gmail.com> <672a01200804221046v637cedf8k218a53b4cc952665@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_6547_29215791.1208886579590 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I forgot to mention that, of cause one can use these transports with knowing the limitations and issues of those, when working directly with axis2 Thanks, Ruwan On Tue, Apr 22, 2008 at 11:16 PM, Ruwan Linton wrote: > Hi Dims, Glen and all, > > On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Glen, > > > > At this point, Can we please agree that it's better for the people who > > actually work on it have their way :) > > > +1 for this idea ... and one more thing is that; > > Although the transports which resides under synapse code base are just > axis2 transports, there are some special cases that synapse needs from its > transports. For example; > > - nhttp transport requires 202 Accepted HTTP messages to be injected > inside to synapse so that it can complete mediation of one-way messages as > well as we need those messages to be injected on the separateListener case, > where as axis2 should just neglect those HTTP messages. > - Same with 500 Internal Server Error on nhttp > - smtp transport requires to treat all the Cc headers and Cc the > message to all the specified addresses (we have discussed this earlier on > axis2 and this is wrong according to the WS-MEPs, because there are many > outs) > > There are a number of synapse specific logic inside synapse transports, > because synapse is not purely bound to WS space, but it is a mediation > framework (ESB) which should support most of the other scenarios going out > of the WS space. There for these transports may not directly work with axis2 > and it is not at all a good idea to move them out from synapse code base. > > Thanks, > Ruwan > > > > > > > > thanks, > > dims > > > > > > Glen Daniels wrote: > > | Asankha C. Perera wrote: > > |> Dims > > |>> - there should not be stale copies > > |>> - people who work on them should work where they want to. > > |> +1 to both! > > | > > | Agreed - I'd just prefer people wanted to work on them under WS/Axis. > > :) > > | > > |> I'd like to maintain these under Synapse.. We wrote these transports > > |> primarily for use by Synapse, and now we have JMS, NIO-HTTP/S, Mail, > > |> VFS (File), FIX and AMQP already.. These belong to a separate Maven > > |> module thats published to the Apache snapshots and Maven Central > > |> repos, and > > | > > | Hm. So this is a bit of a separate conversation, but *each* of the > > | transports should be its own deployable artifact. If I want the AMQP > > | transport for some work I'm doing, I don't want to bother downloading > > | all the others.... Wherever they end up we should fix that!! > > | > > |> this JAR does not depend on the Synapse codebase at all. Anyone who > > |> wishes to use these can do so without any problems whatsoever, and > > |> raise JIRA's for bugs/enhancements where the code is actually > > maintained. > > | > > | Yeah. I just think this makes a lot more sense under WS. > > | > > |>> | | These transports (JMS, NIO, whatever) are going to be generally > > |>> useful to any Axis2 user, so why make them go look in Synapse's > > |>> codebase for them? > > |> I agree,.. however these transports were written by the Synapse > > |> community for primary use by them. So instead of asking them to > > |> maintain the code they write somewhere else - for the convenience of > > |> the secondary users, why not clearly document the available options > > |> under Axis2 and where one could download these extension transports > > |> developed by the Synapse community? > > | > > | Sure, I'm not saying that wouldn't work - what's really important to > > me > > | is that Axis2 users get a clear picture of the available transports > > when > > | they download Axis2 and use our website. This is both to avoid > > | duplication of effort and to enable users to use the richest set of > > | components available. It seems to me that the most natural way to > > | achieve this is to contribute new transports to ws-commons or Axis2. > > | > > | Also consider this - wouldn't it be cool to be able to run the Axis2 > > | test suite (which is presumably much more comprehensive than Synapse's > > | testing of Axis2) over each of the transports that Synapse originally > > | built? I would think that might demonstrate some issues that Synapse > > | itself might not find, thus enabling the transports to be improved. > > | > > | But if the community wants to keep developing these under Synapse, > > then > > | we definitely need some pointers in the Axis2 code and web pages, and > > | those pointers need to be maintained. > > | > > | Thanks, > > | --Glen > > | > > | --------------------------------------------------------------------- > > | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > | For additional commands, e-mail: axis-dev-help@ws.apache.org > > | > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.5 (Cygwin) > > > > iD4DBQFIDh3xgNg6eWEDv1kRArQ9AJ44ct3OR4J4djeY0ttNox3rhpkPGwCXYbdj > > n+u3lNY14rCRKaSFT9s+Hw== > > =Nw0Q > > -----END PGP SIGNATURE----- > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > > > > > -- > Ruwan Linton > http://www.wso2.org - "Oxygenating the Web Services Platform" > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform" ------=_Part_6547_29215791.1208886579590 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I forgot to mention that, of cause one can use these transports with knowing the limitations and issues of those, when working directly with axis2

Thanks,
Ruwan

On Tue, Apr 22, 2008 at 11:16 PM, Ruwan Linton <ruwan.linton@gmail.com> wrote:
Hi Dims, Glen and all,

On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas <davanum@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glen,

At this point, Can we please agree that it's better for the people who actually work on it have their way :)

+1 for this idea ... and one more thing is that;

Although the transports which resides under synapse code base are just axis2 transports, there are some special cases that synapse needs from its transports. For example;

  • nhttp transport requires 202 Accepted HTTP messages to be injected inside to synapse so that it can complete mediation of one-way messages as well as we need those messages to be injected on the separateListener case, where as axis2 should just neglect those HTTP messages.
  • Same with 500 Internal Server Error on nhttp
  • smtp transport requires to treat all the Cc headers and Cc the message to all the specified addresses (we have discussed this earlier on axis2 and this is wrong according to the WS-MEPs, because there are many outs)
There are a number of synapse specific logic inside synapse transports, because synapse is not purely bound to WS space, but it is a mediation framework (ESB) which should support most of the other scenarios going out of the WS space. There for these transports may not directly work with axis2 and it is not at all a good idea to move them out from synapse code base.

Thanks,
Ruwan
 


thanks,
dims


Glen Daniels wrote:
| Asankha C. Perera wrote:
|> Dims
|>> - there should not be stale copies
|>> - people who work on them should work where they want to.
|> +1 to both!
|
| Agreed - I'd just prefer people wanted to work on them under WS/Axis. :)
|
|> I'd like to maintain these under Synapse.. We wrote these transports
|> primarily for use by Synapse, and now we have JMS, NIO-HTTP/S, Mail,
|> VFS (File), FIX and AMQP already.. These belong to a separate Maven
|> module thats published to the Apache snapshots and Maven Central
|> repos, and
|
| Hm.  So this is a bit of a separate conversation, but *each* of the
| transports should be its own deployable artifact.  If I want the AMQP
| transport for some work I'm doing, I don't want to bother downloading
| all the others....  Wherever they end up we should fix that!!
|
|> this JAR does not depend on the Synapse codebase at all. Anyone who
|> wishes to use these can do so without any problems whatsoever, and
|> raise JIRA's for bugs/enhancements where the code is actually maintained.
|
| Yeah.  I just think this makes a lot more sense under WS.
|
|>> | | These transports (JMS, NIO, whatever) are going to be generally
|>> useful to any Axis2 user, so why make them go look in Synapse's
|>> codebase for them?
|> I agree,.. however these transports were written by the Synapse
|> community for primary use by them. So instead of asking them to
|> maintain the code they write somewhere else - for the convenience of
|> the secondary users, why not clearly document the available options
|> under Axis2 and where one could download these extension transports
|> developed by the Synapse community?
|
| Sure, I'm not saying that wouldn't work - what's really important to me
| is that Axis2 users get a clear picture of the available transports when
| they download Axis2 and use our website.  This is both to avoid
| duplication of effort and to enable users to use the richest set of
| components available.  It seems to me that the most natural way to
| achieve this is to contribute new transports to ws-commons or Axis2.
|
| Also consider this - wouldn't it be cool to be able to run the Axis2
| test suite (which is presumably much more comprehensive than Synapse's
| testing of Axis2) over each of the transports that Synapse originally
| built?  I would think that might demonstrate some issues that Synapse
| itself might not find, thus enabling the transports to be improved.
|
| But if the community wants to keep developing these under Synapse, then
| we definitely need some pointers in the Axis2 code and web pages, and
| those pointers need to be maintained.
|
| Thanks,
| --Glen
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| For additional commands, e-mail: axis-dev-help@ws.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD4DBQFIDh3xgNg6eWEDv1kRArQ9AJ44ct3OR4J4djeY0ttNox3rhpkPGwCXYbdj
n+u3lNY14rCRKaSFT9s+Hw==
=Nw0Q
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org




--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"



--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform" ------=_Part_6547_29215791.1208886579590--