Hi Kasun,
On Tue, May 17, 2016 at 4:05 AM, Kasun Indrasiri wrote:
> Looks good.
>
> How do we handle the use cases in which we have multiple requests going
> out from ESB (i.e. such as service chaining scenario). In that case can we
> clearly identify and correlate wirelogs
Looks good.
How do we handle the use cases in which we have multiple requests going out
from ESB (i.e. such as service chaining scenario). In that case can we
clearly identify and correlate wirelogs with its respecting
requests/response?
On Tue, May 3, 2016 at 12:12 AM, Rajith Vitharana
Hi Kasun,
Implemented the scenario, now it works fine other than below limitations
* need to add a debug point in where ever we need to see wirelogs (for
example if we need to see wirelogs for some send mediator, we need to put a
debug point to that mediator)
* need to right click on the
@Rajith : Can you please update the progress on this?
On Mon, Apr 4, 2016 at 9:52 PM, Viraj Rajaguru wrote:
> Hi Rajith,
>
> With the current implementation, we can only see the wire logs from
> Developer Studio while debugging without any correlation with the mediator.
> This
Hi Rajith,
With the current implementation, we can only see the wire logs from
Developer Studio while debugging without any correlation with the mediator.
This might be acceptable when we have a simple message flow to debug with
one or two back-end calls etc. But it comes to scenarios with large
On Tue, Apr 5, 2016 at 9:59 AM, Kasun Indrasiri wrote:
> Yeah.. we might be not able to use the current wire-log implementation for
> do this but we need to find a way how we can pass the wire level message as
> part of the ctx.
>
Sure, we will look for some other way to do this.
Yeah.. we might be not able to use the current wire-log implementation for
do this but we need to find a way how we can pass the wire level message as
part of the ctx.
On Tue, Apr 5, 2016 at 9:30 AM, Isuru Udana wrote:
> Hi Kasun,
>
> TRANSPORT_HEADERS case is somewhat
Hi Kasun,
TRANSPORT_HEADERS case is somewhat different, because we have access to the
all the transport level headers from the HttpRequest coming from Http Core
level, but for the entire message we won't be able to take that approach.
Thanks.
On Tue, Apr 5, 2016 at 9:24 AM, Isuru Udana
Hi Kasun,
It is not possible to make it a part of the message context as we don't
have access to any context at the Wire level (Not even the http core level
context).
On Tue, Apr 5, 2016 at 9:11 AM, Kasun Indrasiri wrote:
> Can we have wire level message information as part of
I mean.. from transport layer to mediation layer, we need to pass the
relevant information for wire message. For instance, we are doing a similar
thing to pass the transport headers through the mediation with the use of a
map with 'TRANSPORT_HEADERS'. I guess we can do a similar thing to support
Can we have wire level message information as part of the message context
(Of course we have to do this only if debugging is enabled or something),
so that we can correlate message and its wire level message while
debugging.
On Fri, Apr 1, 2016 at 9:46 AM, Rajith Vitharana
Hi,
I was able to simply show the wire log (what is just written to the wire)
as a property when a debug point get hits, But in that case there are some
drawbacks, such as we can't see back end call wire logs because we can't
set debug point just after back end call happens, (we can see back end
Hi,
We came across a sort of a mandatory requirement for debugger : debugging wire
level message from the visual editor. We need to figure out how to
represent this visually + implement this at the core engine level (probably
propagate these transport level information to the mediation level).
13 matches
Mail list logo