Hi David
I also think it would be reasonable to split the
transports out of axis2-kernel.
Great :-)..
I think where I'm worried is the idea that we could do a quick .1
release with that kind of change - that's simply not realistic. It's
definately something that would require a fair amount of testing.
What's the desired timeframe for the synapse release we're talking
about?
I totally agree.. and I am not pushing for that right away.. I can
manage the next release of Synapse (i.e. 1.1) the way things are using a
few tricks like putting our copy of the transport in-front of the
Axis2-kernel etc. at runtime.
My intention would be to explain the reasoning behind asking for this
change and make sure that Axis2 folks are comfortable with a split like
this for the next planned Axis2 release. This maybe a point release or a
major release - and need not be in a hurry to support Synapse
thanks
asankha
On 05/10/2007, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
----------------
Note: For some strange reason, this mail returned twice with the error:
<[EMAIL PROTECTED]>:
140.211.11.136 failed after I sent the message.
Remote host said: 552 spam score (5.9) exceeded threshold
and thus I am sending this as a new message instead of a reply to the thread
----------------
Guys.. the confusion/problem/root cause is this.. the Synapse community
re-wrote the JMS transport initially, and checked this into the Axis2
Kernel module as other transports were in there at the time. Actually
this replaced the previous JMS transport Axis2 had.
Then we wrote a new non-blocking http/s transport, and kept this within
Synapse. After some time there was a suggestion from Axis2 that we
should check this code into Axis2 instead to make it available to a
wider audience for usage, testing and improving overall quality as well.
Thus we checked this into Axis2 [Kernel :-(]
Now the problem is this.. The JMS transport was implemented for JMS 1.1,
and the ESB community encountered users who wanted to deploy production
apps using JMS 1.0.2. We also had a few bug fixes going into the NIO
transport - where we couldn't wait for "the next axis2" release. We also
developed a Apache VFS based file/ftp/sftp/.. transport lately. We would
like to give this code to all Axis2 users for sure, but not within the
Axis2-kernel module - as it would create issues for us to make never
versions of these same classes for our use.
As you may be already aware, Synapse is very close to transports - i.e.
we want the maximum out of them, and would encounter most users who
would be looking for custom transports etc. We also do lots of load
testing for concurrency and NIO related issues.. and we want to stay
upto-date with the latest HttpCore release. Now since we committed our
initial transport code into Axis2-kernel, we are in a fix on making safe
updates as and when required for Synapse releases.
All we ask for is for Axis2 to create a module for transports and take
transports out from the kernel.
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
