Problem with preferences when upgrading Java with Jetspeed 2.0

[bhardage]

Hello,

I'm attempting to upgrade a web application I'm working on from Java 1.5.0_06 to Java 1.6.0_16 and I've run into a problem concerning Jetspeed.

Basically, I set some preferences for a certain portlet in my portlet.xml file which loaded correctly before the Java upgrade, but now only load part of the time.

They're actually loaded correctly the first time my server is started (I'm using Tomcat), but after stopping and restarting the server, they're never loaded again.

Any help would be much appreciated.

Thanks, B.J.

[David Sean Taylor-3]

On Oct 13, 2009, at 8:12 AM, bhardage wrote:

>
> Hello,
>
> I'm attempting to upgrade a web application I'm working on from Java
> 1.5.0_06 to Java 1.6.0_16 and I've run into a problem concerning  
> Jetspeed.
>
> Basically, I set some preferences for a certain portlet in my  
> portlet.xml
> file which loaded correctly before the Java upgrade, but now only  
> load part
> of the time.
>
> They're actually loaded correctly the first time my server is  
> started (I'm
> using Tomcat), but after stopping and restarting the server, they're  
> never
> loaded again.

I have seen this problem when preferences are stored to the default  
preferences provider (on Windows, that would be the Windows Registry  
for example) instead of storing to the Jetspeed Database Preferences  
store. You might want to for your preferences there first, and try to  
figure out what could be causing the Java Preferences API to override  
Jetspeed's preferences provider

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@...
For additional commands, e-mail: jetspeed-dev-help@...

[bhardage]

David Sean Taylor-3 wrote:

I have seen this problem when preferences are stored to the default  
preferences provider (on Windows, that would be the Windows Registry  
for example) instead of storing to the Jetspeed Database Preferences  
store. You might want to for your preferences there first, and try to  
figure out what could be causing the Java Preferences API to override  
Jetspeed's preferences provider

I am fairly unfamiliar with the underlying structure of Jetspeed. I wonder if you could give some advice as to how to find this information; I'm 98% sure I'm not using the Windows Registry, although this is a designed-for-Windows app, but I'm really not sure where to start looking for the cause of this problem.

Thanks for you help,

B.J.

[David Sean Taylor-3]

On Nov 6, 2009, at 12:21 PM, bhardage wrote:

>
>
> David Sean Taylor-3 wrote:
>>
>> I have seen this problem when preferences are stored to the default
>> preferences provider (on Windows, that would be the Windows Registry
>> for example) instead of storing to the Jetspeed Database Preferences
>> store. You might want to for your preferences there first, and try to
>> figure out what could be causing the Java Preferences API to override
>> Jetspeed's preferences provider
>>
>
> I am fairly unfamiliar with the underlying structure of Jetspeed. I  
> wonder
> if you could give some advice as to how to find this information;  
> I'm 98%
> sure I'm not using the Windows Registry, although this is a
> designed-for-Windows app, but I'm really not sure where to start  
> looking for
> the cause of this problem.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@...
For additional commands, e-mail: jetspeed-dev-help@...

[bhardage]

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.

Thanks,
B.J.

[David Sean Taylor-3]

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@...
For additional commands, e-mail: jetspeed-dev-help@...

[bhardage]

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.

[David Sean Taylor-3]

On Nov 10, 2009, at 8:46 AM, bhardage wrote:

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

