...
>
> > 1. test2.jsp: Call to
> > portalContext.getSupportedWindowStates() returns null.
> >
> I fixed this (hopefully) yesterday morning in the CVS.
>
Haven't got chance to test it again. After I updated my whole cocoon-distribution from
CVS and build clean webapplication only with portal-block and I am encountering
problem that did not occure before. After click on JSR-168 tab the exception occured:
INFO (2004-03-08) 19:42.51:791 [core.authentication-manager]
(/cocoon21/samples/portal/auth) Thread-7/PipelineAuthenticator: Authenticator: User
authenticated using handler 'portal-handler'
FATAL_E (2004-03-08) 19:42.58:619 [core.xslt-processor]
(/cocoon21/samples/portal/portal) Thread-9/TraxErrorHandler: Error in TraxTransformer:
javax.xml.transform.TransformerException: java.util.ConcurrentModificationException
javax.xml.transform.TransformerException: java.util.ConcurrentModificationException
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1226)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3135)
at
org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:433)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:56)
at
org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:549)
at
org.apache.cocoon.portal.impl.PortalManagerImpl.showPortal(PortalManagerImpl.java:76)
...
But when I comment out testsuite portlets and leave only "internal" TestPortlet1,
exception does not occur. If it has something to do with the fact the cocoon doesn't
use last pluto container and I used latest testsuite (it didn't change much last days)
then please ignore this report. BTW: When testing in cocoon I replaced latest pluto
jars with ones that come with cocoon.
> > 2. test2.jsp: Call to renderRequest.getParameter("testName")
> > returns null after 2.nd and every other render() was called.
> > Portlet container should preserve request parameters sent
> > upon 1.st request for every subsequent call of render() in
> > the portlet which was not target of the subsequent client
> > request (JSR-168spec chap. 11.1.1 §3). But jakarta-pluto is
> > also doing this, so it's not exactly cocoon problem.
> >
> Did you test the latest pluto version?
Yes I did. It is still happening with latest jakarta-pluto/Tomcat from CVS today, so I
reported that to pluto bugzilla.
>
> > 3. test3.jsp: Submit to url created by
> > renderResponse.createRenderURL();
> > url.setWindowState(WindowState.MAXIMIZED); changes correctly
> > return value of renderRequest.getWindowState() to
> > "maximized", but the portlet window actually does not
> > maximize. By contrast when submit to url with
> > WindowState.MINIMIZED is executed, the portlet windows
> > minimizes but stays minimized forever - I could not get it to
> > normal size by clicking window icons.
> >
Reported to cocoon bugzilla.
> > 4. test4.jsp: Simmilar to point 2. but at this time
> > parameters set by _action_ are not preserved. When testing in
> > jakarta-pluto, they are.
> >
> > My testing env:
> > cocoon-portal block build from CVS (04.march.2003)
> > jakarta-testuite built from CVS (04.march.2003)
> >
> Thanks for reporting this! I think the best way is if you file bugs
> into bugzilla. Please enter a bug to the Cocoon bugs if the
> problem is only with the Cocoon portal and to Pluto's bug list
> if the bug is in Pluto as well.
>
> I will try to update the version of Pluto used in Cocoon to the
> latest version in the next days and then have a look at the bugs
> you described.
>
> Many thanks!
>
Thank you!
Michal
