David Sean Taylor <david <at> bluesunrise.com> writes:
> interface in jetspeed-api:
> 
> org.apache.jetspeed.userinfo.UserInfoManager
> 

Thanks for the reply David.  I have looked at the implementing class and it 
seems as though portlet preferences as well as user traits/attributes are
both stored in a Preferences object. Is this correct?

I have not worked with the java.util.prefs API much before, so please excuse
my ignorance in this regard.  Looking at the java.util.prefs.Preferences class,
it says "this data is stored persistently in an implementation-dependent 
backing 
store. Typical implementations include flat files, OS-specific registries, 
directory servers and SQL databases."

However, I cannot find where the Preferences tree is actually being persisted.
I can see gets and puts to the Preferences, but not where they are being written
to some storage medium such as a file or database.

This is the piece I am missing.

Furthermore, if I understand correctly that user portlet preferences
and user traits/attributes are both being stored in this medium, IMHO, I think
that these should be seperated out.

The storage of portlet preferences involves storing arbitrary keys and values.
But user attributes are generally going to be made up of a list of fixed 
attributes for a specific portal implementation (eg. email address, first 
name, last name and a whole host of other information that will be necessary
to maintain). 

At least in my case anyway, I am not interested in storing portal preferences
in LDAP as the schema will not really allow for this.  However, I do want
to maintain all the other fixed user traits in LDAP and have them loaded by
the user manager to possibly be made available to portlet applications.

So, I think what I would need to do to accomplish this is:
1. Create an LDAP backed implementation of java.util.prefs.Preferences
2. Extend/Override UserImpl to keep user (portal) preferences and user 
attribute "preferences" separate.
3. Extend/Override UserManagerImpl to use the new User implemenation.
4. Do the appropriate spring config changes.

Does this sound right?

Thanks for the help,
aaron





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to