-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Agreed that this is definitely a problem.
Next question, is do you want do this in Synapse Commons (do you have one?) or WS Commons? - -- dims Ruwan Linton wrote: | 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: | | 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] | |> | |> | |> - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |> |> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIDkjrgNg6eWEDv1kRAuGrAJ9i68sD0DZ0tNQcRIPNF5vM9XSyYACePxMC mx0ZcjXfZ8XARq6IuL7XRmM= =+UFi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
