Thanks but no I haven't - sorry I forgot to mention I am using SM 3.3, so as
far as I read, it only supports JBI packaging. Therefore I registered the
listener just as a bean in the config/servicemix.xml.

Since this listener class of mine is loaded at startup, there should
probably be something more I have to do to specify to SM that all messages
should be taken to the listener. I prefer this listener not to have an
endpoint because it would mean that the outside world should know this
endpoint (and I don't want that).


Thanks,
G.

-----Original Message-----
From: Guillaume Nodet [mailto:[email protected]] 
Sent: Monday, March 09, 2009 8:05 PM
To: [email protected]
Subject: Re: altering routing within the NMR

Did you register the listener as an OSGi service ?

    <osgi:service ref="myListener">
        <osgi:interfaces>
            <value>org.apache.servicemix.nmr.api.event.Listener</value>

<value>org.apache.servicemix.nmr.api.event.ExchangeListener</value>
        </osgi:interfaces>
    </osgi:service>


On Mon, Mar 9, 2009 at 18:59, Gabriela Gheorghe <
[email protected]> wrote:

> Hi again,
>
> I am having some small problem with the listener you guys told me how to
> build. I implemented a class that implements an ExchangeListener with some
> simple printlines (in console or in a file) in the exchangeSent /
> exchangeAccepted methods.
>
> I followed these instructions in a previous post
> (http://markmail.org/message/luxmyb7gtj2e2ows):
> 1) Implement the ExchangeListener interface
> 2) Package it as a JAR file and drop it in the ServiceMix lib/ dir
> 3) Use Spring bean syntax to register your ExchangeLIstener implementation
> in the conf/servicemix.xml file outside of any ServiceMix-specific
elements
> (e.g., <bean id="foo"
> class="com.mycompany.listener.MyCustomExchangeListener" />)
>
> The problem is that ... nothing happens. When I test some of the tutorials
> -
> that I believe they are all using the NMR at some point - no file, no
> output
> in the log of ServiceMix nor in its console.
>
> ServiceMix does not crash and the log is clean - so it finds my listener
> class, but is very silent. Am I missing something or it's just that I am
> not
> looking where I am supposed to look for some output?
>
> Thanks,
> G.
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:[email protected]]
> Sent: Thursday, February 05, 2009 8:11 PM
> To: [email protected]
> Subject: Re: altering routing within the NMR
>
> When intercepting the exchange, you can either:
>  * process it and let the routing unchanged
>  * re-route it to another endpoint
>
> If you choose the later (that's what the code I gave do), the exchange
> will not be between A and B, but between A and C.  C needs then to
> create a new exchange and send it to B, so you end up with A -> C ->
> B.  Of course, you should not intercept the exchange C -> B, else, you
> would loop.  However, the test in the implemenation I gave take care
> of intercepting only *new* exchanges: those that are active, have a
> consumer role and have an In message, without any out or faults.
>
> If you choose the former, you need to process the exchange
> synchronously: when the call to exchangeSent() returns, the exchange
> will be delivered to the target endpoint (B if the routing has not
> changed) immediately.
>
> If the processing is simple (modifying the content / properties), go
> with the simple way.  In my case, I was in need for rerouting the
> exchange to go through a JMS layer between A and B endpoints.
>
> Hopes this help.
>
> On Thu, Feb 5, 2009 at 17:21, Gabriela Gheorghe
> <[email protected]> wrote:
> > Thanks for the hints, Guillaume and Gert!
> >
> > The code seems pretty straightforward (apart from the createMap call).
> >
> > The observation is that leaving the source and destination endpoints
> > untouched, might cause a loop.
> >
> > Here's why: A sends a ME for B, the NMR intercepts the ME and forwards
it
> to
> > C; C performs some modifications on the ME but does not tamper with the
> > source and destination endpoints (otherwise the ME would not work as it
> > should and the mechanism would no longer be transparent for A and B) and
> > then it sends the same ME to the router. The router is supposed to send
> the
> > ME to B. But the router will intercept it again via this same mechanism,
> > because the ME would have the same source and destination.
> >
> > Where am I missing something? There should be a way to tell apart the
> > initial ME and the modified one - can it be done via the property
object,
> > without generating too much overhead?
> >
> > Cheers,
> > Gabriela
> >
> > -----Original Message-----
> > From: Guillaume Nodet [mailto:[email protected]]
> > Sent: Thursday, February 05, 2009 3:09 PM
> > To: [email protected]
> > Subject: Re: altering routing within the NMR
> >
> > As Gert said, we haven't any generic solution for servicemix 4, though
> > I was in need for that for the clustering stuff.
> > The idea is to use an ExchangeListener and intercept new exchanges.
> > Here is the code I have so far:
> >
> >    public void exchangeSent(Exchange exchange) {
> >        // Intercept exchanges
> >        if (exchange instanceof InternalExchange
> >                && exchange.getStatus() == Status.Active &&
> > exchange.getRole() == Role.Consumer
> >                && exchange.getOut(false) == null &&
> > exchange.getFault(false) == null) {
> >            // Filter JBI endpoints
> >            InternalEndpoint source = ((InternalExchange)
> > exchange).getSource();
> >            for (ClusterRegistration reg : getServices()) {
> >                if (reg.match(source)) {
> >
> >
>
>
exchange.setTarget(getChannel().getNMR().getEndpointRegistry().lookup(Servic
> > eHelper.createMap(Endpoint.NAME,
> > name)));
> >                    return;
> >                }
> >            }
> >        }
> >    }
> >
> > As you can see, the exchange is routed and the target overwritten.
> > This will re-route the exchange to a known endpoint.
> > In this case, the old target is discarded and will be recreated by the
> > endpoint itself, because we still have the JBI addressing properties
> > available.   Another way would be to save the old target into a
> > property on the exchange that would be later used by the endpoint.
> >
> > On Thu, Feb 5, 2009 at 11:59, Gabriela Gheorghe
> > <[email protected]> wrote:
> >> Hi,
> >>
> >>
> >>
> >> I need to do a bit of tuning inside the NMR so that messages sent to
and
> >> from the SAs could be transparently sent to a certain configurable
> > endpoint
> >> prior to taking their actual route. This of course without having to
> > change
> >> the routes already associated with the deployed components.
> >>
> >>
> >>
> >> Could you please tell me what I should do/use in this case?
> >>
> >>
> >>
> >> Thanks in advance,
> >>
> >> Gabriela
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com


Reply via email to