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:
<to uri="propagate:<propagateType>?anyType=<anyType>&options"/> PropagateType is one of the following: create, update, delete, provision, deprovision, status, suspend, confirmPasswordReset AnyType is one of: user, group, any The only "option" that's currently supported is "pull" which if true supports some of the functionality that was available in the processors, e.g. user update + pull. So for example: <to uri="propagate:update?anyType=user&pull=true"/> Thoughts? Criticisms? One thing I was a bit unsure of is the "pull" functionality in the StatusProducer. It doesn't follow the other patterns in terms of the PropagationManager + TaskExecutor, but instead uses the UserWorkflowAdapter. Should this functionality be put somewhere else I wonder? Colm. On Wed, Jul 27, 2016 at 8:21 AM, Francesco Chicchiriccò <ilgro...@apache.org > wrote: > Hi Colm, > > I guess the routes look a bit nicer as well as we're calling the same >> component rather than individual processors etc. >> > > Definitely, +1 > > 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"/> >> > > That's nice improvement as well. > > Thanks: are you going to open an improvement on JIRA for your work? > Regards. > > > 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
