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 Wed, 27 Jul 2016 07:21:31 GMT
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