Actually I think I can have just a single implementation per user/group/etc, just by checking to see what the type of the Object stored on the exchange is, so something like the following would work for user/group/any etc.:
<to uri="propagate:create"/> Colm. On Tue, Jul 26, 2016 at 5:35 PM, Colm O hEigeartaigh <cohei...@apache.org> wrote: > 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: > > <to uri="userPropagate:create"/> > <to uri="groupPropagate:create"/> > > Or I could have a single component that does something like: > > <to uri="propagate:create?object=user"/> > <to uri="propagate:create?object=group"/> > > etc. WDYT? > > BTW I'm not sure that this change is really buying us much improvement, as > the java logic looks more or less the same, from what I've done so far. I > guess one improvement is that we do away with all of the @Component Camel > Processor implementations (instead replacing them with Camel > DefaultProducer implementations that are controlled by the component). I > guess the routes look a bit nicer as well as we're calling the same > component rather than individual processors etc. > > Colm. > > On Tue, Jul 26, 2016 at 11:54 AM, Francesco Chicchiriccò < > ilgro...@apache.org> wrote: > >> 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 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ò < >>> ilgro...@apache.org>wrote: >>> >>> Hi Colm, >>>> as it seems that Giacomo as well is happy if you can take this task, can >>>> you please describe how are you going to work on it? Dedicated feature >>>> branch? Or you expect to be simple enough to stay in a single commit? >>>> >>>> Thanks! >>>> Regards. >>>> >>>> >>>> On 20/07/2016 13:45, Francesco Chicchiriccò wrote: >>>> >>>> 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 integration test suite is >>>>> run >>>>> with Camel routes by default. >>>>> >>>>> 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? >>>>>> >>>>>> This sounds great to me, and I would also say that there is no >>>>> particular >>>>> rush to finish before releasing 2.0.0: such an improvement can also >>>>> come >>>>> afterwards (2.0.1, 2.0.2, ...). >>>>> >>>>> Regards. >>>>> >>>>> 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/CamelUserProvisioningManager.java >>>>>>>>>> [2] >>>>>>>>>> >>>>>>>>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning- >>>>>>>>>> >>>>>>>>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/processor/UserCreateProcessor.java >>>>>>>>>> >>>>>>>>> [3] >>>>>>>>> https://github.com/apache/syncope/blob/master/fit/core-reference/pom.xml#L963 >>>>>>>>> >>>>>>>> >> -- >> 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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
