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ò <ilgro...@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 <cohei...@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ò <
ilgro...@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ò <
ilgro...@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ò <
ilgro...@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.lamon...@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/
