My biggest concern with putting these in Synapse is the dependency chain. Since the APIs are defined as part of Axis2, I think it makes more sense for these to live in the WS space. So my preference would be to have these (and others) in commons/transports
Paul On Tue, Apr 22, 2008 at 6:49 PM, Ruwan Linton <[EMAIL PROTECTED]> wrote: > 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" -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
