Skip navigation

GateIn

4 Posts authored by: Ken Finnigan

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  This second blog on CDI scopes for GateIn, will cover @PortletRedisplayScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

 

This scope is retained beyond a single Portlet Request lifecycle to be retrieved for all subsequent Render Requests that don't involve an Action or Event. The Beans in this scope are destroyed subsequent Action or Event requests, enabling continual refreshing of the portlet by a user to repeatedly display the same exact content as the Bean data will not be re generated for each Render. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

 

 

Portlet TriggerAction StartAction CompleteEvent StartEvent CompleteRender StartRender CompleteResource StartResource Complete
Portlet ActionX then APPPPP

Portlet Event

X then APPP

Portlet Render



A (if not present)P

Portlet Resource





AX

 

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them.

 

There is one difference with how Resource Request Beans are handled as compared to @PortletLifecycleScoped, in that any Beans that are used during a Resource Request will be merged into the context of the main portlet lifecycle. What this means is that the values on a @PortletRedisplayScoped bean that was used during a Resource Request will replace the contents of the same Bean type for the next Render Request that is executed. In most cases that wouldn't be a problem, but it's a potential gotcha if you make lots of Ajax calls and suddenly wonder why the values in your Beans are all wrong the next time you Render the portlet.

 

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

 

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

 

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

 

With the above dependency we can then create a bean such as:

 

@PortletRedisplayScoped
public class LifecycleBean implements java.io.Serializable {
  ...
}

 

Note that we implement Serializable for our Bean, as the context is stored within the User Session, which can potentially be passivated by the container.

 

As far as CDI is concerned, @PortletRedisplayScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletRedisplayScoped bean, or vice versa.

 

Hope this and the scope we covered in the previous blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  In this first blog on CDI scopes for GateIn, we will cover @PortletLifecycleScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

 

This scope lives for a single Portlet Request lifecycle and is destroyed on completion, meaning that there is no way to guarantee a subsequent Render will generate the same portlet content. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

 

 

Portlet TriggerAction StartAction CompleteEvent StartEvent CompleteRender StartRender CompleteResource StartResource Complete
Portlet ActionAPPPPX

Portlet Event

APPX

Portlet Render



AX

Portlet Resource





AX

 

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them. Any changes to Beans within a ResourceRequest is not retained in any way. This situation is perfect for making Ajax calls from a portlet, so long as the data you're relying on perform the work is accessible from non @PortletLifecycleScoped beans.

 

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

 

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

 

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

 

With the above dependency we can then create a bean such as:

 

@PortletLifecycleScoped
public class LifecycleBean {
  ...
}

 

As far as CDI is concerned, @PortletLifecycleScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletLifecycleScoped bean, or vice versa.

 

Hope this and the scope we cover in the next blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we now have the ability to inject CDI beans directly into our portlet classes, whether they extend GenericPortlet or implement the Portlet interface, and any class that implements a Portlet Filter interface.

 

The injection works just the same as with any other CDI injection, with one small caveat. When deciding which Beans to inject into our portlet or filter, keep in mind that injecting a normal scoped bean, such as @SessionScoped, is fine even though there is no User Session present, because the container will simply inject a client proxy for us, but it's not possible to inject a Bean that is being produced by another Bean that doesn't have a valid context.

 

To explain this with an example, if we take the following portlet class:

 

public class BadPortlet extends GenericPortlet {
  @Inject
  private Greeting myGreeting;
}

 

and create a producer for it such as:

 

@SessionScoped
public class GreetingProducer implements Serializable {
  @Produces
  public Greeting produceGreeting(InjectionPoint point) {
    ...
  }
}

 

We receive a ContextNotActiveException because we're trying to produce one Bean from another Bean that is not yet, as there is no User Session during Portlet Container initialization.

 

When wanting to inject a produced Bean into a portlet class or filter, they need to be produced by @ApplicationScoped or @Dependent scoped Beans.

 

Here's an example portlet showing how we can use CDI injection:

 

public class MyPortlet extends GenericPortlet {
  @Inject
  MyBean bean;

  public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
    PortletRequestDispatcher dispatcher = getPortletContext().getRequestDispatcher("/myPage.jsp");
    request.setAttribute("myBean", bean);
    dispatcher.include(request, response);
  }
}

 

In our JSP we can then access the bean with ${myBean}.

 

I hope that this introduction into creating CDI enabled portlets and portlet filters will make your next portlet a bit easier to use with CDI!

If you haven't already heard through Twitter, the GateIn Cookbook from Packt Publishing was published early November.

 

GateIn Cookbook was co-written by Piergiorgio Lucidi, Luca Stancapiano from Sourcesense and myself.  GateIn Cookbook provides solutions whether you're planning to develop a new GateIn portal, migrate a portal, or only need to answer a specific query. It is filled with bite-sized recipes for quick and easy problem resolution. From the beginning to the end it will guide you through the process of configuring and securing a portal, managing content and resources, and developing applications as you go.

 

GateIn Cookbook contains the following chapters:

  1. Getting Started
  2. Managing Portal Contents Using the GUI
  3. Managing Portal Contents Using XML
  4. Managing Portal Users
  5. Securing Portal Contents
  6. Developing Portlets
  7. Developing Using Components API
  8. Migrating from Existing Portals
  9. Managing Gadgets
  10. Frameworks in a Portal
  11. Managing Portal Resources with the Management Component
  12. Managing Documents Using External ECM Systems

 

Right now we're very happy to offer a 20% discount for the print copy, with coupon code GateInPrint20percentoff, and a 25% discount for the e-book, with coupon code GateInEbook25percentoff!

 

Take advantage of the discounts quickly as they won't be around for long, and happy reading!

 

Ken Finnigan

Portlet Bridge Lead