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 Tue, 26 Jul 2016 10:54:09 GMT
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