synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: [Axis2][Proposal] Move JMS / Async NIO transports out of Axis2 into Synapse
Date Tue, 22 Apr 2008 16:49:58 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message