Re: [DISCUSS] Improving Camel-based provisioning

On 29/07/2016 16:30, Colm O hEigeartaigh wrote: Ok I've committed the initial change to use the new Camel component and would welcome some feedback. Instead of referencing random Camel Processors in the routes, we now have a single component called "propagate". All of the routes call something

Re: [DISCUSS] Improving Camel-based provisioning

Ok I've committed the initial change to use the new Camel component and would welcome some feedback. Instead of referencing random Camel Processors in the routes, we now have a single component called "propagate". All of the routes call something like: PropagateType is one of the following:

Re: [DISCUSS] Improving Camel-based provisioning

Thanks Francesco! I did a quick POC for the user create route + got it working locally. Any thoughts on what the route should look like? I could create a separate component for each of the user/groups/any etc., so the route would look something like: Or I could have a single component that

Re: [DISCUSS] Improving Camel-based provisioning

Hi, FYI I have just committed https://git1-us-west.apache.org/repos/asf?p=syncope.git;a=commit;h=945be877 a modification that should be simplifying the usage PropagationTaskExecutor / PropagationReporter Regards. On 22/07/2016 13:45, Colm O hEigeartaigh wrote: Hi Francesco, I think a

Re: [DISCUSS] Improving Camel-based provisioning

Hi Francesco, I think a dedicated feature branch will not be necessary. I'll probably do it over a few commits, maybe do an operation at a time so as not to break the tests. Colm. On Fri, Jul 22, 2016 at 7:59 AM, Francesco Chicchiriccò wrote: > Hi Colm, > as it seems

Re: [DISCUSS] Improving Camel-based provisioning

Hi Colm, I'd propose to start: I'm really happy to assist you during implementation. On this way I can improve my understanding of camel :) Giacomo Il giorno mer, 20/07/2016 alle 12.17 +0100, Colm O hEigeartaigh ha scritto: > Hi Francesco, > > It should be fairly straightforward I'd say. Is

Re: [DISCUSS] Improving Camel-based provisioning

On 20/07/2016 13:17, Colm O hEigeartaigh wrote: Hi Francesco, It should be fairly straightforward I'd say. Is there reasonable test coverage of the camel routes in the build? As you can see from [3] the "all" profile (featuring Activiti, Camel and Swagger) is active by default, so the whole

Re: [DISCUSS] Improving Camel-based provisioning

Hi Francesco, It should be fairly straightforward I'd say. Is there reasonable test coverage of the camel routes in the build? I'd like to volunteer to take it on, given that I plan on talking about Syncope + Camel, unless you or Giacomo would like to implement it? Colm. On Wed, Jul 20, 2016

Re: [DISCUSS] Improving Camel-based provisioning

On 19/07/2016 17:46, Colm O hEigeartaigh wrote: Hi Francesco, How do you envisage this change would be made? The Processors in question pretty much all call the PropagationManager to create some tasks and then execute them using the PropagationTaskExecutor. We could create a new Camel component

Re: [DISCUSS] Improving Camel-based provisioning

Hi Francesco, How do you envisage this change would be made? The Processors in question pretty much all call the PropagationManager to create some tasks and then execute them using the PropagationTaskExecutor. We could create a new Camel component to encapsulate all of this functionality, and

Re: [DISCUSS] Improving Camel-based provisioning

Hi Francesco, I think it would be great! Currently camel routes are defined using  Spring DSL: as you can image we need to understand if the logic you described can be expressed using that DSL. IMHO that's not a difficult task and it would be great to develop a POC. Otherwise we can investigate

[DISCUSS] Improving Camel-based provisioning

Hi all, as you know, Camel-based provisioning is one of the coolest features among the several cool features in 2.0. The implementation is essentially done this way: each method in CamelUserProvisioningManager [1] (and similarly for groups and any objects) invokes some Camel route, then at