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 18:40:14 GMT
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:
> >
> >        -----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: 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>
> >        |
> >        -----BEGIN PGP SIGNATURE-----
> >        Version: GnuPG v1.4.5 (Cygwin)
> >
> >        iD4DBQFIDh3xgNg6eWEDv1kRArQ9AJ44ct3OR4J4djeY0ttNox3rhpkPGwCXYbdj
> >        n+u3lNY14rCRKaSFT9s+Hw==
> >        =Nw0Q
> >        -----END PGP SIGNATURE-----
> >
> >
> >
> >  ---------------------------------------------------------------------
> >        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
>
>


-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Mime
View raw message