PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-33675

Include the HttpServletResponse in the velocity context of velocity templates

    Details

    • Similar Issues:
      Show 5 results 

      Description

      In the method VelocityVariablesImpl.java#insertVariables(VelocityContext, HttpServletRequest) the HttpServletRequest is added to the velocityContext:

      VelocityVariablesImpl.java
      public void insertVariables(VelocityContext velocityContext, HttpServletRequest request) throws Exception {
          // Request
          velocityContext.put("request", request);
      ...
      

      Please also add the HttpServletResponse to the same velocityContext. Use cases:

      1. from a velocity template (i.e. .tpl or .vm file) we would be able to force some response headers
      2. only with a response object we can perform redirect and forward
      3. many other use cases if we have access to the methods of a response object

      The current workaround is to create a ServicePreAction hook (i.e. servlet.service.events.pre) and add the response object to the request as an attribute:

      MyServicePreAction.java
      ...
      public void run(final HttpServletRequest request, final HttpServletResponse response) {
          request.setAttribute("response", response);
      }
      ...
      

        Activity

        Hide
        Olaf Kock added a comment -

        Velocity templates are the wrong place to implement the given usecases (at least 1 and 2 - 3 is too generic). Reason is that during execution of the templates, the headers might already be committed to the client, causing an exception upon setHeader, setCookie or other operations. Velocity does not handle exceptions, so an implementation of this feature might result in catastrophic failure (e.g. no content, no error message) but imply that you could make use of the response object in templates, which you can't.

        ServicePreAction might be a better place for setting headers, but there might be even better places, depending on the usecase. Any header must be set before the response is ever committed and sent to the browser. And typically you have nothing to say in when this happens: Your suggested workaround might work today on your appserver, but it might not work with the next update to your appserver when timing changes slightly.

        Suggesting to close as "Won't Fix" for this reason.

        Show
        Olaf Kock added a comment - Velocity templates are the wrong place to implement the given usecases (at least 1 and 2 - 3 is too generic). Reason is that during execution of the templates, the headers might already be committed to the client, causing an exception upon setHeader, setCookie or other operations. Velocity does not handle exceptions, so an implementation of this feature might result in catastrophic failure (e.g. no content, no error message) but imply that you could make use of the response object in templates, which you can't. ServicePreAction might be a better place for setting headers, but there might be even better places, depending on the usecase. Any header must be set before the response is ever committed and sent to the browser. And typically you have nothing to say in when this happens: Your suggested workaround might work today on your appserver , but it might not work with the next update to your appserver when timing changes slightly. Suggesting to close as "Won't Fix" for this reason.
        Hide
        Olaf Kock added a comment -

        If there are no other usecases that would justify implementing this feature, I'd still like to close this issue as "Won't fix" if nobody objects. Reasons given in the previous comment - implementation of this issue would break basic assumptions and be (at best) fragile in the different supported environments. The proposed solution is a hack, not guaranteed to work.

        Show
        Olaf Kock added a comment - If there are no other usecases that would justify implementing this feature, I'd still like to close this issue as "Won't fix" if nobody objects. Reasons given in the previous comment - implementation of this issue would break basic assumptions and be (at best) fragile in the different supported environments. The proposed solution is a hack, not guaranteed to work.
        Hide
        Remis Baima added a comment -

        I am OK with Olaf's suggestion.

        Show
        Remis Baima added a comment - I am OK with Olaf's suggestion.

          People

          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              31 weeks, 3 days ago

              Development

                Structure Helper Panel