portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: JS2.1 preference issue
Date Wed, 04 Apr 2007 17:49:00 GMT
Try this setting in registry.xml:

        <!--
             All preferences were shared. With JS2-449, preferences  
are now
             stored 'per user'. The username is stored in the  
preferences FULL_PATH
             To turn on mergeSharedPreferences configure this  
property to true
             This will NOT turn off per user prefs,
              but instead merge with them, where user prefs override.
             boolean
           -->
         <constructor-arg type="boolean">
             <value>true</value>
         </constructor-arg>

Let me know if that brings the preferences back.
We can then further discuss how we want to handle this, either with a  
conversion utility or SQL, or just leave it as is
When the preferences are stored, they will be converted over to the  
new paths


On Apr 4, 2007, at 8:20 AM, Sie, Yang wrote:

> Hello all:
>
> We are trying to upgrade to JS2.1 code base (from 2.1-dev of July  
> 2006)
> and found an issue with existing user preferences.
>
> All existing users preferences came up with nothing even thou the data
> are in the prefs_property_value table. What happened was that we don't
> use JS2's user management and sign on modules, the no-principal is
> always shown in the prefs_node table. However, the new JS2.1 code base
> stores user preference with our users id. Therefore the no- 
> principal is
> no longer used/stored in the prefs_node table. Example:
>
> In our existing DB, the full_path filed in prefs_node table:
>    portlet_entity/538/no-principal/preferences/searchVal/values
> In new schema, the full path becomes:
>    portlet_entity/538/aBadgeID/preferences/searchVal/values
>
> Therefore, the existing preferences for existing users are no longer
> showing.  To correct this, these are what we have in mind:
>
> 1. Write SQL scripts to scan entire table to update every single
> person's preferences (use badgeID to replace the no-principal). We  
> have
> tried this with one user and it worked fine. However, given the
> complexity of the tree structure of the data and the amount of data,
> this approach could potentially introduce errors.
>
> 2. We found out that in Serializer JSEntityPreference
> (org.apache.jetspeed.serializer.objects.JSEntityPreference) it
> mentioned: if ((s == null) || (s.length() == 0)) s = "no- 
> principal";  We
> thought we maybe able to customize this class to get something.  
> Without
> looking into details, is this the only place? Is there a configuration
> file to achieve this?
>
> 3. initDB, we didn't think this can be counted on since each time we
> initDB, all user preferences, as well as their  customized page  
> layouts
> and fragments, will all be gone. It is too clean!
>
> 4. Create our own preference provider in a long term.
>
> Please advise on the best and quickest way to handle this situation.
>
> Thank you.
>
> ---Yang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>

-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message