Portlet Community
  
 
java.net > Community > Portlet >

 

JSR 168 FAQ



Table Of Contents

  1. Basic FAQ
  2. Developer FAQ
  3. Resources
    4.



Basic FAQ

  1. What is a portal ?


    2. A portal can be best described as a web site that acts as a "point of entry" or a gate to a larger system. While it seems pretty difficult to define a portal in the strictest sense, these are some of the common features of portals:

    • Content aggregation:

      Portals tend to aggregate content from multiple, disparate sources and provide one unified view of the same.

    • Personalization:

      This refers to the ability of the portal to tailor the content/services that it offers according to the user of the portal.

    • Search:

      Most if not all portals, offer some form of searching of it's content and sometimes even content from external sources.

    • Single Sign On:

      Allows users to authenticate once to the portal and thereby allows access to many other systems without the need for reauthentication.


  2. Do I need a portal server to build a portal ? What is a portal server ?


    3. No, you don't. You can build a portal using any web based technology: J2EE, Dot Net , PHP or plain old CGI.

    A portal server however provides a base infrastructure for rapidly developing/deploying portals. It also provides, out of the box implementations of most of the services that any portal would require.


  3. What is a JSR 168 Portlet ?


    4. Prior to JSR 168, almost all portal platforms offered their own proprietary approach to create pluggable components. For example, IBM had IBM portlets, Sun(iPlanet) had Providers, SAP had iViews and Plumtree had Gadgets. TBD


  4. What are the benefits of JSR 168?


    5. Portal integration components based on the new standard will enable interoperability independent of the portal vendor solution -- and enable enterprises to more easily use portal platforms for the secure delivery of personalized Web services and aggregated content between multiple internal and external portal deployments.

    • For Developers:
      The new standard will allow developers to reuse existing integration methods for faster addition of data, applications, and services from multiple back-end sources. Developers and independent software vendors (ISVs) will benefit from reduced development time and cost since the specification is based on Java APIs and extends J2EE capabilities to portals.
    • For Customers:
      Enterprises will benefit from greater efficiency and ROI since personalized, aggregated content can be delivered from portal platforms to end-users from a multitude of sources previously difficult to integrate.
    • For Integrators:
      Integrators will have an easier time integrating and aggregating content for their Portal customers, facilitating the delivery of web services.

  5. What is a portlet container and where will I find one?


    6. A portlet container runs portlets and provides them with the required runtime environment. A portlet container contains portlets and manages their lifecycle. It also provides persistent storage for portlet preferences. A portlet container receives requests from the portal to execute requests on the portlets hosted by it.

    A portlet container is not responsible for aggregating the content produced by the portlets. It is the responsibility of the portal to handle the aggregation.

    A portal and a portlet container can be built together as a single component of an application suite or as two separate components of a portal application.


  6. Do I need a portal server to deploy/test my portlets?


    7. Yes, Portlets only generate markup fragments, not complete documents. The Portal aggregates portlet markup fragments into a complete portal page. Also,Portlets are not directly bound to a URL and so web clients interact with portlets through a portal system.



