JS2.1 preference issue

["Sie, Yang" <ya...@fmr.com>]

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

Re: JS2.1 preference issue

[David Sean Taylor <da...@bluesunrise.com>]

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