Dims, I agree there is no -1, but at the same time we couldn't get those fixes into axis2 SMTP transport on our release time frame of synapse and we went ahead with our own one.
BTW: If we are to move these transports out from synapse, it has to be in to a separate commons project (not on to axis2), so that we have the control over them to do the required changes. Thanks, Ruwan On Wed, Apr 23, 2008 at 1:17 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ruwan, > > All i see is some discussion, which happens on a topic > > http://marc.info/?t=119684680300006&r=1&w=3 > > - - Where is the push back? From who? > - - Where is the VOTE? > - - Where is a -1? > > thanks, > dims > > Ruwan Linton wrote: > | Dims, > | > | I couldn't find this on the axis2 mail archives, that thread was having > the > | subject "Improvement to mail transport from a Synapse use case" and > posted > | by saminda to the axis-dev. > | > | Here is the relevant thread on Synapse [ > | http://mail-archives.apache.org/mod_mbox/synapse-user/200712.mbox/thread > ] > | > | Thanks, > | Ruwan > | > | On Wed, Apr 23, 2008 at 12:16 AM, Davanum Srinivas <[EMAIL PROTECTED]> > | wrote: > | Ruwan, > | > | How about a pointer to a public discussion on why SMTP Transport changes > |> were debated? :) > | -- dims > | > | > | > | > | Ruwan Linton wrote: > | | Glen, > | | > | | I agree with you. But my concern is the history. That is, when ever we > | | (synapse) wanted some transport specific feature for synapse to be > added > |> to > | | axis2 transports axis2 community was not accepting them due to many > |> reasons > | | most of them are valid for web services, but from the synapse point of > |> view, > | | we do not need to (and should not) bound to the web services. Isn't > it? > | | > | | This behavior is affecting the evolution of synapse and that is why we > |> went > | | ahead and developed our own transports. (Best example is the SMTP > |> transport) > | | > | | Thanks, > | | Ruwan > | | > | | On Tue, Apr 22, 2008 at 11:48 PM, Glen Daniels <[EMAIL PROTECTED]> > | | wrote: > | | > | |> Hi Ruwan: > | |> > | |> If a given transport really only has relevance in the Synapse > |> environment, > | |> then of course that transport has no need to exist outside Synapse. > |> But if > | |> a transport is generically useful, I'd prefer to see it somewhere in > WS > | |> space as opposed to specifically within Synapse. And if some generic > | |> transport needs tweaking in particular ways for Synapse, then those > |> ways > | |> should be exposed as configuration or plug-points on the transport, > |> which > | |> get exercised by Synapse (but also tested in the transport build). > |> Example > | |> - the nhttp transport could just include a callback property which, > if > |> set, > | |> passes the 202 to a listener and ignores it otherwise (perhaps that's > | |> exactly the way it works). In the SMTP case, we should discuss what > | |> happens, but again I don't see any issue with making a clean and > useful > | |> general SMTP transport - why should there need to be two of them?? > | |> > | |> Here's my use case. Someone wants to use nhttp, or JMS, or SMTP, > with > | |> Axis2. They're not a Synapse user and are not interested in > |> downloading > | |> Synapse. I want to make sure that this user can easily locate, > |> download, > | |> and install the transport they want. At the same time I want the > Axis2 > |> and > | |> the Synapse communities both sharing their skills to make the best > set > |> of > | |> transports available for Axis2 and of course Axis2+Synapse. > | |> > | |> I'm not wedded to the details, as long as we can make that happen. > It > | |> seems to me right now that ws-commons/transports is a better way to > do > |> this > | |> than having lots of extension transports in Synapse, but I'm willing > to > |> be > | |> convinced otherwise. > | |> > | |> Thanks, > | |> --Glen > | |> > | |> Ruwan Linton 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] > |> <mailto: > | |>> [EMAIL PROTECTED]>> wrote: > | |>> > | |>> Hi Dims, Glen and all, > | |>> > | |>> On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas > | |>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > | |>> > | > | > | > | | 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] > | | <mailto:[EMAIL PROTECTED]> > | | | For additional commands, e-mail: [EMAIL PROTECTED] > | | <mailto:[EMAIL PROTECTED]> > | | | > | |>> > | |>> > | |>> > | > | |>> > --------------------------------------------------------------------- > | To unsubscribe, e-mail: [EMAIL PROTECTED] > | <mailto:[EMAIL PROTECTED]> > | For additional commands, e-mail: [EMAIL PROTECTED] > | <mailto:[EMAIL PROTECTED]> > | |>> > | |>> > | |>> > | |>> > | |>> -- Ruwan Linton > | |>> http://www.wso2.org - "Oxygenating the Web Services Platform" > | |>> > | |>> > | |>> > | |>> -- > | |>> Ruwan Linton > | |>> http://www.wso2.org - "Oxygenating the Web Services Platform" > | |>> > | |> --------------------------------------------------------------------- > | |> To unsubscribe, e-mail: [EMAIL PROTECTED] > | |> For additional commands, e-mail: [EMAIL PROTECTED] > | |> > | |> > | > | > |> > - --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > |> > |> > |> > For additional commands, e-mail: [EMAIL PROTECTED] > |> > |> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Cygwin) > > iD4DBQFIDkDSgNg6eWEDv1kRAgbhAJ4hEqtqTp7Xc2C2SoKRp7x85H8lHQCY144n > UEgjToYwR6teYulTJdfFIA== > =lhqw > > -----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"
