[
https://issues.apache.org/jira/browse/AXIS2C-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Catalina Caloian updated AXIS2C-1289:
-
Attachment: XLocate.wsdl
The wsdl file used for code generation.
> Incorrect deserializ
[
https://issues.apache.org/jira/browse/AXIS2C-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Catalina Caloian updated AXIS2C-1289:
-
Attachment: CADBBeanTemplateSource.xsl
The CADBBeanTemplateSource.xsl used for code gene
Incorrect deserialization when the first child is an empty element
--
Key: AXIS2C-1289
URL: https://issues.apache.org/jira/browse/AXIS2C-1289
Project: Axis2-C
Issue Type: Bug
Hello,
In the generated code in axis2_stub_..., the axis2_char_t* type arguments used
for axsi2_stub_create_... are defined non-const, while they're only used const
(and the nature of the parameters just screams for const). This leads to
unnecessary const_casts in code using these functions. W
When sending a message through AMQP doesn't the client know it is
sending through AMQP ?
It does.
If client knows it ideally it should pass some thing to addressing
handlers to modify the reply to header.
Is it a good thing to let the client programmer intervene with low-level
stuff?
>
>> Well my concern is if we really want to let the client programmer
> manipulate the separate listener in dual-channel case.
>
> Ideally what the client programmer should do is just call *
>
> axis2_options_set_use_separate_listener(options, env, AXIS2_TRUE);*
>
> Don't you think so?
>
Yes I a
On Fri, Nov 14, 2008 at 10:43 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-11-14 at 09:38 +0530, Danushka Menikkumbura wrote:
> > > If you want to modify the replyTo at the transport level, for me it
> > > indicates something is wrong some where. Can you please explain your
> > >
Supun,
When the destination is generated by sender, does the sender block
waiting for the remote broker to generating the destination? If that
is the case we can still move this destination generating logic to the
receiver and make the sender block waiting for receiver until it
generates the d
On Fri, 2008-11-14 at 09:38 +0530, Danushka Menikkumbura wrote:
> > If you want to modify the replyTo at the transport level, for me it
> > indicates something is wrong some where. Can you please explain your
> > requirement in more detail?
> Supun,
>
> In the AMQP transport, the destination qu
When the destination is generated by sender, does the sender block waiting
for the remote broker to generating the destination? If that is the case we
can still move this destination generating logic to the receiver and make
the sender block waiting for receiver until it generates the destination.
Is it possible for your receiver to generate the destination and then
sender to pick the destination from there?
Since the transport works with a remote broker, this is not a viable
option. Because it is not guaranteed that the listener is done with
creating the destination by the time the sen
I'm assuming you are starting a receiver (for receiving the message with the
replyTo). In the client side we start the receiver first. Is it possible for
your receiver to generate the destination and then sender to pick the
destination from there? Also we have a method in receiver to retrieve the
r
If you want to modify the replyTo at the transport level, for me it
indicates something is wrong some where. Can you please explain your
requirement in more detail?
Supun,
In the AMQP transport, the destination queues are generated at the
transport level. So the ReplyTo destination is unknow
You can change the replyTo by traversing the SOAP om_tree, before
serializing in the transport. But explain your requirement more so we
may be able to identify an alternative.
On Fri, 2008-11-14 at 08:55 +0500, Supun Kamburugamuva wrote:
> Hi,
>
> If you want to modify the replyTo at the transpo
Hi,
If you want to modify the replyTo at the transport level, for me it
indicates something is wrong some where. Can you please explain your
requirement in more detail?
Thanks,
Supun.
On Fri, Nov 14, 2008 at 8:43 AM, Danushka Menikkumbura <[EMAIL PROTECTED]>wrote:
> Devs,
>
> I need to modify W
Devs,
I need to modify WS-A ReplyTo with a piece of data that is available
just before sending the message out at the transport level. As far as I
can see, the only way to do this is to process the serialized SOAP
envelop at the transport level, as the SOAP envelop is built already
when the t
[
https://issues.apache.org/jira/browse/AXISCPP-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra updated AXISCPP-729:
---
Issue Type: Improvement (was: Bug)
> Trace: Unwind the call stack when exceptions are thrown
>
[
https://issues.apache.org/jira/browse/AXISCPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra updated AXISCPP-645:
---
Description: The AxisTrace class should be enhanced to dump data in
hexadecimal mode given a chunk o
[
https://issues.apache.org/jira/browse/AXISCPP-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra closed AXISCPP-422.
--
Resolution: Fixed
Resolved by AXISCPP-100
> Trace calls to wrappers and handlers
> --
[
https://issues.apache.org/jira/browse/AXISCPP-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra closed AXISCPP-424.
--
Resolution: Fixed
Fix Version/s: current (nightly)
Resolved by AXISCPP-100
> Throw trace
> ---
[
https://issues.apache.org/jira/browse/AXISCPP-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra closed AXISCPP-643.
--
Resolution: Fixed
Fix Version/s: current (nightly)
Resolved by AXISCPP-100
> Trace the SOAP re
[
https://issues.apache.org/jira/browse/AXISCPP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647434#action_12647434
]
nadiramra edited comment on AXISCPP-100 at 11/13/08 2:52 PM:
--
[
https://issues.apache.org/jira/browse/AXISCPP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra closed AXISCPP-100.
--
Resolution: Fixed
Fix Version/s: current (nightly)
OK, finally got this done. Tracing is now i
Hi Catalina,
Looks like there is a bug. It happens that if parent types only contains
attributes, the code that you mentioned is necessary,
current_node = first_node;
is_early_node_valid = AXIS2_FALSE;
is never executed.
Please raise a JIRA reporting this issue. I attached a patch (taken
In all generated files, the AXIS2_CALL is used as calling convention (_stdcall
under windows). But in the generated axis2_stub_ flies, this calling
convention is not used. This is giving problems in my project, where the
generated code is used in a DLL (and some methods are marked for expor
25 matches
Mail list logo
