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: [email protected]
For additional commands, e-mail: [email protected]
