I'm sorry it took so long. I just tested it again and it works fine.

Patrick

2006/2/10, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> Thank you Patrick!
>
> I applied your patch to SVN. Please test this with your portlets again.
>
> /Craig
>
>
>
>
>  Patrick Huber <[EMAIL PROTECTED]>
>
> 02/09/2006 02:45 PM
>
> Please respond to
>  [email protected]
>
>
> To [email protected]
>
> cc
>
>
> Subject Re: Portlet Preferences issues resolved.
>
>
>
>
>
>
>
>
> Hi Zheng
>
>  I finally came around to actually test my own portlet which uses
>  Portlet Preferences and it didn't work. There are actually two
>  problems I've found:
>
>  1) The Portlet Window is used as part of the key name of a pref. The
>  PortletWindowImpl has no toString and thus, the PortletWindow's
>  identity is used, which appears to be different in every request. The
>  first change fixes this.
>
>  2) There was an ordering problem with loading Preferences. 1st: load
>  defaults from portlet.xml 2nd: load actual stored values 3rd: store
>  the merge from 1+2 back to the storage. The 2nd and 3rd steps were
>  swapped.
>
>  With these changes, my own Portlet works as expected. (See svn diff below).
>
>  regards
>  Patrick
>
>
>  Index: 
> pluto-container/src/main/java/org/apache/pluto/core/DefaultPortletPreferencesService.java
>  ===================================================================
>  --- 
> pluto-container/src/main/java/org/apache/pluto/core/DefaultPortletPreferencesService.java
>    (Revision 376396)
>  +++ 
> pluto-container/src/main/java/org/apache/pluto/core/DefaultPortletPreferencesService.java
>    (Arbeitskopie)
>  @@ -97,7 +97,7 @@
>                                      String user) {
>          StringBuffer buffer = new StringBuffer();
>          buffer.append("user=").append(user).append(";");
>  -       buffer.append("portletWindow=").append(portletWindow);
>  +       
> buffer.append("portletWindow=").append(portletWindow.getPortletName());
>          return buffer.toString();
>       }
>
>  Index: 
> pluto-container/src/main/java/org/apache/pluto/core/impl/PortletPreferencesImpl.java
>  ===================================================================
>  --- 
> pluto-container/src/main/java/org/apache/pluto/core/impl/PortletPreferencesImpl.java
>         (Revision 376396)
>  +++ 
> pluto-container/src/main/java/org/apache/pluto/core/impl/PortletPreferencesImpl.java
>         (Arbeitskopie)
>  @@ -123,14 +123,13 @@
>           }
>
>           try {
>  -               // Store the preferences retrieved from portlet.xml.
>  -               store();
>  -            PortletPreference[] prefs =
>  -               preferencesService.getStoredPreferences(window, request);
>  -
>  +            PortletPreference[] prefs =
>  preferencesService.getStoredPreferences(window, request);
>               for (int i = 0; i < prefs.length; i++) {
>                   preferences.put(prefs[i].getName(), prefs[i]);
>               }
>  +
>  +            store();
>  +
>           } catch (PortletContainerException ex) {
>               LOG.error("Error retrieving preferences.", ex);
>               //TODO: Rethrow up the stack????
>
>  2006/2/9, Patrick Huber <[EMAIL PROTECTED]>:
>  > Hi David
>  >
>  > I've been getting lots of ClassNotFoundExceptions during
>  > initialization of the Portlet Container. But there was some kind of
>  > mess on my installation too.
>  >
>  > I just double-checked and tried it all without log4j again and it
>  > works. So the problem was a messed-up tomcat on my side despite me
>  > completely removing and adding tomcat/pluto... twice... really
>  > strange.
>  >
>  > Sorry for the inconvenience...
>  >
>  > Patrick
>  >
>  >
>  > 2006/2/9, David H. DeWolf <[EMAIL PROTECTED]>:
>  > > sorry that I haven't followed this thread close enough. . .could
>  > > someone recap on why we want to make log4j the implementation we
>  > > choose? what's wrong with just using SimpleLog - since eveything else
>  > > we're gearing towards is simple/lightweight?
>  > >
>  > > David
>  > >
>  > > On 2/9/06, Zhong ZHENG <[EMAIL PROTECTED]> wrote:
>  > > > pom updated to include log4j.
>  > > >  Thanks Patrick!
>  > > >
>  > > >
>  > > > On 2/8/06, Patrick Huber <[EMAIL PROTECTED]> wrote:
>  > > > > Hi
>  > > > >
>  > > > > I'm still having the same problem. The log4j.jar is not included in
>  > > > > pluto-portal.war per default - the pom doesn't reference log4j as
>  > > > > dependency. The entry I added looks like this (copied from the
>  > > > > testsuite):
>  > > > >     <dependency>
>  > > > >       <groupId>log4j</groupId>
>  > > > >       <artifactId>log4j</artifactId>
>  > > > >       <version>1.2.9</version>
>  > > > >       <scope>runtime</scope>
>  > > > >     </dependency>
>  > > > >
>  > > > > After a mvn clean install; mvn pluto:install
>  > > > > -DinstallDir=$CATALINA_HOME, log4j.jar is included in the war file.
>  > > > >
>  > > > > Would you mind doing a fresh svn co to check if you get this same
>  > > > > error or not? So we'd know for sure if this is a local problem on my
>  > > > > end or not.
>  > > > >
>  > > > > --
>  > > > >
>  > > > > Update: I just tried another thing: delete pluto and testsuite from
>  > > > > the webapp directory and that seemed to do the trick. Even though the
>  > > > > tomcat install was fresh too, there must have been some leftovers 
> from
>  > > > > a previous attempt...
>  > > > >
>  > > > > Sorry for bothering you
>  > > > > Patrick
>  > > > >
>  > > > >
>  > > > > --
>  > > > > "I love deadlines. I like the whooshing sound they make as they fly
>  > > > > by." -- Douglas Adams
>  > > > >
>  > > >
>  > > >
>  > > > --
>  > > >
>  > > > ZHENG Zhong
>  > > >  - http://heavyz.blogspot.com/
>  > > >  - http://people.apache.org/~zheng/
>  > > >
>  > >
>  >
>  >
>  >
>  > --
>  > "I love deadlines. I like the whooshing sound they make as they fly
>  > by." -- Douglas Adams
>  >
>
>
>  --
>  "I love deadlines. I like the whooshing sound they make as they fly
>  by." -- Douglas Adams
>
>



--
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams

Reply via email to