You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2016/07/15 16:16:16 UTC
[DISCUSS] Improving Camel-based provisioning
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
--
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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Giacomo Lamonaco <gi...@tirasa.net>.
Hi Colm,
I'd propose to start: I'm really happy to assist you during
implementation. On this way I can improve my understanding of camel :)
Giacomo
Il giorno mer, 20/07/2016 alle 12.17 +0100, Colm O hEigeartaigh ha
scritto:
> Hi Francesco,
>
> It should be fairly straightforward I'd say. Is there reasonable test
> coverage of the camel routes in the build?
>
> 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?
>
> Colm.
>
> 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/provi
> > > > > sioning-
> > > > > camel/src/main/java/org/apache/syncope/core/provisioning/came
> > > > > l/CamelU
> > > > > serProvisioningManager.java
> > > > > [2]
> > > > > https://github.com/apache/syncope/blob/master/ext/camel/provi
> > > > > sioning-
> > > > > camel/src/main/java/org/apache/syncope/core/provisioning/came
> > > > > l/proces
> > > > > sor/UserCreateProcessor.java
> > > > >
> > --
> > 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/
> >
> >
>
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Francesco Chicchiriccò <il...@apache.org>.
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&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ò <il...@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 <co...@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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Colm O hEigeartaigh <co...@apache.org>.
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ò <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 <co...@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
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Francesco Chicchiriccò <il...@apache.org>.
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 <co...@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� <il...@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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Colm O hEigeartaigh <co...@apache.org>.
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"/>
Colm.
On Tue, Jul 26, 2016 at 5:35 PM, Colm O hEigeartaigh <co...@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
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Colm O hEigeartaigh <co...@apache.org>.
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
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Francesco Chicchiriccò <il...@apache.org>.
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� <il...@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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Colm O hEigeartaigh <co...@apache.org>.
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/CamelU
>>>>>>>
>>>>>>> serProvisioningManager.java
>>>>>>> [2]
>>>>>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
>>>>>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
>>>>>>>
>>>>>>> sor/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
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Francesco Chicchiriccò <il...@apache.org>.
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�
>> <il...@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/CamelU
>>>>>>
>>>>>> serProvisioningManager.java
>>>>>> [2]
>>>>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
>>>>>>
>>>>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
>>>>>>
>>>>>> sor/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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Francesco Chicchiriccò <il...@apache.org>.
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� <il...@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/CamelU
>>>>> serProvisioningManager.java
>>>>> [2]
>>>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
>>>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
>>>>> sor/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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
It should be fairly straightforward I'd say. Is there reasonable test
coverage of the camel routes in the build?
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?
Colm.
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/CamelU
>>>> serProvisioningManager.java
>>>> [2]
>>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
>>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
>>>> sor/UserCreateProcessor.java
>>>>
>>>
> --
> 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
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Francesco Chicchiriccò <il...@apache.org>.
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 <gi...@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/CamelU
>>> serProvisioningManager.java
>>> [2]
>>> https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
>>> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
>>> sor/UserCreateProcessor.java
--
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/
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Colm O hEigeartaigh <co...@apache.org>.
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?
Colm.
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/CamelU
> > serProvisioningManager.java
> > [2]
> > https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
> > camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
> > sor/UserCreateProcessor.java
> >
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] Improving Camel-based provisioning
Posted by Giacomo Lamonaco <gi...@tirasa.net>.
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/CamelU
> serProvisioningManager.java
> [2]
> https://github.com/apache/syncope/blob/master/ext/camel/provisioning-
> camel/src/main/java/org/apache/syncope/core/provisioning/camel/proces
> sor/UserCreateProcessor.java
>