RE: ANN: [portal] New CachingPortletAdapter
> -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Friday, January 07, 2005 5:46 PM > To: dev@cocoon.apache.org > Subject: Re: ANN: [portal] New CachingPortletAdapter > > > DURDINA Michal wrote: > > Sorry for just a quick response. > > > > JSR168 - portlet specification really defines something > like "expiration cache", which when set to -1 should provide > caching of portlet content. > > > > But as I see it: > > * according to spec, implementation of caching is optional > for portlet container > > * content would be cached also with translated links > (conflict with DefaultEventConverter - that generates links > only with one request validity) > > * portal samples already contains > -1 but caching is not > working (try to output current time in TestPortlet - it will > always refresh) > > * yet must investigate pluto distribution wheter caching > is supported by pluto container at all > > > If the caching as outlined in the spec is not working in > Cocoon, we have > to first fix this to be jsr 168 compliant. So, let's wait for > the results. > > Carsten > I checked Pluto 1.0.1-rc1 (and also trunk) and the result is: pluto portal (/portal) does not implement caching yet. The portlet.xml expiration-cache element is parsed in PortletDefinitionImpl but never read (checked with Eclipse -> References). The same is valid for cocoon. IMHO it is the responsibility of the portal to implement caching not of portlet container. I think there is nothing to fix in cocoon to enable caching. We have to implement caching in cocoon and pluto portal (/portal subproject) should implement caching its own way. Caching implementation involves no changes in pluto container (/container subproject) that the cocoon is dependent on. I suggest I can slightly modify the CachingPortletAdapter to adapt for PortletDefinitionImpl.getExpirationCache() value. Original PortletAdapter can stay untouched and users would have to use new CachingPortletAdapter to enable caching in their portals. I think it is better to provide caching in the new adapter, because users that already used PortletAdapter depend on non-caching behaviour (regardless of value in their portlet.xml). WDYT? I can provide a new patch to bugzilla or only difference to my current patch and I would be happy if somebody could take a look at it afterwards. Thank you, Michal
RE: ANN: [portal] New CachingPortletAdapter
Sorry for just a quick response. JSR168 - portlet specification really defines something like "expiration cache", which when set to -1 should provide caching of portlet content. But as I see it: * according to spec, implementation of caching is optional for portlet container * content would be cached also with translated links (conflict with DefaultEventConverter - that generates links only with one request validity) * portal samples already contains -1 but caching is not working (try to output current time in TestPortlet - it will always refresh) * yet must investigate pluto distribution wheter caching is supported by pluto container at all Michal > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Friday, January 07, 2005 1:14 PM > To: dev@cocoon.apache.org > Subject: Re: ANN: [portal] New CachingPortletAdapter > > > Hi, > > the portlet standard already supports caching; each portlet can be > configured to be cached and the portlet container (in our case pluto) > should cache the content. > So I think our portal already does the caching. Or do I > oversee something? > > Carsten > > DURDINA Michal wrote: > > Hi, > > after some days of coding I finished the implementation of > CachingPortletAdapter ! With CachingPortletAdapter you can > have JSR168 portlets that behave (almost) exactly as they > were every opened in single web browsers. This means that > only one portlet that triggered the action is regenerated at > the time. Content of other portlets are returned from cache. > Porlet content caching was also possible using non-caching > PortletAdapter, but developers needed to implement caching > behaviour inside their portlets. Moreover changing portlet > window state (maximize/minimize/normalize) can be now > optionally handled just by portal without calling the > portlet. This code is already in our application and is > already tested. > > > > CachingPortletAdapter works on these principles: > > * portlet hyperlinks are cached with contents > > * links for window icons have different validity category > mode that links located in content > > * fullscreen state stored on session > > > > Some extensions to existing implementation was required: > > * added links validity categories to EventConverter > (request, half-session, session, permanent) > > * new CopletLinkingEventConverter that implements > half-session links validity > > * new PortletInstanceEvent implemented by > PortletURLProviderImpl to distinguish that portlet events are > NOT targeted to CachingURICopletAdapter (caused conflict) > > * storing EntryLayout (fullscreen) to PortalService > attribute (session) instead of temporaryAttribute (request) > > * refactoring of caching methods to new CopletCache class > > * refactoring of portlet content loading to > loadPortletContent method > > * all changes are backwards compatible > > > > CachingPortletAdapter in hierarchy of coplet adapters: > > AbstractCopletAdapter > > PortletAdapter URICopletAdapter > > CachingPortletAdapter CachingURICopletAdapter > > ApplicationCopletAdapter > > > > The code is submitted in bugzilla: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=32991 > > > > The code contains modified samples that demonstrate new > portlet caching ability. It has been tested with > cocoon-2.1.6. Please take a look at it and possibly apply it > to BRANCH_2_1_X and thereafter to trunk. > > > > Thank you, > > Michal > > > > > >>-Original Message- > >>From: Ralph Goers [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, December 08, 2004 4:50 PM > >>To: dev@cocoon.apache.org > >>Subject: RE: [portal] Need for CachingPortletAdapter > >> > >> > >>Michal, > >> > >>Unfortunately, I have a lot on my plate right now. I'm going > >>to have to do > >>some research to look into your proposals below and so I > >>won't be able to > >>give you my opinion for a few days. But I don't want you to > think I am > >>ignoring this. > >> > >>Ralph > >> > >> > >>ÏURDINA Michal said: > >> > >>>Hi, > >>>I got finally into PageLabels that are implemented in > >> > >>portal block in > >> > >>>cocoon 2.1.6 and documented at > >>>http://wiki.apache.org/cocoon/PortalPageLabels. > >>> > >>>Ralf Goers wrote on > >>> >
ANN: [portal] New CachingPortletAdapter
Hi, after some days of coding I finished the implementation of CachingPortletAdapter ! With CachingPortletAdapter you can have JSR168 portlets that behave (almost) exactly as they were every opened in single web browsers. This means that only one portlet that triggered the action is regenerated at the time. Content of other portlets are returned from cache. Porlet content caching was also possible using non-caching PortletAdapter, but developers needed to implement caching behaviour inside their portlets. Moreover changing portlet window state (maximize/minimize/normalize) can be now optionally handled just by portal without calling the portlet. This code is already in our application and is already tested. CachingPortletAdapter works on these principles: * portlet hyperlinks are cached with contents * links for window icons have different validity category mode that links located in content * fullscreen state stored on session Some extensions to existing implementation was required: * added links validity categories to EventConverter (request, half-session, session, permanent) * new CopletLinkingEventConverter that implements half-session links validity * new PortletInstanceEvent implemented by PortletURLProviderImpl to distinguish that portlet events are NOT targeted to CachingURICopletAdapter (caused conflict) * storing EntryLayout (fullscreen) to PortalService attribute (session) instead of temporaryAttribute (request) * refactoring of caching methods to new CopletCache class * refactoring of portlet content loading to loadPortletContent method * all changes are backwards compatible CachingPortletAdapter in hierarchy of coplet adapters: AbstractCopletAdapter PortletAdapter URICopletAdapter CachingPortletAdapter CachingURICopletAdapter ApplicationCopletAdapter The code is submitted in bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=32991 The code contains modified samples that demonstrate new portlet caching ability. It has been tested with cocoon-2.1.6. Please take a look at it and possibly apply it to BRANCH_2_1_X and thereafter to trunk. Thank you, Michal > -Original Message- > From: Ralph Goers [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 08, 2004 4:50 PM > To: dev@cocoon.apache.org > Subject: RE: [portal] Need for CachingPortletAdapter > > > Michal, > > Unfortunately, I have a lot on my plate right now. I'm going > to have to do > some research to look into your proposals below and so I > won't be able to > give you my opinion for a few days. But I don't want you to think I am > ignoring this. > > Ralph > > > ÏURDINA Michal said: > > Hi, > > I got finally into PageLabels that are implemented in > portal block in > > cocoon 2.1.6 and documented at > > http://wiki.apache.org/cocoon/PortalPageLabels. > > > > Ralf Goers wrote on > > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110191154925434&w=2: > >> >Main issue I see in implementing CachingPortletAdapter is > >> "link translation". > >> > 1.) links that are sent to browser are valid only for the > >> next request > >> > 2.) translated links are part of generated content > >> > 3.) portlet content cannot be cached since its links will > >> not be valid after next request > >> > > >> > > >> If you use PageLabels the above is not true. Events are > valid until > >> they are regenerated on the next request to that page label. > > > > It is not exactly so. Lifecycle of links when using > PageLabels is very > > simmilar to that in the original DefaultEventConverter. They are > > genereated and stored to ENCODE hashmap in the coplet > generation phase and > > live until the portal tab page is generated again. Links > are preserved > > ONLY when switching form one tagged page to another tagged page. > > > > Therefore I refine my statements of issues for implementing > > CachingPortletAdapter (using PageLabels): > > 1.) links that are sent to browser are valid only for the > next request > > (unless the tagged page is switched) > > 2.) translated links are part of generated content > > 3.) portlet content cannot be cached since its links will > not be valid > > after next request to the same tagged page > > > > I have CachingPortletAdapter finished, but I must solve the > problem with > > links to make it working. > > > > I see these possibilities: > > A.) invert the responsibility and let the coplets to > maintain lifecycle of > > their events/links > > > > - coplet will add the event to store (EventConverter) on content > > generation > > - coplet will remember its own list of its events > > - coplet will remove its remembered old events from the store when > > regenerating or removing (logout) > > - EventConverter will not remove events > > > > B.) enhance PageLabelEventConverter and add name of coplet > instance to key > > for events store > > > > - currently only page tab name is used for
RE: [portal] Need for CachingPortletAdapter
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 02, 2004 7:32 PM > To: [EMAIL PROTECTED] > Subject: RE: [portal] Need for CachingPortletAdapter > > > > > > Thanx! > > > > Your PageLabels seem like great enhancement to the portal > engine. Need to > > look closer but > > seems like caching of portlet content will be breeze with > pagelinks in > > use. > > > > But there is one issue remaining. I am afraid that links > don't work on > > first portal page in samples. Seems like pagelinks won't > work on pages > > with no tabs. Did you encounter same behaviour? > > Yes. I suppose that is by design. PageLabels are only > generated for named > items, primarily because items don't have any information to use to > generate a page label. If you have an idea on how that could > be improved > I'd certainly be open to it, although I'm a little unclear on why not > having a page label on a single page web site would be a > problem. Maybe > you could provide an example that would illustrate that. > If I understood you right, you think that absence of pagelinks (=absence of request param 'pagelink') should be no problem on single page with no tabs. So do I. Or at least at this moment :-) But my position is different. I encountered state when links on first page of portal sample don't work at all. That means, no event as maximalization, close, etc is invoked by clicking on the link on icon. Do I have configured anything wrong or is it a bug? Thank you, Michal
RE: JSR-168 Portlets
> > Carsten Ziegeler wrote: > > >I did get it running in Tomcat with just the Pluto libs in > >lib/shared and it worked - it's a long time ago > > > >Now, the better way imho would be if the portlets would > >run "inside of Cocoon" rather than "inside of Tomcat". > >So, you deploy your portlet wars into your Cocoon war > >(or a totally different place) and you don't have to deploy > >the portlets as usual web applications in your servlet > >engine. I think this should be possible, but of course > >needs some work to be done. > > > >Apart from that, if you have any issues/questions/suggestions > >about Pluto, just asked on the pluto mailing list ;) > > > >Carsten > > > > > Well, I like the idea of deploying them inside of Cocoon. I'm > not sure > why the Portlet spec says they should be web apps. The spec says that the portlet applications are supposed to use existing servlet environment. IMHO they wanted to use as much from existing servlet infrastructure as possible. That ended in conclusion that every single portlet application should be packaged and deployed as servlet application. > > But I have good news. I was able to get a portlet to work with the > portlet deployed as a war file and I didn't have to change > any code. First of all I am wondering why there are any problems with pluto.jar placed in "shared/lib". We use it for pluto.jar for Cocoon-2.1.5 and pluto-1.0.1 and it's working correctly. Moreover we also packaged both portal.war + portlet.war + pluto.jar into one enterprise application (ear) and after few patches to cocoon it is working as well (patches been recently submitted to bugzilla). > simply put the pluto and portlet-api jars in Tomcat's common/lib > directory instead of shared/lib and that got rid of the > ClassNotFoundException. I guess there is either a bug in > Tomcat or I am > not reading their documentation properly. There might be some change in Tomcat. We are using Tomcat 4.1.27 and know nothing about Tomcat 5, but in Tomcat 4.1 classloader hierarchy is as of: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html >From the picture there it is evident that "shared/lib" should be "good enough" >placement for all libraries that should be shared between deployed web >applications (portal.war + portlet.war). Only libraries that need to be >"visible" also from container (cataline) should be placed to "common/lib". >Example for this can be custom Pricipal object shared between custom >authentication realm (that instantiate it) and web application (that is >reading it). Michal
[portal] handling portlet action request
I know this should be targeted more to cocoon-users but I believe this would be interesting also for developers. Two types of portlet requests are handled by CocoonPortlet in methods: processAction(request, response) render(request, response). Speciallity of handling ACTION request is that it MUST NOT touch PortletOutputStream or set content type in PortletResponse. This is the task for following render request that comes from portlet container right after action request. In Cocoon both request types are handled very similar; by sitemap. As a result following excetptions are thrown in action request: java.lang.IllegalStateException: Operation 'getOutputStream' is not supported by 'org.apache.cocoon.environment.portlet.ActionResponse' java.lang.IllegalStateException: Operation 'setContentType' is not supported by 'org.apache.cocoon.environment.portlet.ActionResponse' I wonder how is it possible to create sitemap construction that does not touch outputstream and content type of response at all. Thank you for any ideas, Michal
[portal] Upload not working for JSR168 portlets in Cocoon portal
Hello, have you ever tried upload from within portlet in cocoon portal? I can't get this working. I think it is because of the condition that is checking current request content type (must be 'multipart/form-data' for upload) and the implementation of portal servlet request wrapper (ServletRequestImpl.java) that constantly returns "text/html". Take a look at condition in method getServletRequest() in https://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/portal/java/org/apache/cocoon/portlet/multipart/RequestFactory.java and method getContentType() in https://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/portal/java/org/apache/cocoon/portal/pluto/servlet/ServletRequestImpl.java What was the reason for ServletRequestImpl.java not to return content type from actual request but always return "text/html"? May I submit a patch that will change ServletRequestImpl.java to return actual this.request.getContentType() ? Thank you, Michal
RE: Design of unmarshaling sitemap component
> -Original Message- > From: Hunsberger, Peter [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 29, 2004 7:06 PM > To: [EMAIL PROTECTED] > Subject: RE: Design of unmarshaling sitemap component > > > DURDINA Michal <[EMAIL PROTECTED]> writes: > > > Hi, > > I would like to discuss the design problem of the sitemap > > component. My plan is to develop special let's call it > > transformer for transforming sources for pages written or > > generated by analysts (model) to dynamic pages generating > > required results (implementation). The form of model is > > custom XML according to given XMLSchema and the > > implementation pages should be in form of jxtemplates (or xsp). > > > > The transformation should go like this: > > > > pipeline: > > additional data > >| > > modelXML -> populated modelXML -> computed model -> > jxtemplate source > > > > The intent of the pipeline is to generate executable source > > from model that will generate required dynamic page. The > > trick is that the computed modelXML is not trivial and should > > be implemented as Java OM. > > Wow. You're overall requirements sounds a lot like ours so I'm > interested in how you reached this design? Given your use of > jxtemplate > I can't see that it's performance driven? If not, why not just keep > everything in XML from end to end and use XSLT to derive the computed > model? > > Castor/java implementation issues > > Yes, keeping everything in XML and using XSLT would also realize the transformation. Given that it would involve a XSL stylesheet that will do all the computations. Such a stylesheet would not be easy to write and it will be probably too complex to maintain. Using Java for computation on input XML should be more straightforward and using jxtemplate for outputing the resulting XML gains from clear view how the resulting XML will look like. Performance was not the main requirement as the source generation occures only once and then it is cached although this should perform better than XSLT. I already started the implementation and have first version of such a component implemented as a transformer (case A.). I hope it will meet my requirements and we will profit form this kind of concept. Thank you for comment, Michal
[portal] bookmarks to portlets
Hi, is there any solution how to make a bookmark in PortalEngine to JSR168 portlet? I need to pass a parameter in the bookmark to portlet via url. I know how to do this with coplets (using custom bookmark event that stores parameter to coplet attributes), but I am not sure how to handle this within pure JSR168portlet. 1.) Is there any way how to access coplet (that wraps the portlet) attributes within portlet? Will input module "coplet:attributes" work? 2.) Is there any way how to send a request parameter to selected JSR168portlet via portal url so portlet would be able to read it using portletRequest.getParameter()? This would probably need to engage the same mechanism as the one that is responsible for portlet link generation (PortletURLProviderImpl) - but looking closer at the implementation I wonder if this is possible. Thanks, Michal
RE: [portal] JSR168 portlets problems under PortalEngine
I verified all pending issues and can say that except one they all work correctly now. Remaining issue is http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27518. Thanks for prompt changes in CVS. Michal > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Monday, March 15, 2004 11:39 AM > To: [EMAIL PROTECTED] > Subject: RE: [portal] JSR168 portlets problems under PortalEngine > > > Hi Michal, > > thanks for reporting these two problems! I applied your patch and > fixed the serializer the way you suggested. Could you please verify > and then close the bugs? Thanks > > Thanks > Carsten > > Carsten Ziegeler > Open Source Group, S&N AG > http://www.osoco.net/weblogs/rael/ > > > -Original Message- > > From: DURDINA Michal [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 15, 2004 9:37 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [portal] JSR168 portlets problems under PortalEngine > > > > Hi, > > I found some more issues about running JSR-168 portlets in > > the Cocoon Portal. > > > > 1. There is one serious problem with IncludingHTMLSerializer > > when serializing 2 and more portlets whose are interleaved > > with bigger amount of HTML markup. Serialization is carried > > out in blocks of 8Kb and ReplacingOutputStream.write is > > called after every block is ready. The portlet iterator > > created from the orderedPortletList on the first call of > > writeNext() is later broken by following calls of > > orderedPortletList.add() when more portlets are being added > > to the orderedPortletList at startElement(). As a result the > > java.util.ConcurrentModification exception occurs on the next > > call of valueIterator.next(). > > More at bug description: > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=27657 > > > > 2. Pluto container embedded in Cocoon Portal requires several > > services (SPI) to be implemented by portal. > > PropertyManagerService service is used for setting and > > getting vendor specific information by portlets via > > PortletResponse.setProperty(), but this service is not > > implemented by Cocoon Portal. That would be ok because this > > service is optional but cocoon throws > > CascadingRuntimeException "Unable to lookup service > > org.apache.pluto.services.property.PropertyManagerService > > key" what prevents portlet to be started. > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=27658 > > > > Michal > > > > > > > > > __ Informacia od NOD32 __ > > Tato sprava bola preverena antivirusovym systemom NOD32. > http://www.eset.com > > >
RE: [portal] JSR168 portlets problems under PortalEngine
Hi, I found some more issues about running JSR-168 portlets in the Cocoon Portal. 1. There is one serious problem with IncludingHTMLSerializer when serializing 2 and more portlets whose are interleaved with bigger amount of HTML markup. Serialization is carried out in blocks of 8Kb and ReplacingOutputStream.write is called after every block is ready. The portlet iterator created from the orderedPortletList on the first call of writeNext() is later broken by following calls of orderedPortletList.add() when more portlets are being added to the orderedPortletList at startElement(). As a result the java.util.ConcurrentModification exception occurs on the next call of valueIterator.next(). More at bug description: http://issues.apache.org/bugzilla/show_bug.cgi?id=27657 2. Pluto container embedded in Cocoon Portal requires several services (SPI) to be implemented by portal. PropertyManagerService service is used for setting and getting vendor specific information by portlets via PortletResponse.setProperty(), but this service is not implemented by Cocoon Portal. That would be ok because this service is optional but cocoon throws CascadingRuntimeException "Unable to lookup service org.apache.pluto.services.property.PropertyManagerService key" what prevents portlet to be started. http://issues.apache.org/bugzilla/show_bug.cgi?id=27658 Michal
RE: [portal] JSR168 portlets problems under PortalEngine
...
>
> > 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
[portal] JSR168 portlets problems under PortalEngine
Hi,
I found some problems while running jakarta-pluto testsuite under CocoonPortalEngine.
I would like to report them and offer help if needed.
1. test2.jsp: Call to portalContext.getSupportedWindowStates() returns null.
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.
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.
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)
Michal
RE: [Portal] Question: Why JSR-168 portlet impl moved?
Thanks for pointing me there. Inspite of that, my questions remain: 1. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using Cocoon and using 3rd party portlet container? 2. What was the reason for not moving that code to src/java? Thank you and appologize me :) Michal > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 24, 2004 4:04 PM > To: [EMAIL PROTECTED] > Subject: RE: [Portal] Question: Why JSR-168 portlet impl moved? > > > See: > > http://marc.theaimsgroup.com/?t=10771857645&r=1&w=2 > > Thanks > Carsten > > > -Original Message- > > From: DURDINA Michal [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 24, 2004 3:58 PM > > To: [EMAIL PROTECTED] > > Subject: [Portal] Question: Why JSR-168 portlet impl moved? > > > > Hi, > > I am curious why Carsten moved portlet implementation from > > scratchpad to portal block... I thought JSR-168 portlet > > implementation would go to core. > > > > I think that CocoonPortlet (JSR-168 portlet implementation) > > and portal block are two different things. > > > > CocoonPortlet makes cocoon applications work under portlet > > container (i.e. Jakarta Pluto). > > Portal block IS a portlet container (Portal Engine makes > > environment for coplets and portlets). > > > > So I don't see the reason why to mix these two. > > > > Why must I be dependent on the whole portal block (jar is > > 330kB and will be more) when I want to implement just one > > JSR-168 portlet using cocoon? I supposed that JSR-168 portlet > > implementation would go to core, where other env > > implementations are (Servlet and CLI). What was the reason > > for not doing so? > > > > Thanks, > > Michal > > > > BTW: Tiny patch for CocoonPortal.java is now in Bugzilla #27188 > > > > > > > __ Informacia od NOD32 __ > > Tato sprava bola preverena antivirusovym systemom NOD32. > http://www.eset.com > > >
[Portal] Question: Why JSR-168 portlet impl moved?
Hi, I am curious why Carsten moved portlet implementation from scratchpad to portal block... I thought JSR-168 portlet implementation would go to core. I think that CocoonPortlet (JSR-168 portlet implementation) and portal block are two different things. CocoonPortlet makes cocoon applications work under portlet container (i.e. Jakarta Pluto). Portal block IS a portlet container (Portal Engine makes environment for coplets and portlets). So I don't see the reason why to mix these two. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using cocoon? I supposed that JSR-168 portlet implementation would go to core, where other env implementations are (Servlet and CLI). What was the reason for not doing so? Thanks, Michal BTW: Tiny patch for CocoonPortal.java is now in Bugzilla #27188
