axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse
Date Tue, 22 Apr 2008 19:14:19 GMT
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 <davanum@gmail.com>
wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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 <glen@thoughtcraft.com>
> | 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 <ruwan.linton@gmail.com
<mailto:
> |>> ruwan.linton@gmail.com>> wrote:
> |>>
> |>>    Hi Dims, Glen and all,
> |>>
> |>>    On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas
> |>>    <davanum@gmail.com <mailto:davanum@gmail.com>> 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: axis-dev-unsubscribe@ws.apache.org
> | <mailto:axis-dev-unsubscribe@ws.apache.org>
> | | For additional commands, e-mail: axis-dev-help@ws.apache.org
> | <mailto:axis-dev-help@ws.apache.org>
> | |
> |>>
> |>>
> |>>
>
> |>>  ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <mailto:axis-dev-unsubscribe@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <mailto: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"
> |>>
> |> ---------------------------------------------------------------------
> |> 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)
>
> iD8DBQFIDjKKgNg6eWEDv1kRAh1oAKDIPJ82Fr+3ddfsLKFVWqM4kNDIsQCdENFH
> aJEx3JawYLsf7TzW9ybtGYc=
> =8Rqf
>
> -----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"

Mime
View raw message