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