I found another way which I think is cleaner. I've added a single
Container interface with a singleton which is called back whenever a
CamelContext is created. The implementation can then add a
LifecycleListener or register any other SPI object.
See
Hi Guillaume,
indeed, it looks cleaner. Let me take a deeper look on the code but it
sounds good.
Regards
JB
On 07/28/2011 10:14 AM, Guillaume Nodet wrote:
I found another way which I think is cleaner. I've added a single
Container interface with a singleton which is called back whenever a
How about offering the camelContext as an OSGi service? This way
servicemix can use the whiteboard pattern to watch for camel contexts
and register with them.
Christian
Am 28.07.2011 10:14, schrieb Guillaume Nodet:
I found another way which I think is cleaner. I've added a single
Container
Hi Christian,
It's already the case. CamelContext are exposed as OSGi services. It's
used in Camel commands to list it, etc.
The whiteboard could work but it depends what we want to achieve.
Regards
JB
On 07/28/2011 10:36 AM, Christian Schneider wrote:
How about offering the camelContext as
It's already the case and it does not fulfill my need for multiple reasons:
* when the service is registered, it's way too late to change
anything, I need real low level interception
* only contexts created by blueprint or spring are registered, not
those create with a java / scala / groovy
+1
One of the features we are missing in SMX 4.x...
Best,
Christian
On Fri, Jul 22, 2011 at 7:07 AM, Jean-Baptiste Onofré j...@nanthrax.netwrote:
+1
It's a must have for new SMX :)
Regards
JB
On 07/21/2011 11:22 AM, Guillaume Nodet wrote:
For ServiceMix, we are in need for having
+1
On Jul 24, 2011, at 12:01, Christian Müller christian.muel...@gmail.com wrote:
+1
One of the features we are missing in SMX 4.x...
Best,
Christian
On Fri, Jul 22, 2011 at 7:07 AM, Jean-Baptiste Onofré
j...@nanthrax.netwrote:
+1
It's a must have for new SMX :)
Regards
For ServiceMix, we are in need for having *global* interceptors, i.e.
some kind of static list of interceptors and other strategies. The
main use case is that users would deploy plain camel routes and
ServiceMix would kick in and configure its interceptors but without
any need for the user to
The interceptors story in camel needs revisiting anyway.
Hadrian
On Jul 21, 2011, at 5:22 AM, Guillaume Nodet wrote:
For ServiceMix, we are in need for having *global* interceptors, i.e.
some kind of static list of interceptors and other strategies. The
main use case is that users would
+1
Totally agree. This is a functionality that I've implemented a number of times
and is great for creating audit trails, and replay.
On Jul 21, 2011, at 4:22 AM, Guillaume Nodet wrote:
For ServiceMix, we are in need for having *global* interceptors, i.e.
some kind of static list of
+1
It's a must have for new SMX :)
Regards
JB
On 07/21/2011 11:22 AM, Guillaume Nodet wrote:
For ServiceMix, we are in need for having *global* interceptors, i.e.
some kind of static list of interceptors and other strategies. The
main use case is that users would deploy plain camel routes
11 matches
Mail list logo
