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
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