9 Replies Latest reply on Dec 29, 2005 4:41 PM by Matthew Purdy

    possible bug in portal 2.2

    Matthew Purdy Newbie

      i know jsps/servlets/ejbs well; and have used tomcat and jboss as for a long time. however, i am new jboss portal, and really new to portlets. i started exploring with portlets this month. i started using jboss portal 2.0, and now i am using jboss portal 2.2. do to my ignorance on the subject matter, i am not sure if i discovered a bug in portal 2.0 that was fix in portal 2.2. or a new bug in portal 2.2.

      my env:
      portal 2.0, jboss as 4.0.2, mysql 4.1
      portal 2.2, jboss as 4.0.3, mysql 4.1

      here is was I discovered:

      What was done:
      The TestRequestResponsePortlet sets two message in processAction. The first one "message", uses request.setAttribute; the second one "message2" uses response.setRenderParameter. In doView, thoses two messages are read. The first one "message" is read with request.getAttribute. The second one is read with request.getParameter.

      The results:
      When using JBoss Portal 2.0, both messages are pass thru, however when using JBoss 2.2, only the second one "message2" is passed thru. Since these are strings, response.setRenderParmeter / request.getParameter are fine to use. however, if you need to pass an object other than a string, you have to use the (set|get)Attribute.

      if i am wrong, what ActionRequest/ActionResponse and RenderRequest/RenderResponse methods do i use to pass object from the action to the render in a portlet?


      Here is my test portlet code
      --------------------------------------------------------------------------------
      package test.web.portlet;

      import java.io.*;

      import javax.portlet.*;

      public class TestRequestResponsePortlet extends GenericPortlet
      {

      public void processAction(ActionRequest request, ActionResponse response) throws PortletException, IOException
      {
      request.setAttribute("message", "message from TestRequestResponsePortlet.processAction using request.setAttribute");
      response.setRenderParameter("message2", "message2 from TestRequestResponsePortlet.processAction using response.setRenderParameter");

      }//end method processAction

      public void doView(RenderRequest request, RenderResponse response)
      {
      String message = (String)request.getAttribute("message");
      String message2 = request.getParameter("message2");

      PortletURL actionUrl = response.createActionURL();
      String url = actionUrl.toString();

      response.setContentType("text/html");
      try
      {
      PrintWriter out = response.getWriter();

      out.println("message = " + message + "");
      out.println("message2 = " + message2 + "");

      out.println("click the link below to see the results");
      out.println("<h3><a href=\"" + url + "\">testing request response</h3>");


      out.close();

      }//end try
      catch (IOException e)
      {
      e.printStackTrace();

      }//end catch e

      }//end method doView

      }//end class TestRequestResponsePortletPortlet
      --------------------------------------------------------------------------------

        • 1. Re: possible bug in portal 2.2
          Dan Christopherson Newbie

          You shouldn't count on being able to access attributes set in an actionRequest to be accessable from a renderRequest. The reason for this is that processAaction is only called once for N calls to render, and N-1 of those render calls will be in different HTTPRequests.

          I'm not sure if the portlet spec specifically forbids the behavior you saw in JBoss portal 2.0, but it does mandate that you code for the behavior you saw in JBoss portal 2.2. To illustrate this, run your portlet in 2.0, then hit a url in another portlet on the same page - this time around, your render will be called without your processAction being called and you'll get your string out of the render parameter but not from the attribute.

          • 2. Alternatives to the request.setAttribute? portlet session va
            Matthew Purdy Newbie

            thanx for your replay... new to portlets... didnt think about that... that does make sense:-)

            what is an aternative to the request.setAttribute? should i use the portlet session?

            i.e.
            1) set the portlet session in the action request.
            2) use it in the doView/doEdit/doHelp
            3) when done, delete it in the doView/doEdit/doHelp

            • 3. Re: possible bug in portal 2.2
              Dan Christopherson Newbie

              Yeah, that would work.

              One alternative is to 'marshall' it into render parameters, if it's a relatively simple object. I'm working on an annotations based portlet framework that has that feature. Waiting on signature from my bosses to open source it.

              Another alternative is to refetch within the render, then use the portal and/or hibernate caching to optimize. That's easy to say, but there's a lot of thought required in analysing the cacheing requirements vs. data 'freshness'

              • 4. Re: possible bug in portal 2.2
                Matthew Purdy Newbie

                how would you marshall it into a render parameter?

                futhermore, i have been thinking and doing research:

                i.e.
                what if you have a portlet that read something a datasource in the action request.

                if the connection to the datasource fails you would want to show it in the render (doView/doEdit/doHelp). you may want to pass along the Exception class, which then would be forwarded to the error.jsp page inside the rendering...

                if(request.getAttribute("errorException") != null)
                {
                //pass the message to error.jsp
                }
                else
                {
                //do what you want to with the data from the datasource
                }

                read this from jsr 168: it seems like using the request.(get|set)Attribute is valid???

                ------------------------------------------------------------
                25 PLT.11.1.3 Request Attributes
                Request attributes are objects associated with a portlet during a single portlet request.
                Request attributes may be set by the portlet or the portlet container to express information
                that otherwise could not be expressed via the API. Request attributes can be used to share
                information with a servlet or JSP being included via the PortletRequestDispatcher.
                30 Attributes are set, obtained and removed using the following methods of the
                PortletRequest interface:
                ? getAttribute
                ? getAttributeNames
                ? setAttribute
                35 ? removeAttribute
                Only one attribute value may be associated with an attribute name.
                Attribute names beginning with the ?javax.portlet.? prefix are reserved for definition
                by this specification. It is suggested that all attributes placed into the attribute set be
                named in accordance with the reverse domain name convention suggested by the Java
                40 Programming Language Specification 1 for package naming.

                ------------------------------------------------------------------------

                • 5. Re: possible bug in portal 2.2
                  Konstantin Novoselov Newbie

                   

                  read this from jsr 168: it seems like using the request.(get|set)Attribute is valid???


                  It is valid, but nobody gurantees that render methods would have access to the same instance of request as processAction. doGet use new request object each time you refresh the page or do something with other portlets on the page.

                  You may save your exceptions or other objects in the portlet session to achive desired result.



                  • 6. Re: possible bug in portal 2.2
                    Matthew Purdy Newbie

                    okay, thanx :-)

                    • 7. Re: possible bug in portal 2.2
                      Dan Christopherson Newbie

                       

                      "mpurdy1973" wrote:
                      how would you marshall it into a render parameter?


                      Either decompose it into constituent properties then convert those to strings, or use something like CastorXML to convert to/from XML. The first would really only be workable for a pretty simple, flat bean.

                      • 8. Re: possible bug in portal 2.2
                        Dan Christopherson Newbie

                         

                        "danch" wrote:
                        "mpurdy1973" wrote:
                        how would you marshall it into a render parameter?


                        Either decompose it into constituent properties then convert those to strings, or use something like CastorXML to convert to/from XML. The first would really only be workable for a pretty simple, flat bean.


                        Err, wanted to point out that all this would really do is force the portal container to manage the lifespan of the object in session, rather than the portlet. It'd also be overhead to marshal/demarshal

                        • 9. Re: possible bug in portal 2.2
                          Matthew Purdy Newbie

                          okay, thanx for the info :-)