[jira] [Commented] (SYNCOPE-910) Introduce new Camel propagation component

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399564#comment-15399564
 ] 

ASF subversion and git services commented on SYNCOPE-910:
-

Commit 575f02b4adc0cd868f13a328e195b68146f8d8d4 in syncope's branch 
refs/heads/master from [~coheigea]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=575f02b ]

SYNCOPE-910 - Switching to use AnyTypeKind as per Francesco's comments


> Introduce new Camel propagation component
> -
>
> Key: SYNCOPE-910
> URL: https://issues.apache.org/jira/browse/SYNCOPE-910
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 2.0.0
>
>
> This task is to introduce a new Camel propagation component, instead of 
> having Camel Processor instances handle each individual use-case. It'll make 
> the routes a bit more compact and easier to read.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] Improving Camel-based provisioning

[Francesco Chicchiriccò]

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:




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



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:



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ò  
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.:




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 

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:




Or I could have a single component that does something like:




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 

Re: [DISCUSS] Improving Camel-based provisioning

[Colm O hEigeartaigh]

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:



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:



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ò  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.:
>>
>> 
>>
>
> 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 
>> 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:
>>>
>>> 
>>> 
>>>
>>> Or I could have a single component that does something like:
>>>
>>> 
>>> 
>>>
>>> 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

[jira] [Commented] (SYNCOPE-910) Introduce new Camel propagation component

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399398#comment-15399398
 ] 

ASF subversion and git services commented on SYNCOPE-910:
-

Commit 891122c2f3d4ec814eff8df3154ba425ce172335 in syncope's branch 
refs/heads/master from [~coheigea]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=891122c ]

SYNCOPE-910 - Introduce new Camel propagation component - part II


> Introduce new Camel propagation component
> -
>
> Key: SYNCOPE-910
> URL: https://issues.apache.org/jira/browse/SYNCOPE-910
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 2.0.0
>
>
> This task is to introduce a new Camel propagation component, instead of 
> having Camel Processor instances handle each individual use-case. It'll make 
> the routes a bit more compact and easier to read.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SYNCOPE-700) Documentation artifacts

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399336#comment-15399336
 ] 

ASF subversion and git services commented on SYNCOPE-700:
-

Commit 550145f8ef979a69ecb2e6197fb4d3a727dcf388 in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=550145f ]

[SYNCOPE-700] Architecture: done


> Documentation artifacts
> ---
>
> Key: SYNCOPE-700
> URL: https://issues.apache.org/jira/browse/SYNCOPE-700
> Project: Syncope
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.0
>
>
> As [discussed|http://markmail.org/message/dpleneuzrfcsmq2r] in mailing list, 
> setup the {{asciidoctor-maven-plugin}} in order to generate, alongside with 
> the build, the project documentation in HTML and PDF.
> The generated documentation will then be part of release artifacts and always 
> up-to-date with current release.
> Preliminary results available at 
> http://syncope.apache.org/2.0.0-SNAPSHOT/docs/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SYNCOPE-912) Registered users receive an error message after saving their own profile

[Giacomo Lamonaco (JIRA)]

Giacomo Lamonaco created SYNCOPE-912:


 Summary: Registered users receive an error message after saving 
their own profile
 Key: SYNCOPE-912
 URL: https://issues.apache.org/jira/browse/SYNCOPE-912
 Project: Syncope
  Issue Type: Bug
  Components: enduser
Affects Versions: 2.0.0-M4
Reporter: Giacomo Lamonaco
 Fix For: 2.0.0


After submitting a new user profile, enduser tries to read again that profile - 
of course using user credentials. If workflow requires an approval process, 
users are not authorized to access to their profile.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SYNCOPE-911) Enduser should allow empty values on non required select fields

[Giacomo Lamonaco (JIRA)]

Giacomo Lamonaco created SYNCOPE-911:


 Summary: Enduser should allow empty values on non required select 
fields
 Key: SYNCOPE-911
 URL: https://issues.apache.org/jira/browse/SYNCOPE-911
 Project: Syncope
  Issue Type: Bug
  Components: enduser
Affects Versions: 2.0.0-M4
Reporter: Giacomo Lamonaco
 Fix For: 2.0.0


Login to syncope enduser as a registered user, then open plain schemas tab. In 
case of select fields, if user hasn't already chose a value, the first one 
available is automatically picked up. At the end, if user update its own 
profile, the value of that attribute will be updated to the selected value.

If that attribute is not required, user should be able to select an  empty 
value as option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)