cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DURDINA Michal" <>
Subject RE: [portal] JSR168 portlets problems under PortalEngine
Date Mon, 08 Mar 2004 19:03:35 GMT
> > 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:
javax.xml.transform.TransformerException: java.util.ConcurrentModificationException
	at org.apache.xalan.transformer.TransformerImpl.transformNode(
	at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(
	at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(
	at org.apache.cocoon.transformation.TraxTransformer.endDocument(
	at org.apache.cocoon.portal.impl.PortalManagerImpl.showPortal(

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


View raw message