Apologies for reposting I forgot to reply-all.
Paul
-- Forwarded message --
From: Paul Fremantle [EMAIL PROTECTED]
Date: Thu, Oct 2, 2008 at 2:41 PM
Subject: Re: [Axis2] Moving all the transports into a common modules
To: [EMAIL PROTECTED]
Deepal
There is a problem :)
The JMS
Hi Paul and all,
Deepal
There is a problem :)
The JMS transport is completely different. So we can't take the
Synapse JMS transport and give it the name of the different (old)
Axis2 transport.
That is fine , because JMS is not a commonly used transport in Axis2 , I
mean most of the
: Re: [Axis2] Moving all the transports into a common modules
To: [EMAIL PROTECTED]
Deepal
There is a problem :)
The JMS transport is completely different. So we can't take the
Synapse JMS transport and give it the name of the different (old)
Axis2 transport.
The second problem is that (suppose
hi,
the package name that commons transport module use is org.apache.axis2
I think it should be org.apache.ws.commons
Saying no one more time :)
I do not think that all the modules in commons should have the package
name org.apache.ws.commons , as an example have a look at Axiom and Neethi
all the transports into a common modules
hi,
the package name that commons transport module use is org.apache.axis2
I think it should be org.apache.ws.commons
Saying no one more time :)
I do not think that all the modules in commons should have the package
name org.apache.ws.commons
Paul,
Currently Synapse trunk depends on the snapshot version of Axis2.
Logically, this means that we will only release a new version of Synapse
after the next release of Axis2 (or alternatively release a Synapse
version depending on an Axis2 snapshot). If you consider the possibility
of a
Hi Deepal,
Synapse also has the same backward compatibility issue that you are talking
about with the axis2.xml that synapse ships with, therefore shall we keep
the transports that synapse community contributed as it is
(org.apache.synapse.transports) ;-)
Thanks,
Ruwan
On Thu, Oct 2, 2008 at
Andreas,
There doesn't seem to be a soon Axis2 release, but from my point of view
synapse community might want a release with an existing axis2 release
Probably 1.4.1 before going for the next version of axis2 in which case we
need to back down to the axis2-1.4.1 release, which is OK.
I don't see any issue with backward compatibility. This chage is something
in the axis2.xml, this will not break any code that users have with them. If
it was a API call then I can understand. Also this change would not effect
generated code (AFAIK).
Thanks,
Keith.
On Thu, Oct 2, 2008 at 9:54
On Thu, Oct 2, 2008 at 9:54 PM, Ruwan Linton [EMAIL PROTECTED] wrote:
Hi Deepal,
Synapse also has the same backward compatibility issue that you are talking
about with the axis2.xml that synapse ships with, therefore shall we keep
the transports that synapse community contributed as it is
We can easily guarantee backward compatibility (for axis2.xml) by having
a set of classes with the old package names and extending the
corresponding classes in the new version. Since this is only needed for
transport listeners/senders and message formatters/builders, it would
not require too
Well, you are correct andreas, but the real problem is if we (synapse) want
to go for a release with an existing axis2 release in which case there will
be two classes having the name org.apache.axis2.transports.jms.JMSSender
even though we worked around the backward compatibility of axis2.xml
Do
Ruwan Linton wrote:
Hi Deepal,
Synapse also has the same backward compatibility issue that you are
talking about with the axis2.xml that synapse ships with, therefore
shall we keep the transports that synapse community contributed as it
is (org.apache.synapse.transports) ;-)
yes of course .
I don't see any issue with backward compatibility. This chage is
something in the axis2.xml, this will not break any code that users
have with them.
Thats exactly my point I should be able to upgrade Axis2 without
changing axis2.xml. If you work with default axis2.xml then you do not
have any
So how about this for a compromise:
1) We ship all the new transports in separate JARs
2) We rename all the transports to a new package name
3) We do Andreas' suggestion - just for HTTP - so that the old
axis2.xml will work
4) Synapse can ship all new transports - everything except the HTTP
So how about this for a compromise:
1) We ship all the new transports in separate JARs
+1 and we can have a single jar containing all the transports as well
(thats working now)
2) We rename all the transports to a new package name
I am sorry I am not still convinced to do this change.
I'm happy with Paul's proposal. However there is also another
alternative:
1) Keep the org.apache.axis2.transport package name for all transports
(as it is now in trunk).
2) Before creating the first release of the new transports (and
therefore also before the next Synapse release; see
I'm happy with Paul's proposal. However there is also another
alternative:
1) Keep the org.apache.axis2.transport package name for all transports
(as it is now in trunk).
2) Before creating the first release of the new transports (and
therefore also before the next Synapse release; see
On 2 oct. 08, at 23:45, Deepal jayasinghe wrote:
I'm happy with Paul's proposal. However there is also another
alternative:
1) Keep the org.apache.axis2.transport package name for all
transports
(as it is now in trunk).
2) Before creating the first release of the new transports (and
Andreas
I didn't express my idea clearly. What I meant was that in my proposal, only
the transports coming from Synapse will have new package names, so there is
no impact on the Axis2 community in general and the package renames will
only be a concern for Synapse.
My only concern is that
On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen
[EMAIL PROTECTED]wrote:
Deepal,
Before we can move anything from Synapse to the new commons module, we need
to decide which transports we move (all or only a subset) and based on that,
we need to make sure that all the people involved in the
hi,
the package name that commons transport module use is org.apache.axis2
I think it should be org.apache.ws.commons
WDYT?
thanks,
Amila.
On Mon, Sep 22, 2008 at 12:03 PM, Amila Suriarachchi
[EMAIL PROTECTED] wrote:
On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen
[EMAIL PROTECTED]
Amila,
Please don't move anything for the moment. We need to make sure that
this is well coordinated before doing anything. I will come back on this
later.
Andreas
Amila Suriarachchi wrote:
On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Hi all
I will be moving the Mail, JMS and the Base Transport abstraction into
the WS Commons project now.
Then on WS-Commons dev list (CC:ing axis2-dev), I will be calling for a
vote for commit rights to Andreas, so that he can help maintain the codebase
We will consider moving other
+1 for moving these transports,
Thanks,
Ruwan
On Mon, Sep 22, 2008 at 1:37 PM, Asankha C. Perera [EMAIL PROTECTED] wrote:
Hi all
I will be moving the Mail, JMS and the Base Transport abstraction into the
WS Commons project now.
Then on WS-Commons dev list (CC:ing axis2-dev), I will be
Amila Suriarachchi wrote:
hi,
the package name that commons transport module use is org.apache.axis2
I think it should be org.apache.ws.commons
No Amila , we can not do that for transport like HTTP , that would be a
major change and backward compatibility killer. So lets keep the
package
Deepal,
Before we can move anything from Synapse to the new commons module, we
need to decide which transports we move (all or only a subset) and
based on that, we need to make sure that all the people involved in
the maintenance of these transports have commit access to the new
module.
Deepal,
Before we can move anything from Synapse to the new commons module, we
need to decide which transports we move (all or only a subset) and
based on that, we need to make sure that all the people involved in
the maintenance of these transports have commit access to the new module.
+1
On Sun, Sep 21, 2008 at 2:59 PM, Andreas Veithen
[EMAIL PROTECTED]wrote:
Deepal,
Before we can move anything from Synapse to the new commons module, we need
to decide which transports we move (all or only a subset) and based on that,
we need to make sure that all the people involved in the
Hi all,
Few months back we all agreed to move all commons transports (from Axis2
and Synapse) to a common module. As the first step of that I have moved
all the Axis2 to transport into a common module in ws-commons [1]. In
addition to that we have setup nightly builds from that modules. So now
30 matches
Mail list logo
