Hi Roberto, --- On Thu, 5/28/09, Roberto Rossi <roberto.ro...@cone.it> wrote:
> From: Roberto Rossi <roberto.ro...@cone.it> > Subject: Re: velocity context problem > To: "Jetspeed Users List" <jetspeed-user@portals.apache.org> > Date: Thursday, May 28, 2009, 7:40 PM > > 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. What I'm sure of is that VelocityViewServlet creates velocity context object on each request dispatching in its doRequest() method. [1] [1] https://svn.eu.apache.org/repos/asf/velocity/tools/tags/1.3/src/java/org/apache/velocity/tools/view/servlet/VelocityViewServlet.java At least, I believe the velocity context object should be different ones among each request dispatching from portlets. So, I think one possible problem can occur with request. VelocityViewServlet would invoke handleRequest() overriden by BridgesVelocityViewServlet, which receives the newly created velocity context as an argument. So, I don't think the velocity context object can be shared among request dispatchings. > 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? Is it shared between different portal requests? I cannot figure out easily why it happens. Probably I'm stupid to ask this, but do you have any member variable inside your portlet? e.g. context? > > > 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. Oh, so I think we can remove this in the list. :) > > Just one question: the renderRequest object is specific of > the fragment rendering or is shared between all fragments of > a psml page? Yes, the renderRequest is specific of a portlet window. By the way, just one question here: which version of Jetspeed are you using? Woonsan > > > ROb. > > Cone consulting > Business in rete > Via Sandro Totti 7A - 60131 Ancona > Tel 071 9931 269 > Fax 071 9931 270 > eMail roberto.ro...@cone.it > Web www.cone.it > > --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
