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
|