syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: [DISCUSS] Improving Camel-based provisioning
Date Fri, 29 Jul 2016 14:30:48 GMT
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&amp;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ò <ilgrosso@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 <coheigea@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ò <
>>> ilgrosso@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ò <
>>>>> ilgrosso@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ò <
>>>>>>>
>>>>>>> ilgrosso@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.lamonaco@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message