[
https://issues.apache.org/jira/browse/SYNAPSE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636522#action_12636522
]
Ruwan Linton commented on SYNAPSE-443:
--
Can you please point me how to reproduce this
[
https://issues.apache.org/jira/browse/SYNAPSE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruwan Linton reassigned SYNAPSE-443:
Assignee: Ruwan Linton
> If ClientHandler receives a response of bad request from http ser
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 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
there
> 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; s
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 poin
> 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 ch
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
transp
> 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 a
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 w
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 mu
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.
Thanks,
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 9:0
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 Sy
I am with Deepal on this, why change if there is no eral gain and possible user
pain.
Tom Jordahl
-Original Message-
From: Deepal jayasinghe [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 11:32 AM
To: dev@synapse.apache.org
Cc: [EMAIL PROTECTED]
Subject: Re: [Axis2] Moving
> 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 Neeth
> +1 I dont see any issues in renaming the packages too.
:) , the issue is backward compatibility , which is an issues for me :)
.The reason is doing major changes to a project like Axis2 in this stage
is not a good idea.
-Deepal
>
> Thanks,
> Keith.
>
> On Thu, Oct 2, 2008 at 7:11 PM, Paul Frema
+1 - given that these are set in axis2.xml I see no issue in changing the
package names.
Sanjiva.
Paul Fremantle wrote:
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
Subjec
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 t
+1 I dont see any issues in renaming the packages too.
Thanks,
Keith.
On Thu, Oct 2, 2008 at 7:11 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> 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 t
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: dev@synapse.apache.org
Deepal
There is a problem :)
Th
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) Synapse would like to do a
release before the next Axis2 release. Because the old t
Allow the property mediator to set Boolean properties
-
Key: SYNAPSE-458
URL: https://issues.apache.org/jira/browse/SYNAPSE-458
Project: Synapse
Issue Type: Improvement
Affects Versions
[
https://issues.apache.org/jira/browse/SYNAPSE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636334#action_12636334
]
harm verhagen commented on SYNAPSE-455:
---
reproduced by asankha at wso2.com
http://w
allow dbreport mediator to have a result
Key: SYNAPSE-457
URL: https://issues.apache.org/jira/browse/SYNAPSE-457
Project: Synapse
Issue Type: Improvement
Affects Versions: 1.2
Reporter
25 matches
Mail list logo
