David Sean Taylor-3 wrote:
>
> 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
>
One difference I do notice is in the way the bean is defined. My definition:
<bean id="java.util.prefs.PreferencesFactory"
class="org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl"
name="prefsFactory"
init-method="init">
<property name="prefsProvider">
<ref bean="prefsProvider" />
</property>
</bean>
The constructor arg is missing, and there is no constructor which takes an
argument in the PreferencesFactoryImpl class. I don't know if this is
relevant, but it is a difference.
I hesitate in asking about this because it seems like a simple spring/java
problem, but I attempted to add this constructor with some errors. I just
added the constructor-arg in "prefs.xml" and modified
"WEB-INF/lib/jetspeed-prefs-2.0.jar" (which I assume is where it's pulling
the class from) by adding the constructor you mentioned to the
PreferencesFactoryImpl class. However, for some reason it's not recognizing
the new constructor; I get a bean exception when Jetspeed is starting up:
"1 constructor arguments specified but no matching constructor found in bean
'java.util.prefs.PreferencesFactory'".
Again, I feel kind of stupid asking about this but I can't see why it
wouldn't recognize that constructor (I can use a combination of 7-Zip and
JD-GUI to see that the constructor I added is definitely in the jar).
I guess the real question, though, is if the alternate constructor is
necessary at all.
Any help is appreciated.
Thanks,
B.J.
--
View this message in context:
http://old.nabble.com/Problem-with-preferences-when-upgrading-Java-with-Jetspeed-2.0-tp25874753p26286834.html
Sent from the Jetspeed - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
