Replacing List of Property with Map of Strings in OAuth2 Data Model

[Sergey Beryozkin <sb...@gmail.com>]

Hi

I'd like to check with those who have worked on persisting CXF OAuth2 
Data Model (Thorsten and may be others) on the following.
I've added a List<Property> field to Client, UserSubject, and 
OAuthAuthorizationData beans to support whatever additional properties 
that may be added to individual instances, where Property contains 
'name' & 'value' String pairs.

I did it instead of adding Map<String, String> because for whatever 
reasons I was concerned that using Map will have side-effects for the 
distributed token validation process, I may have thought JAXB won't be 
able to manage them at all.
The end result that having List<Property> is awkward to work with - the 
user code needs to enumerate over the list, I'm also seeing it 
complicates the custom serialization process, and adds some 
inconsistency to the model: for example, ServerAccessToken has a Map of 
extra properties, while its UserSubject field has List<Property> to keep 
the extra properties.

So what I'm planning to do for 3.0.0 milestone2 only is to do what I 
should've done in the first place, i.e, use Map<String, String> for 
keeping the extra properties across the data model and get rid of the 
Property class.

I'd expect that the modern data management tools can offer a migration 
help in such cases, especially given that it is an isolated and minor 
migration issue, assuming people have used the extra properties at all.

Let me know please if you have any concerns, if I don't hear any 
objections then I'd go ahead with change, only on the trunk

Thanks, Sergey

Re: Replacing List of Property with Map of Strings in OAuth2 Data Model

[Thorsten Höger <li...@hoegernet.de>]

Hi,

no objections from my side. I like the change.

Regards,
Thorsten

Am 21.01.2014 13:42, schrieb Sergey Beryozkin:
> Hi
>
> I'd like to check with those who have worked on persisting CXF OAuth2 Data Model
> (Thorsten and may be others) on the following.
> I've added a List<Property> field to Client, UserSubject, and OAuthAuthorizationData
> beans to support whatever additional properties that may be added to individual
> instances, where Property contains 'name' & 'value' String pairs.
>
> I did it instead of adding Map<String, String> because for whatever reasons I was
> concerned that using Map will have side-effects for the distributed token validation
> process, I may have thought JAXB won't be able to manage them at all.
> The end result that having List<Property> is awkward to work with - the user code needs
> to enumerate over the list, I'm also seeing it complicates the custom serialization
> process, and adds some inconsistency to the model: for example, ServerAccessToken has a
> Map of extra properties, while its UserSubject field has List<Property> to keep the
> extra properties.
>
> So what I'm planning to do for 3.0.0 milestone2 only is to do what I should've done in
> the first place, i.e, use Map<String, String> for keeping the extra properties across
> the data model and get rid of the Property class.
>
> I'd expect that the modern data management tools can offer a migration help in such
> cases, especially given that it is an isolated and minor migration issue, assuming
> people have used the extra properties at all.
>
> Let me know please if you have any concerns, if I don't hear any objections then I'd go
> ahead with change, only on the trunk
>
> Thanks, Sergey
>
>