L.S.,
Guillaume Nodet wrote:
Looks good, but I'm not sure how feasible it is. I mean, writing such
a component for camel should be quite easy.
OK, I'll raise a JIRA for it then. Even if we are not going to use it
for this scenario, I think it would be great to be able to deploy an
EndpointListener together with a SA.
The main problem is the
slight mismatch between the messaging apis from camel and servicemix.
Mainly around attachments and a few other things.
In all cases, it would be nice if the APIs are closer to each other.
Is there an overview somewhere of the differences? I suppose we will
probably have to work on this as soon as possible anyway if we are going
to see our current JBI components interact with Camel even more in SMX4
For debugging and diagnosing problems, we don't really want to loose
some data in the conversion imho.
No, we don't, but couldn't we use Camel to pass along the original
MessageExchange object, wrapped in a Camel Exchange to enable the use of
the existing filter predicates?
Gert
On Tue, Mar 11, 2008 at 2:11 PM, Gert Vanthienen (JIRA) <[EMAIL PROTECTED]>
wrote:
[
https://issues.apache.org/activemq/browse/SMX4NMR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41652#action_41652
]
gertvanthienen edited comment on SMX4NMR-21 at 3/11/08 6:09 AM:
-----------------------------------------------------------------
We should definitely look into using the Camel predicates. This is a great
way to reuse what is already there. Especially for the scripting language
predicate, this should be rather straighforward, I guess. It would just be a
matter of adding an ExchangeListener and passing in the script predicate as a
String to create a Camel route that could do the the auditing (perhaps even
re-using the new list: endpoints).
How about adding a new JBI endpoint to Camel to support this? Something like
{code}
from("jbi:exchangeListener:...").filter("my
expresssion").to("list:auditedMessages");
{code}
was (Author: gertvanthienen):
We should definitely look into using the Camel predicates. This is a great
way to reuse what is already there. Especially for the scripting language
predicate, this should be rather straighforward, I guess. It would just be a
matter of adding an ExchangeListener and passing in the script predicate as a
String to create a Camel route that could do the the auditing (perhaps even
re-using the new list: endpoints).
How about adding a new JBI endpoint to Camel to support this? Something like
from("jbi:exchangeListener:...").filter("my
expresssion").to("list:auditedMessages")
> Debugging flows
> ---------------
>
> Key: SMX4NMR-21
> URL: https://issues.apache.org/activemq/browse/SMX4NMR-21
> Project: ServiceMix NMR
> Issue Type: New Feature
> Reporter: Guillaume Nodet
>
> Create a set of console commands / OSGi service / NMR listeners to be able
to:
> * add / remove / disable breakpoints (with conditional evaluation on
exchanges)
> * list paused exchanges
> * inspect / modify a paused exchange
> * resume execution for a exchange
> A breakpoint is basically a condition that filters an exchange. If the
filter match, the breakpoint is activated and the flow for the given exchange is
paused. Simple breakpoints include:
> * exchanges originated from a given endpoint
> * exchanges targeted at a given endpoint
> * exchanges in an ERROR status
> * ...
> Using an ExchangeListener, it should be easy to intercept all the exchanges.
I think the problem is that currently, the only way is to suspend the calling
thread and wait for a signal that would be set by a command when resuming an
exchange. This is not really scalable. Maybe using a flow is a better option,
but I think it would be more intrusive, so that entering / exiting debug mode may
not be easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
