Very interesting.
I tend to agree with you that the
PortletRenderingInitiationStAXComponent implementation should say *not*.
If it helps the PortletRenderingInitiationStAXComponent implementation
was from 9/16/10 and 10/20/10, and the WindowStateSettingsStAXComponent
implementation was from 2/1/12 (logical since mUniversality was a later
implementation).
I glanced at some of the other classes implementing that method and it
is not entirely clear to me what the answer is to your question. For
instance, DTDSettingPipelineComponent and
PortletRenderingIncorporationComponent (though it has a todo comment
about the cache keys) simply return the wrapped component's cache key?
If they modify the stream perhaps they shouldn't? (I could see
PortletRenderingIncorporationComponent perhaps not if it's the final
step). However StAXAttributeIncorporationComponent builds a new cache
key (looks like the only component that does that besides
XSLTComponent). I guess I don't quite understand the code enough at
this stage to provide a more concrete opinion. :-(
James Wennmacher - Unicon
480.558.2420
On 11/14/2014 06:20 AM, Andrew Petro wrote:
uPortal developers,
Can you help me triage a potential bug?
uPortal has a rendering pipeline with segments called components.
Those components do stuff (transform the content flowing through the
pipe), and they also do meta-stuff (e.g., computing cache keys to
allow short circuiting expensive doing of stuff).
One of the components does the stuff of firing off portlet rendering.
It doesn't believe that **the initiating of external portlet rendering
threads** changes the actual content flowing through the pipe (the
content will change later in the pipeline when the placeholders are
replaced with the content so rendered), and so it does not change the
cache key from that reported by the preceding component in the pipe.
public CacheKey getCacheKey(HttpServletRequest request,
HttpServletResponse response) {
//Initiating rendering of portlets will change the stream at all
return this.wrappedComponent.getCacheKey(request, response);
}
( link to that code on GitHub: http://goo.gl/hDhxM1 )
I think that comment should be "will NOT change the stream at all".
But here's where it gets interesting.
In WindowStateSettingsStAXComponent
public CacheKey getCacheKey(HttpServletRequest request,
HttpServletResponse response) {
//Initiating rendering of portlets will change the stream at all
return this.wrappedComponent.getCacheKey(request, response);
}
(Link to code on GitHub: http://goo.gl/P0MIpt )
Looks like a copy-and-paste with that same broken comment. And while
where it was copied from was about firing off external threads and not
changing the content flowing through the pipe,
WindowStateSettingsStAXComponent is about changing the content flowing
through the pipe (tweaking the window states of channel elements).
So, does that mean it should be doing something other than its current
behavior of returning the wrapped component's cache key?
Kind regards,
Andrew
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
