syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: [DISCUSS] Improving Camel-based provisioning
Date Fri, 29 Jul 2016 14:46:52 GMT
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 like:
>
> <to uri="propagate:<propagateType>?anyType=<anyType>&options"/>

This consolidation overall is extremely interesting, thanks for taking 
this forward.

> PropagateType is one of the following: create, update, delete, provision,
> deprovision, status, suspend, confirmPasswordReset
> AnyType is one of: user, group, any

As already noticed via IRC,

org.apache.syncope.core.provisioning.camel.AnyType

looks pretty much the same as

org.apache.syncope.common.lib.types.AnyTypeKind

so I'd suggest to remove the former and to use the latter instead, 
possibly changing

<to uri="propagate:<propagateType>?anyType=<anyType>&options"/>

to

<to uri="propagate:<propagateType>?anyTypeKind=<anyTypeKind>&options"/>

e.g. the parameter name as well, since "anyType" has a different meaning 
(can be PRINTER, SERVICE, whatever you might want to define on your 
Syncope deployment).

> 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?

Not sure, but the Java Provisioning Manager counterpart is

https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/DefaultUserProvisioningManager.java#L159-L178

e.g. a branch in the user update, which anyway proceeds with propagation 
in the lines afterwards.

Regards.

> 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/



Mime
View raw message