You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Massimiliano Perrone <ma...@tirasa.net> on 2015/10/19 11:54:12 UTC
About configuration service
Hi all,
some questions about
org.apache.syncope.common.rest.api.service.ConfigurationService and the
"configuration stack".
1) Why ConfigurationService has a method called list when this method
return a ConfTO object?
1.1) Why not a get() for list() and a read(String schema) for
get(String schema)?
2) Why the "configuration stack" is like the others when JPAConf manage
only CPlainAttr? The most of those methods are unnecessary and misleading.
This questions because I'm using the Syncope common library to develop
and the configuration service doesn't seem to be intuitive.
I hope I was clear enough.
Massimliano
--
Massimiliano Perrone
Tel +39 393 9121310
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)
Re: About configuration service
Posted by Massimiliano Perrone <ma...@tirasa.net>.
Il 19/10/2015 12:08, Francesco Chicchiriccò ha scritto:
> On 19/10/2015 12:06, Francesco Chicchiriccò wrote:
>> On 19/10/2015 11:54, Massimiliano Perrone wrote:
>>> Hi all,
>>> some questions about
>>> org.apache.syncope.common.rest.api.service.ConfigurationService and
>>> the "configuration stack".
>>>
>>> 1) Why ConfigurationService has a method called list when this
>>> method return a ConfTO object?
>>> 1.1) Why not a get() for list() and a read(String schema) for
>>> get(String schema)?
>>>
>>> 2) Why the "configuration stack" is like the others when JPAConf
>>> manage only CPlainAttr? The most of those methods are unnecessary
>>> and misleading.
>>>
>>> This questions because I'm using the Syncope common library to
>>> develop and the configuration service doesn't seem to be intuitive.
>>
>> The point is that with SYNCOPE-290 (released with Syncope 1.2.0-M1 on
>> Sep 8th, 2014) general configuration parameters are now implemented
>> as if they were user attributes: this brought some nice add-ons likes
>> as type management, read-only and multi-value support and so on.
>>
>> In order to implement that, we had to define an immutable Conf entity
>> (similar to User, Group and AnyObject) which holds the list of
>> configuration attributes.
>> This internal representation - which I hardly think that can be
>> changed soon - does not necessarily need to be reflected in the REST
>> interface, though.
>>
>> So, I am +1 if you want to change
>>
>> ConfTO list();
>>
>> into
>>
>> List<AttrTO> list();
>>
>> in ConfigurationService (and then in ConfigurationServiceImpl and
>> ConfigurationLogic / ConfigurationDataBinder) accordingly.
>>
>> At this point I also believe we could safely remove the ConfTO class
>> at all.
>
> ...naturally, this only on master, not for 1_2_X, as it would
> introduce a breaking change in the REST interface.
>
+1. I will open an issue ASAP.
Massi
--
Massimiliano Perrone
Tel +39 393 9121310
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)
Re: About configuration service
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 19/10/2015 12:06, Francesco Chicchiriccò wrote:
> On 19/10/2015 11:54, Massimiliano Perrone wrote:
>> Hi all,
>> some questions about
>> org.apache.syncope.common.rest.api.service.ConfigurationService and
>> the "configuration stack".
>>
>> 1) Why ConfigurationService has a method called list when this method
>> return a ConfTO object?
>> 1.1) Why not a get() for list() and a read(String schema) for
>> get(String schema)?
>>
>> 2) Why the "configuration stack" is like the others when JPAConf
>> manage only CPlainAttr? The most of those methods are unnecessary and
>> misleading.
>>
>> This questions because I'm using the Syncope common library to
>> develop and the configuration service doesn't seem to be intuitive.
>
> The point is that with SYNCOPE-290 (released with Syncope 1.2.0-M1 on
> Sep 8th, 2014) general configuration parameters are now implemented as
> if they were user attributes: this brought some nice add-ons likes as
> type management, read-only and multi-value support and so on.
>
> In order to implement that, we had to define an immutable Conf entity
> (similar to User, Group and AnyObject) which holds the list of
> configuration attributes.
> This internal representation - which I hardly think that can be
> changed soon - does not necessarily need to be reflected in the REST
> interface, though.
>
> So, I am +1 if you want to change
>
> ConfTO list();
>
> into
>
> List<AttrTO> list();
>
> in ConfigurationService (and then in ConfigurationServiceImpl and
> ConfigurationLogic / ConfigurationDataBinder) accordingly.
>
> At this point I also believe we could safely remove the ConfTO class
> at all.
...naturally, this only on master, not for 1_2_X, as it would introduce
a breaking change in the REST interface.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: About configuration service
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 19/10/2015 11:54, Massimiliano Perrone wrote:
> Hi all,
> some questions about
> org.apache.syncope.common.rest.api.service.ConfigurationService and
> the "configuration stack".
>
> 1) Why ConfigurationService has a method called list when this method
> return a ConfTO object?
> 1.1) Why not a get() for list() and a read(String schema) for
> get(String schema)?
>
> 2) Why the "configuration stack" is like the others when JPAConf
> manage only CPlainAttr? The most of those methods are unnecessary and
> misleading.
>
> This questions because I'm using the Syncope common library to develop
> and the configuration service doesn't seem to be intuitive.
The point is that with SYNCOPE-290 (released with Syncope 1.2.0-M1 on
Sep 8th, 2014) general configuration parameters are now implemented as
if they were user attributes: this brought some nice add-ons likes as
type management, read-only and multi-value support and so on.
In order to implement that, we had to define an immutable Conf entity
(similar to User, Group and AnyObject) which holds the list of
configuration attributes.
This internal representation - which I hardly think that can be changed
soon - does not necessarily need to be reflected in the REST interface,
though.
So, I am +1 if you want to change
ConfTO list();
into
List<AttrTO> list();
in ConfigurationService (and then in ConfigurationServiceImpl and
ConfigurationLogic / ConfigurationDataBinder) accordingly.
At this point I also believe we could safely remove the ConfTO class at all.
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/