> I think it is simply because portlet objects should be accessible from vm
> templates.
> GenericVelocityPortlet stores some additional objects such as renderRequest,
> renderResponse and portletConfig into a temporary context object.
> (In addition, I'm seeing that your portlet is also storing objects into this
> by using getContext().)
> The BridgesVelocityViewServlet retrieves the temporary context object and
> puts its objects into the real velocity context object.
So the context inside portlet is just a temporary one... the
BridgesVelocityViewServlet creates the real velocity context
object to the vm template.
> Because the real velocity context object is created by the
> VelocityViewServlet on every dispatch,
> I don't think the velocity context object could be shared among multiple
> dispatches.
Are you sure of this? What I'm seeing is that some velocity context objects
from one request go to another velocity context of another request.
My simple test case is this:
1) get the fragmentid of the current portlet instance:
- String fragmentid = ((ContentFragment)
request.getAttribute(PortalReservedParameters.FRAGMENT_ATTRIBUTE)).getId();
2) put this fragmentid inside the portlet velocity context:
- context.put("fragid", fragmentid);
During normal tests all objects are inside the right context. But when I
started my stress test (the repeated wget)
my templates are receiveing the wrong fragid (tested using: $fragid).
In Firefox I'm watching the psml called azienda.psml (which has all fragment id
with prefix "azienda-"), my strees test
asks instead for the psml called prodotti.psml (which has all fragment id with
prefix "prodotti-").
During the stress I can see that a context of an azienda.psml template is
receiving a fragid of the prodotti page! Incredible!
>From my tests It seems that the real velocity context are shared between
>different portal requests.
If, inside the portlet, I test the presence of the fragid key in the context
(context.containsKey("fragid")) it seems that there is another object with that
key
coming from another psml page of another request!!! Is this possible? Is there
no isolation between velocity contexts or I wrong something really big?
> However I can guess two possible problems:
> (1) As I mentioned before, objects with same names were stored into request
> or session attributes. So, the velocity context did fallback retrieval.
I checked my code. I never use session attributes and some request attributes
used are of a different kind of objects.
> (2) The current getContext() method of GenericVelocityPortlet is using a
> special request attribute to store/retrieve the temporary context object
> by the name defined in GenericVelocityPortlet.java like the following:
>
> public final static String PORTLET_BRIDGE_CONTEXT =
> "portals.bridges.velocity.context";
>
> So, when a temporary context object is created in the portlet, it is stored
> in the request attributes via 'renderRequest'.
> I'm not sure, but there's a problematic possibility here: what if the
> invocation, 'renderRequest.getAttribute(PORTLET_BRIDGE_CONTEXT)'
> returns other unexpected context object which was set in other portlet in the
> same psml request?
> If you are suspicious on this, I'd like to suggest you override getContext()
> method in your portlet
> and see if it has that kind of problem. (Probably you can use renderRequest's
> hash code for investigation purpose.)
I have overridden the getContext method and printed the hashcode of the context
object.
How can I see if there are problems? I printed it after creating it in the
createPortletVelocityContext method and inside the
"getContext(RenderRequest request)" method and it seems always coherent, even
in heavy load.
Just one question: the renderRequest object is specific of the fragment
rendering or is shared between all fragments of a psml page?
ROb.
Cone consulting
Business in rete
Via Sandro Totti 7A - 60131 Ancona
Tel 071 9931 269
Fax 071 9931 270
eMail [email protected]
Web www.cone.it
