You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Peter Klotz <pe...@blue-elephant-systems.com> on 2006/04/28 20:27:22 UTC
servicemix-eip message-filter
Just detected the new message-filter pattern in servicemix-eip,
it seems it only works with InOnly-MEP, why?
IMHO, would also make sense in InOut-MEP or?
<html>
<head>
<title>Error 500 Use an InOnly or RobustInOnly MEP</title>
</head>
<body>
<h2>HTTP ERROR: 500</h2><pre>Use an InOnly or RobustInOnly MEP</pre>
<p>RequestURI=/</p>
<p><i><small><a href="http://jetty.mortbay.org">Powered by
Jetty://</a></small></i></p>
Peter
Re: servicemix-eip message-filter
Posted by Guillaume Nodet <gn...@gmail.com>.
The MessageFilter main use is to drop messages a component is not
interested in, not to validate if a request is valid. You may need a
validator for that, that would check that the xml conforms to a given
and would return an error if not. Is that what you were thinking about
?
Cheers,
Guillaume Nodet
On 4/28/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
> Guillaume Nodet wrote:
> > Yes, i had considered that...
> > The problem is that with an In-Out mep, the consumer is waiting for a
> > response. What could we send ?
>
> If a request comes through then all is ok, if a request if filtered out one
> could throw an exception, which would roll back this message exchange?
>
>
>
> OK: Req --> Fil --> Req
> Resp <-- ter <-- Resp
>
> NOK: Req --> Fil
> Err <-- ter
>
>
> If the calling component is a endpoint e.g. HTTP then this would anyhow return
> some HTTP status code
>
> Maybe my view is too simplistic, not knowing the details of the implementation
> or even the JBI spec very good, but that would have been my expectation.
>
> Or why not make it configurable, if the property is true this behaviour,
> otherwise you return an error too as today that an inout is not allowed with
> this configuration. If you look at it from this side, you return a error now as
> well, so ...
>
> And apart from the pipeline this would otherwise be the only routing pattern
> that does not support InOut but would be very usefull if one would have it.
>
> Just my 5 cents,
>
> Peter
>
>
Re: servicemix-eip message-filter
Posted by Peter Klotz <pe...@blue-elephant-systems.com>.
Guillaume Nodet wrote:
> Yes, i had considered that...
> The problem is that with an In-Out mep, the consumer is waiting for a
> response. What could we send ?
If a request comes through then all is ok, if a request if filtered out one
could throw an exception, which would roll back this message exchange?
OK: Req --> Fil --> Req
Resp <-- ter <-- Resp
NOK: Req --> Fil
Err <-- ter
If the calling component is a endpoint e.g. HTTP then this would anyhow return
some HTTP status code
Maybe my view is too simplistic, not knowing the details of the implementation
or even the JBI spec very good, but that would have been my expectation.
Or why not make it configurable, if the property is true this behaviour,
otherwise you return an error too as today that an inout is not allowed with
this configuration. If you look at it from this side, you return a error now as
well, so ...
And apart from the pipeline this would otherwise be the only routing pattern
that does not support InOut but would be very usefull if one would have it.
Just my 5 cents,
Peter
Re: servicemix-eip message-filter
Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, i had considered that...
The problem is that with an In-Out mep, the consumer is waiting for a
response. What could we send ?
Cheers,
Guillaume Nodet
On 4/28/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
> Just detected the new message-filter pattern in servicemix-eip,
>
> it seems it only works with InOnly-MEP, why?
> IMHO, would also make sense in InOut-MEP or?
>
> <html>
> <head>
> <title>Error 500 Use an InOnly or RobustInOnly MEP</title>
> </head>
> <body>
> <h2>HTTP ERROR: 500</h2><pre>Use an InOnly or RobustInOnly MEP</pre>
> <p>RequestURI=/</p>
> <p><i><small><a href="http://jetty.mortbay.org">Powered by
> Jetty://</a></small></i></p>
>
>
> Peter
>
>
>