Developer FAQ

  1. Can I get the HttpServletRequest from Portlet?


    2. The PortletRequest object is supposed to give you everything you need.. e.g. parameters, attributes, dispatching, etc. As per the spec, you should not need the HttpServletRequest.

    Although, different portlet-container implementation provide some kind of hack to get hold of HttpServletRequest. e.g. in Pluto you can cast the RenderRequest to HttpServletRequest as (HttpServletRequest)plutoRenderRequest ... BUT, be aware that it will introduce dependency on Pluto, which is against spirit of the spec.


  2. Can I use session in portlets?


    3. Yes, the specification defines a PortletSession interface that allows a portal/portlet-container to use any of the session tracking approaches (such as HTTP Cookies, SSL Sessions or URL rewriting) to track a user’s session. The PortletSession interface defines two scopes for storing objects, APPLICATION_SCOPE and PORTLET_SCOPE.

    Use APPLICATION_SCOPE, if you want to access attributes which have been placed within the session in external resources like your servlet. While the portlet scoped attributes, although available to other resources, are used for attributes that are meant for the portlets use only.


  3. What's difference between PortletConfig.getInitParameter() and PortletContext.getInitParameter()?


    4. Context-wide init-params share the same context space as Servlets and JSPs belonging to the same application and they are defined in the web.xml file. You can get them using PortletContext.getInitParameter() method.

    Portlet-wide initialization parameters on the other hand belong in the portlet.xml file and you can get them using PortletConfig.getInitParameter() method.


  4. How can I set/retrieve a cookie from a portlet?


    5. No you cant.There is no direct way to set/retrieve a cookie value from a portlet.

    Cookies are used a mechanism for session tracking. The portlet specification does not mandate the portal server to use any particular session tracking mechanism. In fact, the portal server is free to use whatever mechanism it chooses: Cookies, URL rewriting, Https Sessions etc. Portlet developers are expected to use the PortletSession object and leave it to the portal server to deal with the underlying mechanism.


  5. Can I set a cookie from an included Servlet/ JSP ?


    6. This will not work. The Portlet Spec (PLT 16.3.3) mandates that the addCookie() call on an included Servlet or JSP does no operation. If this does work on some containers, then it should be considered a bug and should not be relied upon.


  6. Is there a hack to get/set cookies ?


    • PortletRequest Properties:

      The getProperties() method of the PortletRequest would return the HTTP headers, if available. This can be used to retrieve the cookie values in most containers. This behavior cannot be relied upon as there might be circumstances where they are unavailable.

    • Javascript:

      You can embed javascript functions in a JSP page and include that JSP in your response. In the javascript, you can have code that can set/retrieve cookies and if needed, pass it over to the portlet


  7. How do I achieve inter-portlet communication ?


    8. Inter-portlet communication refers to the ability by which portlets can communicate with each other in a spec compliant way. There are currently two approaches to achieve inter-portlet communication. The exact approach you choose would depend on the problem you are trying to address

    • Using the PortletSession:

      A PortletSession is created for each user per portlet application. This makes the PortletSession useful for communicating all user related information among different portlets in the same portlet application.

      When you set attributes in a PortletSession you have two options: To use a PORTLET scope (this is the default) or to use an APPLICATION scope. If you want the particular attribute to be shared among portlets, you need to use the APPLICATION scope.

      For example, consider CityPortlet and WeatherPortlet, two portlets in the same application.

      In processAction() of CityPortlet

      portletSession.setAttribute("cityName", newCityName, PortletSession.APPLICATION_SCOPE);

      In the WeatherPortlet, you can retrieve the changed city name by getting it from the PortletSession:

      In doView() of WeatherPortlet

      currentCityName=(String)portletSession.getAttribute("cityName",PortletSession.APPLICATION_SCOPE);
      showWeatherForThisCity(currentCityName);

      Pretty simple, but here is a caveat.The portlet spec does not mandate any order in which the doView() (or for that matter doEdit() or doHelp() ) be called for multiple portlets on the same portal page. This means if you were to set an attribute in the doView() method of CityPortlet you may or may not get the attribute in the doView() of WeatherPortlet (depending on the portal server and perhaps the layout that you are using).The spec, however, does mandates that the processAction() be called before any rendering method is called. Therefore you need to ensure that any state change that needs to be propagated across multiple portlets in the same portlet application is confined to the processAction() method.

    • Using the PortletContext:

      A PortletContext (very similar to a ServletContext) is shared between all users and all portlets in a portlet application.You can get and set attributes from the PortletContext and this can be used as a global point of communication.

      For example, if the WeatherPortlet uses a webservice which is currently unavailable. You might have code like this:

      In doView() of WeatherPortlet

      if(portletContext.getAttribute("errorMessage") != null) {
          displayErrorMessage();
      }

      In this case, all instances of WeatherPortlet irrespective of which user is seeing it, would see the error message.ADD TOM'S FEEDBACK


  8. What if I need two portlets from two different portlet applications to communicate with each other ?


    9. This situation occurs rarely and if it does, you may need to review your packaging structure. Do you really want to couple two unrelated portlets? If they are dependent wouldn't you rather package them in the same application?

    If you still need the portlets to communicate, you will have to use some other standard J2EE communication mechanisms like JNDI , Database with JDBC, messaging through JMS etc

Back to Menu