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:
-----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]
<mailto:[EMAIL PROTECTED]>
| For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[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]
<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]
