RE: [portal] Need for CachingPortletAdapter
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-devm=110191154925434w=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 pageLabel parameter i.e. portal?pageLabel=Gallerycocoon-portal-event=3 - after adding coplet instance name the link would look like this portal?pageLabel=Gallery.Gallery-Viewercocoon-portal-event=3 - new events for one coplet now don't replace old events for another coplet on the same page C.) add compare method to event interface - before new event is stored to events store compare new event with old events whether same event not already present in the store - if same event is found between old events it will be returned instead of new on and the link will stay the same (index to store does not change) - gradually all links from portal are stored in the events store but there is no duplicate and the indexes to events are preserved between requests D.) name one :) I find the case A.) is little bit harder to implement but it was my first thought :-) case B.) is nice and clean way how to prevent that events for cached portlet without focus will not be overriden by currently focused coplet case C.) is only one that also allows the browser back button to work properly because repeated http requests will invoke same action as the event will be still alive in the store. Of course, internal coplet states are not taken into account. This simplified view solves only situation when coplet state is maintained exclusivelly through request parameters. I would like to know, if anyone has any preference to one or other solution. Also all cases can have some issues that am not aware of and I would be happy if you could also point them out. Thank you, Michal
RE: [portal] Need for CachingPortletAdapter
-Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [portal] Need for CachingPortletAdapter URDINA Michal wrote: Hi, currently provided PortletAdapter does not offer caching ability for JSR168 portlets. I really need caching for portlets and I wanted to implement this feature as new CachingPortletAdapter. Having looked at URICopletAdapter and CachingURICopletAdapter the caching implmentation for coplets is pretty simple. CachingURICopletAdapter relies on these principles: - coplet content is XML - coplet content it is cached/emited in the generator of portal generating pipeline - links are cached untranslated and the link translation occurs in the transformer that follows generator PortletAdapter relies on these principles: - portlet content is not XML (however it is often XHTML) - portlet content is emited in serializer of portal generating pipeline - links are translated in the portlet generation and are part of portlet content 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. Has anyone been thinking about the caching of content for JSR168 portlets? I would be happy if we could come to common solution that could be consequently implemented. No, I haven't been thinking of it, but it seems like it would be a good thing. I'd welcome a proposal and/or code. Michal Ralph 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? Michal
[portal] deprecation of request data store
This mail refers a bit to my previous thread Sharing cocoon.jar between multiple web
aplications
http://marc.theaimsgroup.com/?t=10946512153r=1w=2
I have problem with portal engine running in ear bundled with other portlet webapps
when all libraries are on ear level. I get NPE when portlet is resolving its
portlet-url via
PortletURLProviderImpl.toString() -
PortalServiceImpl.getComponentManager() -
PortalServiceInfo.getInfo() -
PortalInfo.getComponentManager() - returns null !
I am using the cocoon-2.1.5 release and the code in PortalServiceImpl has changed
since then in CVS
from version 1.10:
protected PortalServiceInfo getInfo() {
PortalServiceInfo info = (PortalServiceInfo)
this.dataStore.getRequestData(this.key);
if ( info == null ) {
info = new PortalServiceInfo();
info.setup(ContextHelper.getObjectModel(this.context),
this.portalComponentManagers);
this.dataStore.setRequestData(this.key, info);
}
return info;
}
to version 1.12 (CVS comment CZ: Deprecate request data store and remove it's use in
the portal):
protected PortalServiceInfo getInfo() {
final Request request = ContextHelper.getRequest( this.context );
PortalServiceInfo info = (PortalServiceInfo) request.getAttribute(this.key,
Request.GLOBAL_SCOPE);
...
}
I would like to know what was the reason for this change and if it would solve the
problem I described upper.
In that case I would like to make a patch that would make those changes applicable for
cocoon 2.1.5 release. But the change introduced the use of feature new to
cocoon-2.2.0-dev core - request.getAttribute(this.key, Request.GLOBAL_SCOPE). Will it
be feasable to backport all this functionality back to cocoon 2.1.5? Or you would
advise another solution.
Thank you,
Michal
---
Michal urdina
ASSET Soft, a.s. / eBussiness Solutions
Koick 56, 821 08 Bratislava SLOVAK REPUBLIC
Phone: +421-2-50703-523
Fax: +421-2-50703-444
e-mail: [EMAIL PROTECTED]
http://www.assetsoft.sk
Nightly builds for SVN WAS: [portal] deprecation of request data store
-Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Friday, September 10, 2004 12:58 PM To: [EMAIL PROTECTED] Subject: Re: [portal] deprecation of request data store URDINA Michal wrote: In that case I would like to make a patch that would make those changes applicable for cocoon 2.1.5 release. But the change introduced the use of feature new to cocoon-2.2.0-dev core - request.getAttribute(this.key, Request.GLOBAL_SCOPE). Will it be feasable to backport all this functionality back to cocoon 2.1.5? Or you would advise another solution. Have you checked in 2.1.X branch? It might have the fix you are looking for. http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ Vadim NO, because I am relly stuck behind the firewall. I rdiffed branch BRANCH_2_1_X with RELEASE_2_1_5 in cvs and found no changes assuming that all changes are done only in subversion. For SVN I wanted to use our httpproxy (squid) but it is configured not to allow extended http methods that svn use and I have no impact on its configuration. So I wanted to download snapshot from http://cvs.apache.org/snapshots/cocoon-2.1/ but then I realized that it would probably doing only HEAD snapshots and only from CVS. Where is the location for nightly built snapshots of cocoon-2.1.6-dev ? Can I command svn client not to use HTTP extended methods? Does it exist any tool like cvsgrab for svn? Thank you, Michal
RE: Sharing cocoon.jar between multiple web aplications
-Original Message- From: peter royal [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 8:32 PM To: [EMAIL PROTECTED] Subject: Re: Sharing cocoon.jar between multiple web aplications On Sep 8, 2004, at 11:17 AM, URDINA Michal wrote: The problem arise only when one web application calls other web application to generate its output (via getRequestDispatcher.include() - crosscontext must be enabled). Then both webapps use the same static field instance in the same thread. And if both are calling method on the same class i.e. Cocoon.process(), then called web application can rewrite the value saved by calling web application. ah, gotcha. why not just put cocoon.jar per-webapp then, and put the rest of the deps at the ear level? :) -pete Yes, thats solves the problem partially. Instead of duplicating 15MB of libraries, I will be duplicating only about 2,5MB of cocoon libraries and libraries that are dependent on cocoon libraries. I.e. castor.jar must be moved back from ear to WEB-INF/lib to see cocoon classes needed for xml unmarhsalling. I tried to fix the static ThreadLocal fields on my own and it resulted to change only in Cocoon.java to remove checkEnvironment() method. Static field in other classes did not affect me either because they are in blocks that we do not use or I am sure that they won't be multicalled in one request (i.e. portal-block classes). Here is the list of them anyway (cocoon-2.1.5 release): grep -d -l ThreadLocal *.java File blocks\batik\java\org\apache\cocoon\components\url\SourceProtocolHandler.java: File blocks\portal\java\org\apache\cocoon\portal\impl\PortletPortalManager.java: File blocks\portal\java\org\apache\cocoon\portal\serialization\IncludingHTMLSerializer.java: File blocks\portal\java\org\apache\cocoon\portal\util\ReferenceFieldHandler.java: File blocks\portal-fw\java\org\apache\cocoon\webapps\portal\context\SessionContextImpl.java: File blocks\scratchpad\java\org\apache\cocoon\ant\AntBuildGenerator.java: File java\org\apache\cocoon\components\CocoonComponentManager.java: File java\org\apache\cocoon\components\treeprocessor\variables\VariableResolverFactory.java: From those all these are not affected by multicall problem because: PortletPortalManger - there is not read of the static ThreadLocal copletInstanceData; VariableResolverFactory - detto - no read of static ThreadLocal disposableCollector; CocoonComponentManager - immune because of the use of threadlocal stack of variables instead of threadlocal variable IncludingHTMLSerializer - no conflict because this class is called by only on webapp (or at least it is very unlikely to be called more than one in one request) ReferenceFieldHandler - detto - no conflict So all I needed to change was Cocoon.java. I have not tested this thorougly so I cannot say if it really works correctly yet. But I still would be for using static fields only with special care and with handling against webapp multicall (on webapp includes other) problem i.e. as CocoonComponentManager does with threadlocal stack and proper cleaning before return. Michal
RE: Sharing cocoon.jar between multiple web aplications
I am using cocoon-2.1.5 release. I will try to replece Cocoon.java from CVS HEAD. Thanks for pointing me there. Michal -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 12:21 AM To: [EMAIL PROTECTED] Subject: Re: Sharing cocoon.jar between multiple web aplications URDINA Michal wrote: The problem arise only when one web application calls other web application to generate its output (via getRequestDispatcher.include() - crosscontext must be enabled). Then both webapps use the same static field instance in the same thread. And if both are calling method on the same class i.e. Cocoon.process(), then called web application can rewrite the value saved by calling web application. IIRC, this particular problem you are describing are resolved in CVS. When last time you had updated your snapshot? Vadim
Sharing cocoon.jar between multiple web aplications
Hi,
I created ear file with about 6 war files. All war files are cocoon web applications
and thus have same WEB-INF/lib directories. The ear file has apx. 100MB due to
duplicity of libraries in WEB-INF/lib's. It seems reasonable to me to pull up those
duplicit libraries at ear level and share them among web applications.
But I'm stuck with the use of static ThreadLocal class fields in some cocoon classes.
Good example is CocoonComponentManager.environmentStack:
this static field is used in methods
- enterEnvironment()
- leaveEnvironment()
which are call on every request process by Cocoon.process() method:
process(Environment environment) {
try {
CocoonComponentManager.startProcessing(environment);
CocoonComponentManager.enterEnvironment(environment,
this.componentManager, this); // - environmentStack.push
...
finally {
CocoonComponentManager.leaveEnvironment();
// - environmentStack.pop
CocoonComponentManager.endProcessing(environment, key);
}
CocoonComponentManager.checkEnvironment(getLogger());
Providing that CocoonComponentManager class is located in WEB-INF/lib, we have no
problem, because every webapp gets its own class loader that creates its local
instance of static field. This field is then used only by proper webapplication and in
the threadsafe manner. But if we move CocoonComponentManager to ear level and share
this class among more than one web application, we break the contract, because only
one instance of this static field will be created for all web applications. When we
consider that one application can call other one, then we can see this not working,
because multiple web aplications will be writing the same instance of the static
field. The example is CocoonComponentManager.checkEnvironment() which throws exception
when environmentStack is not empty.
The problem can be even more visible in portlet environmnet (our environment in use),
when portlet container - webapp #1 is allowed to call portlets - webapp #2-#n)
parallelly in separate threads.
That's why the use of static ThredLocal class fields should be prohibited in all
cocoon component classes. There must be some alternative for it.
WDYT?
Call of CocoonComponentManager.checkEnvironment in Cocoon.process() is marked as
// TODO (CZ): This is only for testing - remove it later on
CocoonComponentManager.checkEnvironment(getLogger());
Isn't this the proper time to remove it? Or at least to have a possibility to disable
this check?
Thank you,
Michal
Attch: classes using the ThreadLocal static field:
src\blocks\scratchpad\java\org\apache\cocoon\ant\AntBuildGenerator.java
src\javaorg\apache\cocoon\components\CocoonComponentManager.java
src\blocks\portal\java\org\apache\cocoon\portal\serialization\IncludingHTMLSerializer.java
src\blocks\portal\java\org\apache\cocoon\portal\impl\PortletPortalManager.java
src\blocks\portal\java\org\apache\cocoon\portal\util\ReferenceFieldHandler.java
src\blocks\portal-fw\java\org\apache\cocoon\webapps\portal\context\SessionContextImpl.java
src\blocks\batik\java\org\apache\cocoon\components\url\SourceProtocolHandler.java
src\java\org\apache\cocoon\components\treeprocessor\variables\VariableResolverFactory.java
RE: Sharing cocoon.jar between multiple web aplications
-Original Message- From: peter royal [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 4:03 PM To: [EMAIL PROTECTED] Subject: Re: Sharing cocoon.jar between multiple web aplications On Sep 8, 2004, at 9:44 AM, URDINA Michal wrote: I created ear file with about 6 war files. All war files are cocoon web applications and thus have same WEB-INF/lib directories. The ear file has apx. 100MB due to duplicity of libraries in WEB-INF/lib's. It seems reasonable to me to pull up those duplicit libraries at ear level and share them among web applications. But I'm stuck with the use of static ThreadLocal class fields in some cocoon classes. I do this without any ill effects.. If the static's weren't ThreadLocals, there would be a problem.. But since they are ThreadLocals, each webapp is still isolated, because you'll only have one thread-per-request at a time. -pete The problem arise only when one web application calls other web application to generate its output (via getRequestDispatcher.include() - crosscontext must be enabled). Then both webapps use the same static field instance in the same thread. And if both are calling method on the same class i.e. Cocoon.process(), then called web application can rewrite the value saved by calling web application. The processing goes like this (all on the same thread): webapp#1: set value call webapp#2 webapp#2: set value doSomething get value return webapp#1: doSomething get value return webapp#1 gets the value saved by webapp#2 and that's not ok:) Michal
Design of unmarshaling sitemap component
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. What I need to involve is conversion from XML to
Java Object, make the computation in Java and go back with the results to XML in form
of jxtemplate source.
I have two alternatives of implementation. Both are involving castor for converting
XML to Java object.
A.) make the XML2Java conversion in transformer
pipeline:
file(modelXML) - cinclude(aditionaldata) - castortransformer(modelClass, template) -
- jxtemplatetransformer - jxtemplate (or xsp) source
|
modelInstance
This starts with reading modelXML from file, including additional data (i.e. in form
of another xml document). Populated XML is then the source for Castor unmarshaling,
the intermediate result is the instance of modelClass placed on request attribute. The
transformer then emits the template given in second parameter. The modelInstance is
used in template and jxtemplatetransformer is used to generate required page source
(jxtemplate again or xsp).
B.) make the XML2Java conversion in action:
pipeline1:
action(cocoon:/pipeline2, modelClass) {
jxtemplategenerator(template) - jxtemplate (or xsp) source
|
modelInstance
}
pipeline2:
file(modelXML) - cinclude(aditionaldata) - XML
This is simmilar to A.) but with the exception that this does not break the SAX stream
in castortransformer and XML2Java conversion is done between two pipelines. On the
other hand there is useless serialization and deserialization between both pipelines.
There is question about which approach is better from the design point of view.
Additional questions include:
- in case of A.) is it better to have modelXML on the start of the pipeline and
template as the parameter or to have template at the start of the pipeline and
modelXML as the parameter?
- are there any other viable and simple alternatives?
Thank you for your comments.
Michal
[Portal] future and design questions
Title: [Portal] future and design questions Hello! Right now I am in process of evaluating available portal solutions. Because I am big cocoon enthusiast I took a deeper look into the cocoon portal-fw and portal blocks. I would try to summarise the main features I found when played with both portal-framework and portal engine. Please correct me if I am wrong: - both solutions aim mostly to implement portlet container capabilities - both solutions are quite similar from the view of sitemap configuration and coplet features - coplets provide XML feeds and are realized by sitemap pipelines (local) or by accessing any source in the internet (defined by uri) - authentification is done by authentification-fw but this is not required as this can be replaced by other solution i.e. by container managed security (http://marc.theaimsgroup.com/?l=xml-cocoon-dev=106703524221219=2) - user's settings are stored in files (by means of sourcewriter transformer) but they can be persisted by any data store by means of specialized transformers - final HTML look is created by xsl stylesheet applied after syndicating all coplets in layout template - other clients (PDA, WAP) can be handled by applying different xsl stylesheet and targeting required markup - JSR-168 portlet container behaviour will be implemented in portal-engine block to support 3rd party portlet implementations I still have some questions where I am not sure about answers: - what will be (or is) the main difference of current portal-framework and new portal engine? What were the main issues that caused rewrite of existing portal-fw to portal engine? - what exactly will be implemented from JSR-168 spec to portal engine, what components will then be still used from cocoon? - what future do you see for cocoon as a portal framework when JSR-168 compliant containers will come out (i.e. Jakarta Pluto) and what part of portal application lifecycle should then cocoon cover? Thanks for your answers and for good job done on cocoon! Michal -- MisoD -- Michal Durdina - [EMAIL PROTECTED] ASSET Soft a.s., Kosicka 56, Bratislava, 821 08 Slovakia, Europe
RE: [Portal] future and design questions
Title: RE: [Portal] future and design questions (resending because of some delivery problems) Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Sent: Monday, October 27, 2003 11:57 AM To: [EMAIL PROTECTED] Subject: RE: [Portal] future and design questions URDINA Michal wrote: Hello! Right now I am in process of evaluating available portal solutions. Because I am big cocoon enthusiast I took a deeper look into the cocoon portal-fw and portal blocks. The portal block is a newer implementation that is in general more flexibel than the old one but currently lacks for example administration tools etc. I would try to summarise the main features I found when played with both portal-framework and portal engine. Please correct me if I am wrong: - both solutions aim mostly to implement portlet container capabilities - both solutions are quite similar from the view of sitemap configuration and coplet features - coplets provide XML feeds and are realized by sitemap pipelines (local) or by accessing any source in the internet (defined by uri) - authentification is done by authentification-fw but this is not required as this can be replaced by other solution i.e. by container managed security (http://marc.theaimsgroup.com/?l=xml-cocoon-dev=106703524221219=2) Yes, but this is only true for the portal block; the portal-fw block is tied to the authentication-fw. Although it is possible with some trick to use a different approach with the portal-fw as well. - user's settings are stored in files (by means of sourcewriter transformer) but they can be persisted by any data store by means of specialized transformers - final HTML look is created by xsl stylesheet applied after syndicating all coplets in layout template - other clients (PDA, WAP) can be handled by applying different xsl stylesheet and targeting required markup - JSR-168 portlet container behaviour will be implemented in portal-engine block to support 3rd party portlet implementations I still have some questions where I am not sure about answers: - what will be (or is) the main difference of current portal-framework and new portal engine? What were the main issues that caused rewrite of existing portal-fw to portal engine? Mainly flexibility, like choosing different authentication mechanism etc and implementing the JSR-168 which will only happen for the portal block (unless someone steps in and does it for the portal-fw as well, which would be very very tricky). - what exactly will be implemented from JSR-168 spec to portal engine, what components will then be still used from cocoon? Good question, I'm wondering this myself these days :) Now, currently the JSR-168 defines only portlets, but not the portlet container itself (only part of the behaviour of the container), so it might be that the portal engine of Cocoon stays the same. But you will have the abilitiy to use a JSR-168 portlet instead of a pipeline. - what future do you see for cocoon as a portal framework when JSR-168 compliant containers will come out (i.e. Jakarta Pluto) and what part of portal application lifecycle should then cocoon cover? I honestly don't know - this is something the users will decide. Now, I hope that the cocoon portal engine will be JSR-168 compliant as well (soon), so when developing portlets it doesn't matter if you choose Cocoon or Pluto or Jetspeed or whatever. At least that's the theory which I think will not always be the practice: When you develop a portlet you need functionality and in some cases you find this functionality in your portlet container (in Cocoon, in Jetspeed etc.) and you will use this. From that point on you're tied to that container. But the JSR-168 helps here a lot. Anyway, personally, I think Cocoon is a good base for portal applications as it provides so many good concepts, like the avalon based architecture, the sitemap, the processing pipelines, flow, blocks (with 2.2), form handling frameworks etc that make developing complex applications alot easier
