portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <d.tay...@onehippo.com>
Subject Re: Problem with preferences when upgrading Java with Jetspeed 2.0
Date Tue, 10 Nov 2009 03:39:18 GMT

On Nov 9, 2009, at 8:12 AM, bhardage wrote:

>
>
> David Sean Taylor-3 wrote:
>>
>> Can you query the database to see if the preferences are stored  
>> there?
>> They will be under the PORTLET_PREFERENCE and  
>> PORTLET_PREFERENCE_VALUE
>> tables in 2.2.
>> In version 2.0, look under the PREFS_NODE and PREFS_PROPERTY_VALUE
>> tables. Seems you might be using version 2.0 according to this email
>> subject...
>>
>> Look in the Windows Registry (regedit). I don't run Windows, but I
>> believe you can go to HKEY_LOCAL_MACHINE/SOFTWARE/Javasoft/Prefs/
>>
>> and then under there you can find the system and user trees. Look for
>> entries likes:
>>
>> /portlet_application/demo/portlets/BookmarkPortletForXHTMLBasic/
>> preferences/Apache Home/size
>>
>> /user/devmgr/userinfo
>>
>
> Yes, you are correct.
>
> It looks like the first time the server is started, registry keys are
> created under
> HKEY_LOCAL_MACHINE/SOFTWARE/Javasoft/Prefs/portlet_application/  
> containing
> what appears to be all my portlet preferences.
>
> If I navigate to a portlet and make a preference change
> (preferences.store()) I get the following warning:
> "[org.apache.ojb.broker.core.PersistenceBrokerImpl] WARN: No running  
> tx
> found, please only store in context of an PB-transaction, to avoid
> side-effects - e.g. when rollback of complex objects" and the registry
> values don't seem to be affected.
>
> After stopping the server, I can see that both the PREFS_NODE and
> PREFS_PROPERTY_VALUE tables have been left pretty much untouched.
>
> However, after restarting the server, visiting that same page, and  
> stopping
> the server the second time, the PREFS_PROPERTY_VALUE table is still
> untouched but the PREFS_NODE tables has several new rows whose  
> NODE_NAME
> fields correspond to the portlets on the page I visited (though the
> preferences were not loaded when I visited the page).
>
> I'm not exactly sure what to make of this information, but apparently
> there's some sort of inconsistency between reading/storing the  
> preferences
> in the registry versus the database between server starts.
>
> Thanks so much for your help so far. I wonder if you would have any
> suggestions on how I might track down the underlying problem.
>
It appears that the Jetspeed preferences factory is not overriding  
Java's default preferences factory. We override the Java preferences  
during the Spring container construction, see WEB-INF/assembly/ 
prefs.xml:

    <bean id="java.util.prefs.PreferencesFactory"  
class="org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl"
          name="prefsFactory" depends-on="preloadPrefsProvider" init- 
method="init" destroy-method="destroy">
         <!-- dummy constructor argument to distinguish it from the  
default constructor invoked by the Java Preferences itself -->
         <constructor-arg><value>1</value></constructor-arg>
         <property name="prefsProvider">
             <ref bean="prefsProvider" />
         </property>
     </bean>

and here is the constructor:

  public PreferencesFactoryImpl(int dummy)
     {
         System.setProperty("java.util.prefs.PreferencesFactory",  
getClass()
                 .getName());
     }

Setting the java.util.prefs.PreferencesFactory system property  
overrides the default Java preferences implementation, which stores  
preferences in the Windows registry, to using the Jetspeed Preferences  
provider, storing preferences in the database

The problem is, something is going wrong in the sequence of setting  
this property. My guess would be one of the following:

1 * some other code in your application is accessing preferences  
before our Spring container, maybe in a static initializer. Could be  
in your command line class path, Tomcat's class loader, or a number of  
different places. Try to isolate Jetspeed as much as possible, using a  
clean Tomcat installation, no custom web applications, and an empty  
class loader when starting Tomcat

2 * somehow the preferences factory assembly has been removed or  
commented out

If this is a fresh installation, then my guess would be #1
If its a Jetspeed that you are upgrading, then something might have  
gone wrong in the upgrade procedure, and the prefs.xml might not be  
correct


NOTE: for version 2.2.0 and higher, the above does not apply since we  
no longer use the Java Preferences API


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