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 <[EMAIL PROTECTED]> wrote: > Hi Dims, Glen and all, > > On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > | For additional commands, e-mail: [EMAIL PROTECTED] > > | > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.5 (Cygwin) > > > > iD4DBQFIDh3xgNg6eWEDv1kRArQ9AJ44ct3OR4J4djeY0ttNox3rhpkPGwCXYbdj > > n+u3lNY14rCRKaSFT9s+Hw== > > =Nw0Q > > -----END PGP SIGNATURE----- > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Ruwan Linton > http://www.wso2.org - "Oxygenating the Web Services Platform" > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
