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 at 12:03 PM, Francesco Chicchiriccò < ilgro...@apache.org> wrote: > 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 to encapsulate all of this functionality, and then just refer to >> it in the Spring DSL. Something like "<to uri="propagate:create?...>", >> "<to >> uri="propagate:update?...>" etc. Are you thinking alone these lines or >> something else? >> > > Hi Colm, > considering my (very limited) understanding of Camel, I would have > expected exactly something like this. > > How difficult would it be to implement? > > Regards. > > > On Mon, Jul 18, 2016 at 1:39 PM, Giacomo Lamonaco < >> giacomo.lamon...@tirasa.net> wrote: >> >> 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 other DSLs (equivalent to Spring DSL of course). >>> >>> Best Regards, >>> Giacomo >>> >>> Il giorno ven, 15/07/2016 alle 18.16 +0200, Francesco Chicchiriccò ha >>> scritto: >>> >>>> 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 the end of the route, >>>> some >>>> 'processor' is invoked (as [2] for example, when user is created). >>>> >>>> As you might see from [2] and all similar classes in that package, >>>> there >>>> is still some relevant logic implemented in Java, which might be >>>> moved >>>> back to the route definition, hence increasing the general benefits >>>> of >>>> the whole concept of Camel-based provisioning. >>>> >>>> Do you also see this as an enhancement? Do you think it is possible >>>> / >>>> feasible to implement with limited effort? >>>> >>>> Regards. >>>> >>>> [1] >>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning- >>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/CamelU >>>> serProvisioningManager.java >>>> [2] >>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning- >>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces >>>> sor/UserCreateProcessor.java >>>> >>> > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Involved at The Apache Software Foundation: > member, Syncope PMC chair, Cocoon PMC, Olingo PMC, > CXF Committer, OpenJPA Committer, PonyMail PPMC > http://home.apache.org/~ilgrosso/ > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
