Hello all,
In our use case we are looking to use a Recipient List which creates
branches dynamically and keep track of that. We were able to write an
implementation without too many problems and we are afraid there might be
hidden problems. Our tests were unable to identify any.
We have:
- an interface DynamicProcessorCollection with a single method
Processor findOrBuild(Exchange echange)
- A RichDynamicRouter processor which uses the
DynamicProcessorCollection
- A RichDynamicRouterDefinition which extends the ChoiceProcessor
overriding its createProcessor method so that it creates RichDynamicRouter
. A DynamicProcessorCollectionBuilder provided at constructor is used to
build the DynamicProcessorCollection from the WhenClauses and the
RouteContext.
This all works pretty well. In our skeleton implementation of
DynamicProcessorCollection, called AbstractDynamicProcessorCollection, the
DynamicProcessorCollection interface is implemented as follows:
- If the relevant processor is found, return it
- If it is not found
o Create a ProcessorDefinition
o Modify the route by appending a WhenClause to the
RichDynamicRouterDefinition at its output
o Create the processor from the definition
o If the processor is a service, call the lifecycleStrategy.onServiceAdd
to all the childServices of processor
In order to have the new created processors correctly wrapped in an
InstrumentationProcessor and exposed to JMX by a LifeCycleStrategy, we had
to create our own InterceptStrategy and LifeCycleStrategy. We encountered
the limitations on DefaultManagementLifecycleStrategy : in practice it was
difficult to extend because of private members and private methods. In
particular:
o We had to re-implement the onServiceAdd to work around the fact that
the getManagedObjectForProcessor is private, since the latter access
private properties too.
We have the following questions:
- Are we going to hit some problems with the threading model of
Camel by modifying the route definition during the route execution? Is
there anything we have totally missed?
- Would you accept pull requests that generify the
DefaultManagementLifecycleStrategy and makes it easier to extend it?
- In our InterceptStrategy we are using the route description to
determine if we should wrap our processor or not. Is there a better way?
Thank you for your help
Edmondo
In our use case we are looking to use a Recipient List which creates
branches dynamically and keep track of that. We were able to write an
implementation without too many problems and we are afraid there might be
hidden problems. Our tests were unable to identify any.
We have:
- an interface DynamicProcessorCollection with a single method
Processor findOrBuild(Exchange echange)
- A RichDynamicRouter processor which uses the
DynamicProcessorCollection
- A RichDynamicRouterDefinition which extends the ChoiceProcessor
overriding its createProcessor method so that it creates RichDynamicRouter
. A DynamicProcessorCollectionBuilder provided at constructor is used to
build the DynamicProcessorCollection from the WhenClauses and the
RouteContext.
This all works pretty well. In our skeleton implementation of
DynamicProcessorCollection, called AbstractDynamicProcessorCollection, the
DynamicProcessorCollection interface is implemented as follows:
- If the relevant processor is found, return it
- If it is not found
o Create a ProcessorDefinition
o Modify the route by appending a WhenClause to the
RichDynamicRouterDefinition at its output
o Create the processor from the definition
o If the processor is a service, call the lifecycleStrategy.onServiceAdd
to all the childServices of processor
In order to have the new created processors correctly wrapped in an
InstrumentationProcessor and exposed to JMX by a LifeCycleStrategy, we had
to create our own InterceptStrategy and LifeCycleStrategy. We encountered
the limitations on DefaultManagementLifecycleStrategy : in practice it was
difficult to extend because of private members and private methods. In
particular:
o We had to re-implement the onServiceAdd to work around the fact that
the getManagedObjectForProcessor is private, since the latter access
private properties too.
We have the following questions:
- Are we going to hit some problems with the threading model of
Camel by modifying the route definition during the route execution? Is
there anything we have totally missed?
- Would you accept pull requests that generify the
DefaultManagementLifecycleStrategy and makes it easier to extend it?
- In our InterceptStrategy we are using the route description to
determine if we should wrap our processor or not. Is there a better way?
Thank you for your help
Edmondo