anonymous wrote : I'll comment more later, but at first sight, property access should be removed from the User interface and should only appear in a profile interface provided by the profile module. Do you mean that User has only getter methods for 'id' and 'userName'? I was thinking about what fields are MUST to have from portal perspective. Like.... should user have email or 'enabled' field? But 'theme' is also required for props so maybe it's better to stay only with 'id' and 'userName' and some others MUST be mapped as persistable in UserProfileModule anonymous wrote : | Now about what can be set or not, that should be exposed by the profile metadata layer. If a non existant property is set and cannot because the underlying model does not offer the capability then an exception should be raide. I was thinking about 'second level DB presistence' approach to enable storing anything, but this sounds ok. The problem remains that some props are must to have and are not easy to persist as LDAP attribute (theme, last login date....) - using default schema. This would end with LDAP impl that: - stores specified props as attributes in LDAP - stores specified props in DB (in table separate from current portal schema) - doesn't store props not specified above. - some props are mandatory to be mapped at least at DB level DB implementation uses current schema. For the API we could just add UserProfileModule.isMapped(String) method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987162#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...