axis-java-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 Wed, 23 Apr 2008 11:43:41 GMT
Hey Sanjiva:

Sanjiva Weerawarana wrote:
> - I agree with that Axis2 transports should NOT be in the kernel jar. 
> Can we finally agree (forget the history please) to that now and create 
> new maven modules for each transport and put each one into its own jar? 
> This is for the transports that are (or will remain) in ws/axis2.


And while we're at it (separate conversation though), perhaps transports 
should be deployable as easily as services/modules...


...with transport.xml inside *.tsp/META-INF

> - Given that these transports are usable by anyone building on Axis2 
> (and not just Synapse) and that they depend on Axis2 APIs, I believe 
> they should be in a project which releases those transports against 
> given versions of Axis2 APIs. My preference is that it should be in 
> ws/commons/transports or a new sub-project called ws/transports. 
> Asankha, what problem do you see in that approach? I think everyone 
> would +1 you being the RM for this project ;-).

Sounds like a plan. :)

See - you might not have 
seen that due to the lack of [axis2] prefix.

> - How about the following compromise position:
>   - we create a new ws/transports project and move http and any other 
> transports out of axis2 into that.

New mailing lists, then?  (oh joy more folders :))  I could be ok with 
this, but I think using commons is simpler.

>   - we kill the old NHTTP and JMS tranports in axis2

Dims is already on this.

>   - move JMS and SMTP out of synapse into the new project

+1.  We should look at which if any of the Synapse transports are not 
generally applicable outside the Synapse context, and move all the others.

>   - as a general rule, if Axis2 and Synapse are both going to ship the 
> transport in their default distros, then we move the code here

I'd tweak that - as a general rule, if the transport is generally useful 
to both projects, it should live here to make sure it gets tested in 
both contexts.

>   - for other transports we strongly encourage people to put them here 
> to enable easier wider use (e.g., WSO2 Mashup Server would inherit all 
> the transports in Axis2 but not those from Synapse .. I think Asankha 
> would want the new and improved SMTP transport to be in the WSO2 Mashup 
> Server too ;-)). Of course we can't enforce that but I would hope that 
> we should be able to come to a sufficient community understanding 
> between the Synapse and WS TLPs to make that work.


>   - this project publishes each transport as a separate jar with a 
> naming convention that identifies the axis2 (API) version it corresponds 
> to. of course trunk will correspond to trunk as always

Need to think about that a bit.

>   - I'm ok with going one step further and even moving the Axis2 
> transport APIs into the project and for Axis2 to just use them. This is 
> like what Axis2 does with Axiom for example.

+1, yup.

> The result is that the transports become an enabler for Axis2 (and 
> Synapse and more) just as much as Axiom or XMLSchema is. The benefit is 
> that they're no longer "Axis2's transports" or "Synapse's transports" 
> but rather "those common transports". (I have to admit I didn't look at 
> the code to evaluate the realisticness of this bit of the proposal - but 
> the rest of it stands on its own anyway.)

Well, they ARE still Axis2 transports in that they exist to extend Axis2 
- they're just in a common place so other users of Axis2 (Synapse in 
particular) can share them easier.  Aside from the issues around 
perception, I think it would make just as much sense to have them under 
axis2/ (assuming we could release them separately, etc).  No, I'm not 
proposing that. :)


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

View raw message