Hi Devs,
The op_client property reuse is set to false inside
axis2_op_client_add_msg_ctx so that this has to be enabled for every
single op_client call. Should not this be a client-level setting that
ought to be reset explicitly?.
Danushka
--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.
Getting java.lang.NoSuchMethodError: org.apache.axis.descrip
Key: AXIS-2781
URL: https://issues.apache.org/jira/browse/AXIS-2781
Project: Axis
Issue Type: Bug
Refactored the changes made when improving Faulty Services handling.
Key: AXIS2-4289
URL: https://issues.apache.org/jira/browse/AXIS2-4289
Project: Axis 2.0 (Axis2)
Issue
[
https://issues.apache.org/jira/browse/AXIS2-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sameera Jayasoma updated AXIS2-4289:
Attachment: patch-axis2-trunk-30-03-2009-01.txt
Patch is attached
Refactored the changes
[
https://issues.apache.org/jira/browse/AXIS2-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isuru Eranga Suriarachchi resolved AXIS2-4284.
--
Resolution: Fixed
Committed the fix in trunk
Improving JAXWS WSDL
Hi,
Apache ServiceMix have given support for SMPP using a SMPP component [1]
I think that code[2] will be useful to me as a reference.
And i have updated my proposal to the New Apache Proposal format It can be
found at
http://wiki.apache.org/general/charith/gsoc2009/axis2transportProposal
Hi, I tried to build the Axis2 1.5 beta 2 again, but now it fails
during the building of the scripting module:
---
[INFO] Building Apache Axis2 - Scripting
[INFO]
[
https://issues.apache.org/jira/browse/AXIS2-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12693810#action_12693810
]
Ed Komp commented on AXIS2-4272:
There are a few related JIRA's that indicate that the
Hi folks:
So I'm trying to get the transports 1.0 releases moving along, and have run
into a bit of a snag. The transports depend on axis2-kernel SNAPSHOT, for
interfaces like MessageContext, Flow, etc. - the problem is how do we do the
release when we want to release the transports before the
If transports is using these Axis2 interfaces I don't see the point of
having it as a separate project. I thought the reason for moving
transports outside of Axis2 was to allow it to be used for other
purposes. How is that going to work if the code is assuming the Axis2
environment?
The only
I'm sorry, I'm kind of new around here, but the basic strategy that I know
to follow is to cut a branch, change the dependency in the pom of the branch
to the released version of the upstream dependency that you're milestoning
against, and then release from the branch.
If you can't do this
Repository updatePolicies are inverted
--
Key: AXIS2-4290
URL: https://issues.apache.org/jira/browse/AXIS2-4290
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: samples, build,site
maven-surefire-plugin skip=true in parent, but skip=false in every other module
---
Key: AXIS2-4291
URL: https://issues.apache.org/jira/browse/AXIS2-4291
Project: Axis 2.0
Hi Jason:
Jason Fager wrote:
I'm sorry, I'm kind of new around here, but the basic strategy that I know
Welcome! :)
to follow is to cut a branch, change the dependency in the pom of the branch
to the released version of the upstream dependency that you're milestoning
against, and then
Oops - sent that before I finished editing.
Glen Daniels wrote:
The was never to release the transports without dependency on Axis2 - they
are *Axis2* transports, and while they're pluggable components, they're not
designed for usage outside of Axis2 (Synapse notwithstanding - Synapse is
I mentioned two additional ideas to deal with this problem a while ago
when this issue also came up:
1) Release transports and axis2 at the same time. Have one vote for
both libraries.
2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way
Jarek Gawor wrote:
...
2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way the transports project would
only have the 'optional' transport modules and we wouldn't have to
release the transports for/with Axis2.
+1 for this approach.
On Tue, Mar 31, 2009 at 8:20 AM, Jarek Gawor jga...@gmail.com wrote:
I mentioned two additional ideas to deal with this problem a while ago
when this issue also came up:
1) Release transports and axis2 at the same time. Have one vote for
both libraries.
+1. I think this the best way.
2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way the transports project would
only have the 'optional' transport modules and we wouldn't have to
release the transports for/with Axis2.
You can take back just http and local into Axis2 if
On Tue, Mar 31, 2009 at 2:59 AM, Dennis Sosnoski d...@sosnoski.com wrote:
If transports is using these Axis2 interfaces I don't see the point of
having it as a separate project. I thought the reason for moving transports
outside of Axis2 was to allow it to be used for other purposes. How is
Amila Suriarachchi wrote:
Here the main idea was to share the same transports between Axis2 and
synapse. The idea of an axis2 transport is to use as an adapter
between axis2 and the actual transport (i.e http, smtp, JMS etc). In
fact Axis2 transport uses respective libraries for these
On Tue, Mar 31, 2009 at 12:22 AM, Asankha C. Perera asan...@apache.org wrote:
2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way the transports project would
only have the 'optional' transport modules and we wouldn't have to
release
Jarek Gawor wrote:
On Tue, Mar 31, 2009 at 12:22 AM, Asankha C. Perera asan...@apache.org wrote:
2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way the transports project would
only have the 'optional' transport modules and we
23 matches
Mail list logo