I see you are on version 2.0. I gave you the constructor for version  
2.1.3. I was under the impression you were using version 2.1.3, sorry.
Also, you said you are using Java version 1.6, but you were using  
version 1.5. Were the preferences working with Java 1.5?
Perhaps there is a problem with Java 1.6 and version 2.0 of Jetspeed  
(I haven't used 2.0 in a long time now....)


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@...
For additional commands, e-mail: jetspeed-dev-help@...

[bhardage]

David Sean Taylor-3 wrote:

I see you are on version 2.0. I gave you the constructor for version  
2.1.3. I was under the impression you were using version 2.1.3, sorry.
Also, you said you are using Java version 1.6, but you were using  
version 1.5. Were the preferences working with Java 1.5?
Perhaps there is a problem with Java 1.6 and version 2.0 of Jetspeed  
(I haven't used 2.0 in a long time now....)

Yes, the preferences load correctly for Java 1.5 and Jetspeed 2.0. A registry key is not created and the two previously mentioned tables are populated correctly.

The problem comes only when I use Java 1.6 and Jetspeed 2.0. I have no idea why it happens; I just know the preferences stop loading correctly.

Thanks,
B.J.

[David Sean Taylor-3]

On Nov 10, 2009, at 2:24 PM, bhardage wrote:

>
>
> David Sean Taylor-3 wrote:
>>
>> I see you are on version 2.0. I gave you the constructor for version
>> 2.1.3. I was under the impression you were using version 2.1.3,  
>> sorry.
>> Also, you said you are using Java version 1.6, but you were using
>> version 1.5. Were the preferences working with Java 1.5?
>> Perhaps there is a problem with Java 1.6 and version 2.0 of Jetspeed
>> (I haven't used 2.0 in a long time now....)
>>
>
> Yes, the preferences load correctly for Java 1.5 and Jetspeed 2.0. A
> registry key is not created and the two previously mentioned tables  
> are
> populated correctly.
>
> The problem comes only when I use Java 1.6 and Jetspeed 2.0. I have  
> no idea
> why it happens; I just know the preferences stop loading correctly.

Any chance that you can upgrade to 2.1.3 or 2.1.4-trunk?

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@...
For additional commands, e-mail: jetspeed-dev-help@...

[bhardage]

David Sean Taylor-3 wrote:

Any chance that you can upgrade to 2.1.3 or 2.1.4-trunk?

Well, I figured worst case scenario would come down to either upgrading or just not using the preferences api in favor of a properties file instead.

Thanks,
B.J.

[David Sean Taylor-3]

On Nov 11, 2009, at 6:46 AM, bhardage wrote:

>
>
> David Sean Taylor-3 wrote:
>>
>> Any chance that you can upgrade to 2.1.3 or 2.1.4-trunk?
>>
>
> Well, I figured worst case scenario would come down to either  
> upgrading or
> just not using the preferences api in favor of a properties file  
> instead.
>

The preferences are a little more involved than a few property files.  
Best I can do is recommend staying on Java 1.4 or 1.5 for the 2.0  
release, or migrating to a newer release. Guess I could load up the  
old 2.0 release and see for myself what is going wrong on Java 1.6 if  
using Java 1.6 and Jetspeed 2.0 is absolutely critical for you....


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@...
For additional commands, e-mail: jetspeed-dev-help@...

[bhardage]

David Sean Taylor-3 wrote:

The preferences are a little more involved than a few property files.  
Best I can do is recommend staying on Java 1.4 or 1.5 for the 2.0  
release, or migrating to a newer release. Guess I could load up the  
old 2.0 release and see for myself what is going wrong on Java 1.6 if  
using Java 1.6 and Jetspeed 2.0 is absolutely critical for you....

Well, the problem is that the customer for whom this application is being modified understands what Java is, just because it's something he knows has to be installed before the application. He's a little fuzzier with Jetspeed, since it's built into the application, and upgrading it probably won't show any visible changes.

I don't think it'll be a problem upgrading Jetspeed as far as he's concerned if that's what it takes to fix the Java problem (and it really needs to be upgraded eventually anyway). So, I guess I just need to bite the bullet and upgrade Jetspeed.

As far as you looking at Jetspeed 2.0/Java 1.6 to see what the problem is, it's unnecessary. I mean part of me really wants to know what the problem was, but it's not worth the time.

Thanks again for all your help.

B.J.

[David Sean Taylor-3]

On Nov 16, 2009, at 6:26 AM, bhardage wrote:

>
>
> David Sean Taylor-3 wrote:
>>
>> The preferences are a little more involved than a few property files.
>> Best I can do is recommend staying on Java 1.4 or 1.5 for the 2.0
>> release, or migrating to a newer release. Guess I could load up the
>> old 2.0 release and see for myself what is going wrong on Java 1.6 if
>> using Java 1.6 and Jetspeed 2.0 is absolutely critical for you....
>>
>
> Well, the problem is that the customer for whom this application is  
> being
> modified understands what Java is, just because it's something he  
> knows has
> to be installed before the application. He's a little fuzzier with  
> Jetspeed,
> since it's built into the application, and upgrading it probably  
> won't show
> any visible changes.
>
> I don't think it'll be a problem upgrading Jetspeed as far as he's  
> concerned
> if that's what it takes to fix the Java problem (and it really needs  
> to be
> upgraded eventually anyway). So, I guess I just need to bite the  
> bullet and
> upgrade Jetspeed.
>
> As far as you looking at Jetspeed 2.0/Java 1.6 to see what the  
> problem is,
> it's unnecessary. I mean part of me really wants to know what the  
> problem
> was, but it's not worth the time.

You can follow the data migration guides to upgrade here:

http://portals.apache.org/jetspeed-2/guide-migration.html

Im kinda interested to see why it fails. If you can wait a few days I  
might get a look at it...


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@...
For additional commands, e-mail: jetspeed-dev-help@...