Wednesday, December 08, 2010

Oracle Fusion Metadata Repository

What does Oracle Fusion Metadata Reposity hold fro you?
Metadata Repository - contains metadata for Fusion Middleware Components (SOA, Webcenter, Identity Management). Repository could be Database-based or File-based, most components (Webcenter, SOA, OID…) require Database-based Repository.


How to create Database-based repository ?
RCU - Repository Creation Utility is the tool to create schema and load repository in existing database for Fusion Middleware components.


RCU creates default schema and load repository in default tablespaces. RCU provides flexibility to change schema or tablespace name. (Only exception to this is Oracle Internet Directory (OID) schema). You could load multiple repository (like Portal, webcenter, SOAINFRA) in single database. This interesting feature is you could load different version of same repository (like dev_soainfra, test_soainfra for DEV & Test instance.) in same database for multiple Fusion Middleware Instances.



How to run RCU?

RCU can be run in two modes - GUI (Graphical User Interface) & CLI (Command LineInterface). For Fusion Middleware 11g R1 (11.1.1.X) or higher , RCU can only load schema in Oracle Database (version 10.2.0.4 and higher or 11.1.0.7 and higher). It can be run locally (same machine with Database) or Remotely(Database is on remote machine).

RCU (Repository Creation Utility) can be run from $RCU_SOFTWARE/bin/ rcu (for Unix) or rcu.bat (for Windows) ; This will start RCU in GUI mode. For CLI mode use “rcu [-silent | -interactive] { }”.

RCU log is written to the RCU_SOFTWARE_DIR/ rcu/ log/ logdir./rcu.log.

There are various types of Repository:
  1. Metadata Services (MDS)
  2. Audit Services (IAU)
  3. Oracle Internet Directory (OID)
  4. Single Sign-On (SSO)
  5. SOA Infrastructure (SOAINFRA)
  6. Business Activity Monitoring (BAM)
  7. User Messaging (ORASDPM)
  8. Oracle WebCenter (WEBCENTER)
  9. WebCenter Portlets (PORTLETS)
  10. Oracle Content Server (OCSERVER)
  11. Portal (PORTAL)
  12. Discoverer (DISCOVERER)
  13. Oracle Identity Federation (OIF)
  14. Discussions (DISCUSSIONS)
  15. Wiki and Blog (WIKI)

Tuesday, November 30, 2010

Oracle SOA Suite 11gR1 PS2 Installation Traps

1. SOAINFRA user issue
In the domain creatioin, the environment check will report can not find the SOAINFRA user in schema_version_registry.

Error Message:

Component Schema=SOA Infrastructure
Driver=oracle.jdbc.xa.client.OracleXADataSource
URL=jdbc:oracle:thin:@localhost:1521/XE
User=DEV_SOAINFRA
Password=********
SQL Test=select 1 from schema_version_registry where owner=(select user from dual) and mr_type='SOAINFRA' and version='11.1.1.2.0'

CFGFWK-60850: Test Failed!
CFGFWK-60853: A connection was established to the database but no rows were returned from the test SQL statement.



Solution:

The error is really caused by the incorrect RCU. RCU is 11.1.1.3.0, but the version in above query is still 11.1.1.2.0. It can be fixed by the follow command.
./Oracle_SOA1/bin/psa -dbType Oracle -dbConnectString localhost:1521:xe -dbaUserName sys -schemaUserName DEV_SOAINFRA

2. Download updates issue.

NOTE: 
In the updates checking process, you have to provide a user name and password of oracle website. Please make sure you provide a correct password before click Next button. I selected the Save Password and I didn't find a way to change it after I clicked the Next button.
Even you provide a correct user name and password, you may still get an error message. From the installation guide, it mentioned ‘If there is a problem connecting to the repositories it may be caused by a proxy server. If so go to JDeveloper – Tools -> Properties -> Web Browser and Proxy and set the proxy server and proxy exclusions to appropriate values for your environment. Then restart JDeveloper.’. But it didn’t tell you how to modify it. I ever tried to deselect the proxy but it failed. When you try the download, you will get the same error and the original setting would come back automatically.
(The JDeveloper – Tools -> Properties -> Web Browser and Proxy should be JDeveloper – Tools -> Preferences -> Web Browser and Proxy.)

Error Message:
"An error occurred downloading updates. Click Back to return to the previous page and retry installation, or Cancel to close wizard. Unexpected end of file from server."

Solution:
1. Directly download for Oracle website and manually install it.
2. Open the preference of Jdeveloper by menu Tools-->Preferences, select the Web browser and Proxy setting and modify the proxy host name to localhost, otherwise, you will be always failed.

Comment:
'I ever tried to deselect the proxy but it failed. When you try the download, you will get the same error and the original setting would come back automatically. '
Maybe I made a mistake and didn't restart the JDeveloper. Now I have successfully deselected the proxy and can update the JDeveloper.


Friday, October 22, 2010

HowTo: Run the .sh File Shell Script In Linux / UNIX

(From: http://www.cyberciti.biz/faq/run-execute-sh-shell-script/)
I've downloaded a software for Linux from the Internet. There is a file called install.sh. How do I run an .sh file to install the software?

.sh file is nothing but the shell script to install given application or to perform other tasks under UNIX like operating systems. The easiest way to run .sh shell script in Linux or UNIX is to type the following commands. Open the terminal (your shell prompt) and type the command:


sh file.sh

OR

bash file.sh


.sh File As Root User

Sometime you need to install application which requires root level privalage
Some time you need root access to install application; without root, you won't have the necessary permissions to install application or make system level modifications. Root access is disabled by default on many Linux and UNIX like systems. Simply use sudo or su as follows:

sudo bash filename.sh
Type your password. Another option is to use the su command as follows to become superuser:

su -
Type root user password and finally run your script:
bash filename.sh
chmod Command: Run Shell Script In Linux

Another recommend option is to set an executable permission using the chmod command as follows:

chmod +x file.sh

Now your can run your .sh file as follows

./file.sh

How to use Unix shell script to send e-mail.

Recently, got problem to send e-mail from Unix with an existing shell script. It took me a long time to fixed. Here is the implementation of mine.

1. Mail sender



import java.io.BufferedReader;
import java.io.InputStreamReader;

public class MailSender {

public void send() throws Exception {
String[] cmd = { "sh", "/opt/app/test/SendEmail.sh",
"Victor Mail Sender", "hello Victor!", "mail@victor.net",
"victor@gmail.com" };

Runtime rt = Runtime.getRuntime();

Process p = rt.exec(cmd);

BufferedReader br = null;
try {
br = new BufferedReader(new InputStreamReader(p.getInputStream()));
String x = null;
while ((x = br.readLine()) != null) {
System.out.println(x);
}
p.waitFor();
} finally {
try {
if (br != null)
br.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}

public static void main(String[] args) {
try {
MailSender ms = new MailSender();
ms.send();
} catch (Exception e) {
e.printStackTrace();
}
}
}


In the above code, when we build the command used to send mail, we use "sh" as the first value of string array. If without this value, the SendEmail.sh must be set an executable permission. Using array to execute the shell script is to allow space in the subject and message body. If you put them in a string as a command to execute, it will not work and all the space in the command will be used as a separator.

The follow info is copied from The Java Developers Almanac.


     try {
       // Execute a command without arguments
       String command = "ls";
       Process child = Runtime.getRuntime().exec(command);
 
       // Execute a command with an argument
       command = "ls /tmp";
       child = Runtime.getRuntime().exec(command);
   } catch (IOException e) {
   }

   //If an argument contain spaces, it is necessary to use the overload that requires the command and its arguments to be supplied in an array:
   try {
       // Execute a command with an argument that contains a space
       String[] commands = new String[]{"grep", "hello world", "/tmp/f.txt"};
       commands = new String[]{"grep", "hello world", "c:\\Documents and Settings\\f.txt"};
       Process child = Runtime.getRuntime().exec(commands);
   } catch (IOException e) {
   }


Unix Shell Scirpt:


#!/usr/bin/ksh

# --------------------------
# 1, Set up environment
# --------------------------

LOG_HIS="./Mail.History.log"

#Current environment variable
TS=$(date +%Y%m%d-%H%M%S)

# ------------------------------------------------------------
# 2, Check parameter and write initial info into log
# ------------------------------------------------------------
echo "--------------------------- ${TS} -------------------------- "  >>${LOG_HIS}

# Check if has parameter
if [ "$#" -lt 4 ]
then
    echo "Error: Missed parameters !" >> ${LOG_HIS}
    exit 1
else
    from=$3
    to=$4
    Subject=$1
    body=$2
    
    echo "Subject:  ${Subject}" >> ${_LOG_HIS}
    echo "body:  ${body}" >> ${LOG_HIS}
    echo "From:  ${from}" >> ${LOG_HIS}
    echo "To:  ${to}" >> ${LOG_HIS}
fi

echo  $body |mailx -m -r $from -s "$Subject"  $to >> ${LOG_HIS}

exit 0

Tuesday, August 03, 2010

Dependency Injection in Java EE 6 - Part 5

From http://www.theserverside.com/feature/Dependency-Injection-in-Java-EE-6-Part-5

This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection as well as robust context management for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.
In the previous articles in the series, we discussed basic dependency injection, scoping, producers/disposers, component naming, interceptors, decorators, stereotypes, events and conversations. In this article we will discuss CDI’s interaction with JSF in detail. In the next and last article of this series, we will cover portable extensions, available implementations as well as CDI alignment with Seam, Spring and Guice. We will augment the discussion with a few implementation details using CanDI, Caucho’s independent implementation of JSR 299 included in the open source Resin application server.
CDI and JSF
A majority of CDI features are generic to all tiers of a Java EE application and not specific to JSF. In fact most CDI features are useful even in a Java SE application. However, there are a few CDI features that are specific to the web tier and there are many middle-tier oriented features that can be combined in powerful ways with JSF. In the following sections we will explore how features like CDI component naming, scopes, injection, producers, qualifiers and EJB 3 services can be used effectively with JSF.
Note JSF 2 retains its own web tier component model via the @ManagedBean set of annotations as well as annotations for the view, request, session and application scopes. Indeed, you can use EJB 3 and JSF 2 without CDI if you so wish. However there are few compelling reasons to do so considering the much richer set of CDI features that can be used with JSF 2 and EJB 3, including the ones we will discuss here.
Component naming via the @Named annotation is perhaps the easiest place to start. As discussed in the second article in the series, it is the critical link between the type-based Java component world and the string identifier based JSF/Facelet world. Besides making a CDI component available through EL binding expressions by assigning it a resolvable name, the @Named annotation is also useful for overriding the default name of a bean to make it more readable in EL. As the examples in the second article demonstrate, you could shorten the name of a component from the default “bidItemPostingWizard” to simply “itemWizard”:
@ConversationScoped @Named(“itemWizard”)
public class BidItemPostingWizard
Besides providing the critical CDI-JSF linkage, the @Named annotation is fairly unremarkable so we won’t discuss it further here besides using it in the JSF/CDI example use-cases in the following sections.

Web Frameworks other than JSF
Although this article covers JSF 2 only, CDI can also be used in a more-or-less similar fashion with Web Frameworks like Wicket or even Struts 2. Indeed, Seam 3 already supports Wicket and we are considering Struts 2 integration as part of Resin/CanDI. Would such integration be helpful to you?

CDI Contexts and JSF
CDI automatic context management complements JSF’s component-oriented model in very powerful ways by abstracting away boilerplate HTTP request, session and cookie manipulation code. We discussed CDI scopes and context management in detail in the very first article of the series. We also focused on just the innovative conversation scope in the fourth article, including JSF examples. Context management centers on the ability to transparently place managed beans into a declared scope and injecting them from the scope when needed. The striking effect of this capability is generally most noticeable to developers using action-oriented web frameworks like Struts.
Let’s take an example common to most applications to illustrate some of this – a login component. Such a component in its most basic form would be able to handle the login event. The login information should also be saved into the session after the login completes so that it can be retrieved where needed throughout the session. You can accomplish this by simply creating a CDI session scoped login component:

@Named
@SessionScoped
public class Login implements Serializable {
  @Inject
  private UserService userService;

  private String username;
  private String password;
  private User user;

  public void setUsername(String username) {
    this.username = username;
  }

  public String getUsername() {
    return username;
  }

  public void setPassword(String password) {
    this.password = password;
  }

  public String getPassword() {
    return password;
  }

  public void setUser(User user) {
    this.user = user;
  }

  public User getUser() {
    return user;
  }

  public String login() {
    user = userService.getUser(username);
    ...
    return "account.jsf";
  }
}
You would use the component in a JSF page to handle the login event as follows:
<h:form>
  <h1>Login</h1>
  <h:panelGrid columns="2">
    <h:outputLabel for="username">Username:</h:outputLabel>
    <h:inputText id="username" value="#{login.username}"/>
    <h:outputLabel for="password">Password:</h:outputLabel>
    <h:inputSecret id="password" value="#{login.password}"/>
  </h:panelGrid>
  <h:commandButton value="Login" action="#{login.login}"/>
</h:form>

The username and password properties are bound to input text fields while the login method is bound to the login event. The login method uses the injected user service to retrieve user details. These user details can then be accessed by any other component since the login component is placed in the session scope. For example the component to add a bid could use the login data as follows:
@Named
@RequestScoped
public class BidManager {
  @Inject
  private BidService bidService;

  @Inject
  private Login login;

  @Inject @SelectedItem
  private Item item;

  @Inject
  private Bid bid;

  public String addBid() {
    bid.setBidder(login.getUser());
    bid.setItem(item);
    bidService.addBid(bid);

    return “bid_confirm.xhtml”;
  }
}
CDI resolves the injection request to the login component stored in the session scope. Note that the bid manager component itself is in the request scope so in this example we are retrieving data stored in the underlying HTTP session into the HTTP request context. Without automatic context management, you would have to save the user information into the HTTP session yourself and retrieve it manually when needed via boilerplate API calls. Typical manual session manipulation code is usually also accompanied by needless database look-ups. In our example, most naive developers would likely only store a user identifier into the session on login and look-up the user data from the database when the bid is added.
You should also note the other interesting things going on in the bid manager component. The injection of the back-end bid service is pretty straightforward. However, the bid and item injection is more interesting. The item object being injected was likely placed into scope before the bid was placed and has the selected item qualifier placed on it. We will see how CDI qualifiers can be used effectively at the presentation tier shortly. Similarly, the injected bid object encapsulates bid data such as the bid amount. This serves to better model the presentation tier in an object oriented fashion and also promotes the reuse of domain objects across tiers (for example, the bid object could be a JPA mapped entity). You can use a similar technique to better model our example login component:
@Named
@SessionScoped
public class Login implements Serializable {
  @Inject
  private Credentials credentials;

  @Inject
  private UserService userService;

  private User user;

  public void setUser(User user) {
    this.user = user;
  }

  public User getUser() {
    return user;
  }

  public String login()
  {
    user = userService.getUser(credentials.getUsername());
    ...
    return "account.jsf";
  }
}

@Named
@RequestScoped
public class Credentials {
  private String username;
  private String password;

  public void setUsername(String username) {
    this.username = username;
  }

  public String getUsername() {
    return username;
  }

  public void setPassword(String password) {
    this.password = password;
  }

  public String getPassword() {
    return password;
  }
}  
We have re-factored out the username and password fields into a request scoped credentials component that is injected into the login component. Because the credentials are in the request scope and not the session scope, they are discarded right after the login event, which is what we really want to have happen anyway. The re-factored JSF page will look like this and is probably a readability improvement as well:
<h:form>
  <h1>Login</h1>
  <h:panelGrid columns="2">
    <h:outputLabel for="username">Username:</h:outputLabel>
    <h:inputText id="username" value="#{credentials.username}"/>
    <h:outputLabel for="password">Password:</h:outputLabel>
    <h:inputSecret id="password" value="#{credentials.password}"/>
  </h:panelGrid>
  <h:commandButton value="Login" action="#{login.login}"/>
</h:form>

You can freely interweave object scopes as your application requirements evolve. You can inject session scoped objects into request or conversation scoped objects, application scoped objects into session scoped objects, request scoped objects into session scoped objects and the like. CDI proxies make sure that there is not an issue even if a narrower scoped object is injected into a broader scoped object – CDI will always resolve to the currently active instance under the hood. For example, if a request scoped object is injected into a conversational component, CDI will ensure that the conversational component always references the most up-to-date request scoped object via the injected proxy. As an exercise, you should try to think about how you would code a conversation scoped user preferences wizard to add one or more request scoped preferences (hint: you would inject the request scoped preferences object and use it in the method to add a preference to the current set - the correct request scoped reference will be resolved automatically even after initial injection). 

Producers in JSF
We discussed CDI producers in detail in the second article in the series. In most cases, components in the web tier will be defined statically. However, just as is the case with back-end components, it is sometimes useful to generate components dynamically in the web tier via producers. Let’s revisit our login component as an example. If you look carefully you’ll notice that the bid manager component really does not need a reference to the login component per se. What it really needs is the user object that the login component holds a reference to. Injecting the login component instead of the user component makes our code less loosely coupled. This problem can easily be solved by introducing a producer in the login component:
@Named
@SessionScoped
public class Login implements Serializable {
  @Inject
  private Credentials credentials;

  @Inject
  private UserService userService;

  private User user;

  public String login()
  {
    user = userService.getUser(credentials.username);
    ...
    return "account.jsf";
  }

  @Produces
  public User getCurrentUser()
  {
    return user;
  }
}

@Named
@RequestScoped
public class BidManager {
  @Inject
  private BidService bidService;

  @Inject
  private User user;

  @Inject @SelectedItem
  private Item item;

  @Inject
  private Bid bid;

  public String addBid() {
    bid.setBidder(user);
    bid.setItem(item);
    bidService.addBid(bid);

    return “bid_confirm.xhtml”;
  }
}
Although in this example the producer method itself is in a session scoped bean, producers can be encapsulated in pure factory objects just as in the example in the second article. In such a case, you will likely want to attach an appropriate scope to the producer method like this:
@Produces @SessionScoped
public User getCurrentUser()
{
  ...
}
You can also use CDI producers (in particular producer fields) for better encapsulation and improving readability in JSF. Let’s take a look at the following simplified component to place a bid:
@RequestScoped @Named
public class PlaceBid {
  @Inject
  private BidService bidService;

  @Produces @Named
  private Bid bid = new Bid();

  public void placeBid() {
    bidService.addBid(bid);
  }
}
In this example, instead of embedding the fields of the bid in the place bid component, we have better encapsulated it in the bid object and exposed the bid object as a named producer field. The corresponding JSF component will look something like this:
<h:form>
  <table>
    <tr>
      <td>Bidder</td>
      <td><h:inputText value="#{bid.bidder}"/></td>
    </tr>
    <tr>
      <td>Item</td>
      <td><h:inputText value="#{bid.item}"/></td>
    </tr>
    <tr>
      <td>Bid Amount</td>
      <td><h:inputText value="#{bid.price}"/></td>
    </tr>
  </table>
  ...
  <h:commandButton type="submit" value="Place Bid"
    action="#{placeBid.placeBid}"/>
  ...
</h:form>

Without the named producer, the bid fields could still be referenced in EL but would be much less readable as below:

This technique is especially helpful for complex forms with many inputs that might be best grouped into separate objects exposed by named producers from a master form handler.
CDI Qualifiers and JSF
Qualifiers are invaluable particularly while using CDI producers with JSF. We discussed qualifiers in detail in the first article of the series. Unlike business and persistence tier components, you typically will not need to swap out implementations at the web tier using qualifiers. However, while creating dynamic components, it is often necessary to qualify them to reduce the possibility of an accidental dependency collision. Let’s revisit the login component to see why this might be the case with CDI producers:
@Named @SessionScoped
public class Login implements Serializable {
  ...
  @Produces
  public User getCurrentUser()
  {
    return user;
  }
}

@Named @RequestScoped
public class BidManager {
  ...
  @Inject
  private User user;
  ...
}
The problem with the code above is that there might be other dynamically produced user objects in the session or request scopes. For example, there might be a currently selected seller or customer service agent that is also a user object for the same session. Imagine this code used from the customer service live chat screen:
@Named @SessionScoped
public class CustomerService implements Serializable {
  ...
  @Produces @Agent
  public User getSelectedAgent()
  {
    return selectedAgent;
  }
}
Because there will now be two candidates for the injection point in the bid manager it will become ambiguous as to which one to inject at runtime. The best way to resolve the dependency correctly would be to introduce a qualifier:
@Named @SessionScoped
public class Login implements Serializable {
  ...
  @Produces @LoggedIn
  public User getCurrentUser()
  {
    return user;
  }
}

@Named @RequestScoped
public class BidManager {
  ...
  @Inject @LoggedIn
  private User user;
  ...
}
Besides avoiding possible dependency collisions, adding qualifiers to producers generally improves readability, as is illustrated in our example. Both the producer and the injection point make it clear what type of user is expected at runtime.
Flattened Layers with JSF
Most server-side Java applications are typically built with large teams, heavy maintenance and longevity in mind. This is one reason layering is so popular in Java EE applications. Layers improve testability, enforce separation of concerns, help skills specialization and make it easier to replace the implementation of a specific layer. However, layering can be overkill for smaller teams, smaller applications and prototypes.
Keeping this fact in mind, CDI allows you to flatten the business/transactional and persistence tiers if you so wish. It enables this by allowing you to use EJB 3 and JPA directly with JSF without any intermediate service or DAO tiers. For example, the simplified bid manager component we looked at earlier can be re-factored to be a session bean that uses an injected JPA entity manager directly:
@Stateful @RequestScoped @Named
public class BidManager {
  @PersistenceContext
  private EntityManager entityManager;

  @Produces @Named
  private Bid bid = new Bid();

  public void addBid() {
    entityManager.persist(bid);
  }
}
Because it is an EJB, the bid manager is automatically thread-safe so it can use the non-thread-safe entity manager reference directly and is also transactional by default. The JSF page using the bean would remain unchanged:
<h:form>
  <table>
    <tr>
      <td>Bidder</td>
      <td><h:inputText value="#{bid.bidder}"/></td>
    </tr>
    <tr>
      <td>Item</td>
      <td><h:inputText value="#{bid.item}"/></td>
    </tr>
    <tr>
      <td>Bid Amount</td>
      <td><h:inputText value="#{bid.price}"/></td>
    </tr>
  </table>
  ...
  <h:commandButton type="submit" value="Place Bid"
    action="#{bidManager.addBid}"/>
  ...
</h:form>

As the application evolves, you could, of course, always re-factor the flattened components into web, domain, business and persistence tiers. The capacity to use EJB 3 and JPA directly with JSF simply gives you some added flexibility when you need it.

Using EJB Services Outside the Component Model
You can flatten the application tiers in Resin 4 without needing to use EJB per se by directly adding EJB services such as transactions to CDI managed beans. In our example, you would add the @TransactionAttribute annotation instead of the @Stateful annotation to make the bid manager transactional. Entity manager thread-safety is not an issue in Resin 4 since all JPA provided entity managers are automatically wrapped in a thread-safe proxy.

More to Come
Besides the CDI features we discussed in detail here, there are many other CDI features that can be used in powerful ways with JSF. You can use CDI stereotypes to define components specific to the web tier in addition to the built-in @Model stereotype. For example, you could add a @Wizard stereotype that is named, conversation scoped and attaches interceptors/decorators specific to wizard components. You could use CDI events to trigger actions from the web tier in a loosely-coupled fashion. You could also use the features we described here in many other innovative ways for your particular application. We encourage you to further explore these possibilities on your own.
As we mentioned at the beginning of the article, we are now almost at the end of this series and hope it was useful to you. In the next and last article of this series we will discuss CDI portable extensions, CDI’s alignment with Seam, Guice, Spring, etc as well as the current implementations of CDI including Weld/Seam 3, OpenWebBeans and CanDI.
In the meanwhile, for comments on CDI, you are welcome to send an email to jsr-299-comments@jcp.org. You can also send general comments on Java EE 6 to jsr-316-comments@jcp.org. For comments on the article series, Resin or CanDI, our JSR 299 implementation, feel free to email us at reza@caucho.com or ferg@caucho.com. Adios Amigos!

Monday, July 12, 2010

How to implement a unparallel job and dynamically add another trigger

Sometimes, a job is not allow to run parallel, e.g. a file loading task. It is not a good idea to allow multiple job to load a same file in same time and it will lead to create duplicate records in table.

How to implement a job to exclusively load the data from a file? Quartz provides a stateful interface and we can use it to implement a stateful job to avoid run a same job parallelly. For a stateful job, one job must wait another finished and then to run.

If we need to dynamically add a trigger to fire a job immediately exclusively, how to implement it? First, use the stateful job interface to avoid the same job running parallelly. Then we create a new trigger and set proper job group and job name (the name of job you want to run) and schedule it by scheduleJob() method of scheduler.

Wednesday, May 19, 2010

Contexts and Dependency Injection for Java EE (CDI) - Part 4

From http://www.theserverside.com/tip/Dependency-Injection-in-Java-EE-6-Conversations-Part-4

This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection as well as robust context management for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.

In the previous articles in the series, we discussed basic dependency injection, scoping, producers/disposers, component naming, interceptors, decorators, stereotypes and events. In this article we will discuss CDI Conversations in detail. In future articles, we will cover details of using CDI with JSF, portable extensions, available implementations as well as CDI alignment with Seam, Spring and Guice. We will augment the discussion with a few implementation details using CanDI, Caucho’s independent implementation of JSR 299 included in the open source Resin application server.
The Concept of Conversations
In the first article of the series, we discussed conversations very briefly from the perspective of CDI scopes in general. The conversation scope is an idea that comes from Seam and deserves a detailed look, especially for understanding how to use it with JSF.
Most server-side Java developers are very familiar with the request and session scopes. That is likely how you started web application state management, probably using the programmatic APIs defined in the Servlet specification. As a result, it is pretty obvious how the CDI request and session scopes are used with JSF through @RequestScoped and @SessionScoped beans (although we will still discuss this in some detail in the next article in the series). The most typical use of a @RequestScoped bean is as a JSF backing bean for a single page handling one HTTP request/response cycle. The vast majority of CDI beans you will use with JSF will likely belong to the request scope. In a similar vein, @SessionScoped beans are used for objects that are used throughout the HTTP session. Examples of this include user login credentials, account details and so on.
There is a relatively large class of web application use-cases that fall between these two logical extremes. There are some presentation tier objects that can be used across more than one page/request but are clearly not used across the entire session. Such objects are usually used in multi-step workflows. Unlike session scoped objects that are usually timed-out, conversation scoped objects have well-defined life-cycle start and end-points that can be determined ahead of time. A good example use-case for the conversation scope is an online quiz or questionnaire (both of which I’m sure we’ve all encountered much more frequently than we would like). While such use-cases are often implemented as part of the HTTP session, there really is no good reason to do so since the life-cycle of a quiz or questionnaire can be pretty well-defined and they are not needed across the entire session. The life-cycle of a quiz/questionnaire would begin with the first question. As part of the application workflow, the user will progress through questions. The user may also go back and forth through responses an arbitrary number of times. Finally, the quiz/questionnaire would end its life-cycle after the user finalizes their responses. Infrequently, the user will simply abandon the quiz/questionnaire, so conversation scoped objects do still need a timeout mechanism in case the event that defines the end of the workflow never happens. An order process that translates a shopping cart into a finalized checkout is another good candidate for the conversation scope since it will typically be a multi-step wizard.
Another way to think about the conversation scope is that it is a truncated custom session with the developer programmatically determining where the scope begins and ends. The concept of conversations will become even clearer as we look at a concrete example with code.
A Conversational Example
To borrow a convenient example from EJB 3 in Action, the bidder account creation wizard in the eBay-like ActionBazaar makes another great candidate use-case for the conversation scope. As shown in Figure 1, the wizard is composed of fours steps. In the first step, the user will enter login information such a username, password, password confirmation, secret question/answer, etc. When the user clicks the “Next” button, the information in the first step is saved and the user is taken to the second step. In the second step, user details such as the first name, last name, address, email and contact information is collected and saved. The wizard also allows the user to backtrack to the previous step and change the previously entered information.


Similarly, the third step collects user preferences such as notification and display preferences. The final step of the wizard confirms all the collected bidder account information before actually creating the account. The first step of the wizard starts the conversation while the conversation scope should end when the account is created in the last step of the wizard.
The entire account creation wizard can be implemented through a single conversation scoped bean. Before we look at how the bean is implemented, let’s take a brief look at the relatively unsophisticated JSF Facelets for the wizard. Figure 2 shows the JSF code that corresponds to each of the pages in Figure 1.


The enter_login.jsf page implements the first page of the wizard (in case of Facelets the actual source code file name is likely enter_login.xhtml). The login input is bound to a bean named login while the “Next” button is bound to accountCreator.saveLogin. As we will see shortly, the accountCreator bean is a conversation scoped bean that models the workflow. The login bean, on the other hand, is a simple data holder backing bean produced by the accountCreator bean. The second page in the workflow, enter_user.jsf similarly uses a produced backing bean named user and the “Next” button is bound to accountCreator.saveUser. The “Previous” button maps directly to the first page in the wizard. The enter_preferences.jsf page is implemented in a very similar fashion. The final page in the wizard, confirm_account.jsf, displays the values collected by the wizard during the conversation and also binds the event handler that triggers the actual creation of the account and the end of the workflow, accountCreator.createAccount.
Let’s now take a close look at the conversation scoped bean that implements the wizard:


@Named
@ConversationScoped

public class AccountCreator {
  @Inject
  private AccountService accountService;
  @Inject
  private Conversation conversation;
  @Named
 @Produces
  public Login login = new Login();
  @Named
  @Produces

  public User user = new User();
  @Named
  @Produces

  public Preferences preferences = new Preferences();
   public String saveLogin() {
    conversation.begin();
    ...
    return “enter_user.jsf”;
   }

   public String saveUser() {
    ...
    return “enter_preferences.jsf”;
   }

   public String savePreferences() {
    ...
    return “confirm_account.jsf”;
   }

   public String createAccount() {
    Account account = new Account();
    account.setLogin(login);
    account.setUser(user);
    account.setPreferences(preferences);
    accountService.createAccount(account);
    conversation.end();
    return “/home.jsf”
   }

}


The bean is annotated to be both @Named so that it can be referenced from EL as well as @ConversationScoped. The login, user and preferences fields produce named backing beans for use in the wizard pages. Because these beans are produced by the conversational bean, they are available throughout the conversation as well as being available to the parent bean holding the bean instances. It is very important to note that a handle to the Conversation itself is injected into the bean. As we will discuss in greater detail both in this section as well as the next section, the Conversation interface allows programmatic control over the life-cycle of the conversation scope. This interface is basically what allows you to “custom-fit” the conversation to your application. A back-end service to actually create the account is also injected and is presumably implemented as a transactional stateless session bean. The JSF event listener methods in AccountCreator is actually where most of the interesting stuff is going on. The saveLogin method is called on the first page of the wizard and actually starts the long-running conversation. To understand what that means, you’ll have to know about types of conversations in CDI.
CDI has two different types of conversations, transient and long-running. By default, when you annotate a bean with @ConversationScoped, it is assumed to be transient. A transient conversation ends when the request that originated the conversation ends. This is a sensible fail-safe in case a conversational bean does not really need to be extended beyond the request. Any transient conversation can be turned into a long-running conversation on demand. Unlike a transient conversation, a long-running conversation extends beyond the scope of a request, potentially as long as the whole application session. A transient conversation is turned into a long-running conversation by invoking the Conversation.begin method, as is done in the saveLogin method. If the saveLogin method is not invoked, for example if the user abandoned the wizard at the first step, the bean will never be put into a long-running conversation and will simply be disposed of at the end of the request as part of the transient conversation. Besides starting the long running conversation, a number of other things can possibly be done in the saveLogin method, including perhaps validating that the username does not already exist, the password matches the confirmed password or that the password meets security guidelines. The saveLogin method also moves the wizard to the next page by returning the “enter_user.jsf” URL as the outcome for the event.
No specific manipulation of the conversation is done in the next page of the wizard, except for binding more input values to the user produced bean and the saveUser event handler likely only does some form-level validation before forwarding to the enter_preferences.jsf page. The savePreferences event handler is similarly simplistic. The event handler method for the final page in the wizard, createAccount, does a number of interesting things, however. It actually creates the final Account object with all the input collected into the produced fields throughout the conversation and invokes the back-end service to save the newly created account into the database. It then invokes the Conversation.end method. As you can guess, the Conversation.end method ends the long running conversation. This does not mean however that the conversation is immediately destroyed; it simply means that the conversation is “demoted” to becoming transient again. This allows for the conversational bean to be destroyed when the request ends and the user is moved out of the wizard into the “/home.jsf” URL.
An interesting question to think about is what happens if the user abandons the wizard in the middle after the long-running conversation is started. The bean will of course not be destroyed when a request ends. Like sessions, long-running conversations have an implicit timeout. When this timeout value expires, the conversation is destroyed. This timeout value is typically shorter than a session timeout. An astute reader might also wonder what happens if the saveLogin method (and therefore the Conversation.begin) is invoked twice during the same conversation, or if the Conversation.end method is invoked while the conversation is still transient. In most real applications, the begin and end methods should always be invoked after checking the current state of the conversation using the other methods in the Conversation interface described in detail below.


Programmatic vs. Declarative Conversations
It is an interesting question to ask whether the programmatic model of injecting the conversation and calling the begin and end methods could be converted to a declarative equivalent. For example, instead of injecting the conversation, we could have used something like @Begin and @End on the saveLogin and createAccount methods.
While this is not currently supported in CDI, it is the model that was supported in previous versions of Seam and will likely still be supported in Seam 3. If you believe it is useful, this is something we can support in Resin 4 as well.


More on Conversations
In order to make effective use of the conversation scope, it is helpful to understand a little bit of how it is implemented under-the-hood. CDI keeps track of a long running conversation by propagating an HTTP GET parameter named cid (reserved by the specification) across requests that are part of a workflow. The ID is created when the conversation starts and the cid that is passed around from request-to-request is mapped to the correct conversation context at runtime on subsequent requests in the workflow. When CDI cannot find a cid in the request, it assumes that a new conversation should be started. The ID itself is usually automatically generated, but you can create it manually yourself and retrieve it when needed (see the table below). As matter of fact, the cid can even be propagated back and forth from JSF and non-JSF pages (such as Servlets that are aware of CDI).
Below are all the methods that are supported by the Conversation interface:

Method
Description
void begin() The method promotes the conversation to being long-running. If the conversation is already long-running, an IllegalStateException is thrown. When the conversation is promoted, CDI automatically generates a unique ID and assigns it to the conversation – this is the ID that is used in the cid parameter.
void begin(String id) This variant of the begin method allows you to provide an application defined ID for the conversation. You may want to do this, for example, if you wanted to track the conversations for your application by assigning some custom meaning to it.
void end() This method demotes a long-running conversation to become transient. If the conversation is not long-running, an IllegalStateException is thrown.
String getId() This method returns the identifier of the current long-running conversation, or a null value if the current conversation is transient. The method can be used to send the conversation ID to a non-JSF page by embedding it into a URL or hidden form value, for example.
long getTimeout() This method returns the timeout, in milliseconds, of the current conversation.
void setTimeout(
long milliseconds)
This method sets the timeout of the current conversation. The method could be used as a performance tuning measure or for customizing application behavior (for example, setting idle time for an on-line quiz).
boolean isTransient() This method indicates whether the current conversation is transient. It should be used to check conversation state before invoking the begin and end methods.



It is also important to understand that you can start multiple conversations in the same session. For example, you could open two instances of the enter_login.jsf page in separate tabs. Two different conversations with two different conversation IDs would result. Conversations are thread-safe, meaning that even if you started two concurrent requests, two different conversations would still result.
For further details on the conversation scope such as conversation passivation, feel free to look through the CDI specification (or the Weld reference guide referenced below).
More to Come
Although we have discussed CDI’s interaction with JSF in somewhat greater detail in this article of the series, JSF’s interaction with CDI deserves focused coverage. In the next article of the series, we will focus solely on CDI from a JSF developer’s perspective including CDI’s interaction with JSF using EL binding, scoping, producers, qualifiers, events and the like.
In the meanwhile, for comments on CDI, you are welcome to send an email to jsr-299-comments@jcp.org. You can also send general comments on Java EE 6 to jsr-316-comments@jcp.org. For comments on the article series, Resin or CanDI, our JSR 299 implementation, feel free to email us at reza@caucho.com or ferg@caucho.com. Cheers until next time!
References
1.      JSR 299: Contexts and Dependency Injection for Java EE, http://jcp.org/en/jsr/detail?id=299.
2.      JSR 299 Specification Final Release, https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_JCP-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=web_beans-1.0-fr-oth-JSpec@CDS-CDS_JCP.
3.      Weld, the JBoss reference implementation for JSR 299: http://seamframework.org/Weld.
4.      Weld Reference Guide, http://docs.jboss.org/weld/reference/1.0.0/en-US/html/.
5.      CanDI, the JSR 299 implementation for Caucho Resin, http://caucho.com/projects/candi/.
6.      OpenWebBeans, Apache implementation of JSR 299, http://openwebbeans.apache.org.
About the Authors
Reza Rahman is a Resin team member focusing on its EJB 3.1 Lite container. Reza is the author of EJB 3 in Action from Manning Publishing and is an independent member of the Java EE 6 and EJB 3.1 expert groups. He is a frequent speaker at seminars, conferences and Java user groups, including JavaOne and TSSJS.
Scott Ferguson is the chief architect of Resin and President of Caucho Technology. Scott is a member of the JSR 299 EG. Besides creating Resin and Hessian, his work includes leading JavaSoft’s WebTop server as well as creating Java servers for NFS, DHCP and DNS. He lead performance for Sun Web Server 1.0, the fastest web server on Solaris.

Contexts and Dependency Injection for Java EE (CDI) - Part 3

From http://www.theserverside.com/news/2240016831/Part-3-of-dependency-injection-in-Java-EE-6

This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection as well as robust context management for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.
In the previous articles in the series, we took a high-level look at CDI, discussed basic dependency management, scoping, producers/disposers, component naming and dynamically looking up beans. In this article we will discuss interceptors, decorators, stereotypes and events. In the course of the series, we will cover conversations, CDI interaction with JSF, portable extensions, available implementations as well as CDI alignment with Seam, Spring and Guice. We will augment the discussion with a few implementation details using CanDI, Caucho’s independent implementation of JSR 299 included in the open source Resin application server.
Cross-cutting concerns with CDI interceptors
Besides business logic, it is occasionally necessary to implement system level concerns that are repeated across blocks of code. Examples of this kind of code include logging, auditing, profiling and so on. This type of code is generally termed “cross-cutting concerns” (although subject to much analysis as a complement to object orientation, these types of concerns really don’t occur that often in practice). CDI interceptors allow you to isolate cross-cutting concerns in a very concise, type-safe and intuitive way.   
The best way to understand how this works is through a simple example. Here is some CDI interceptor code to apply basic auditing at the EJB service layer:
@Stateless
public class BidService {
    @Inject
    private BidDao bidDao;

    @Audited
    public void addBid(Bid bid) {
        bidDao.addBid(bid);
    }
    ...
}

@Audited @Interceptor
public class AuditInterceptor {
    @AroundInvoke
    public Object audit(InvocationContext context) throws Exception {
        System.out.print("Invoking: "
            + context.getMethod().getName());
        System.out.println(" with arguments: "
            + context.getParameters());
        return context.proceed();
    }
}

@InterceptorBinding
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface Audited {}
Whenever the addBid method annotated with @Audited is invoked, the audit interceptor is triggered and the audit method is executed. The @Audited annotation acts as the logical link between the interceptor and the bid service. @InterceptorBinding on the annotation definition is used to declare the fact that @Audited is such a logical link. On the interceptor side, the binding annotation (@Audited in this case) is placed with the @Interceptor annotation to complete the binding chain. In other words, the @Audited and @Interceptor annotations placed on AuditInterceptor means that the @Audited annotation placed on a component or method binds it to the interceptor.
Note a single interceptor can have more than one associated interceptor binding. Depending on the interceptor binding definition, a binding can be applied either at the method or class level. When a binding is applied at the class level, the associated interceptor is invoked for all methods of the class. For example, the @Audited annotation can be applied at the class or method level, as denoted by @Target({TYPE, METHOD}). Although in the example we chose to put @Audited at the method level, we could have easily applied it on the bid service class instead.
We encourage you to check out the CDI specification for more details on interceptors including disabling/enabling interceptors and interceptor ordering (alternatively, feel free to check out the Weld reference guide that’s a little more reader-friendly).
 
Custom vs. Built-in Interceptors
EJB declarative transaction annotations like @TransactionAttribute and declarative security annotations like @RolesAllowed, @RunAs can be thought of as interceptor bindings built into the container. In fact, this is not too far from exactly how things are implemented in Resin.
In addition to the EJB service annotations, we could add a number of other built-in interceptors for common application use-cases in Resin including @Logged, @Pooled, @Clustered, @Monitored, etc. Would this be useful to you?

Isolating pseudo business concerns with CDI decorators
Interceptors are ideal for isolating system-level cross-cutting concerns that are not specific to business logic. However, there is a class of cross-cutting logic that is closely related to business logic. In such cases, you will have logic that really should be externalized from the main line of business logic but is still very specific to the interception target type, method or parameter values. CDI decorators are intended for such use cases. Like interceptors, decorators are very concise, type-safe and pretty natural.
As in the case with interceptors, the best way to understand how decorators work is through a simple example. We’ll use the convenient bid service example again. Let’s assume that the bid service is used in multiple locales. For each locale bid monetary amounts are entered and displayed in the currency specific to the locale. However, the bid amounts are internally stored using a standardized currency (such as maybe the Euro or the U.S. Dollar). This means that bid amounts must be converted to/from the locale specific currency, likely at the service tier. Because the currency conversion code is not strictly business logic, it should really be externalized, but it is very specific to bid operations. This is a good use case for decorators, as shown in the code below:
@Stateless
public class DefaultBidService implements BidService {
    ...
    public void addBid(Bid bid) {
    ...
}

@Decorator
public class BidServiceDecorator implements BidService {
    @Inject @Delegate
    private BidService bidService;

    @Inject @CurrentLocale
    private Locale locale;

    @Inject
    private Converter converter;

    public void addBid(Bid bid) {
        bid.setAmount(converter.convert(bid.getAmount(),
            locale.getCurrency(), Converter.STANDARDIZED_CURRENCY));

        bidService.addBid(bid);
    }
    ...
}
As you can see from the code example, the currency conversion logic is isolated in the decorator annotated with the @Decorator annotation. The decorator is automatically attached and invoked before the interception target by CDI (just as in the case of interceptors). A decorator cannot be injected directly into a bean but is only used for the purposes of interception. The actual interception target is injected into the decorator using the @Delegate built-in qualifier. As you can also see, decorators can utilize normal bean injection semantics. If the Decorator/Delegate terminology sounds familiar, it is not an accident. CDI Decorators and Delegates essentially implement the well-known Decorator and Delegate OO design patterns. You can use qualifiers with @Delegate to narrow down which class a decorator is applied to like this:
@Decorator
public class BidServiceDecorator implements BidService {
    @Inject @Legacy @Delegate
    private BidService bidService;
    ...
}

The CDI specification (or the Weld reference guide) has more details on decorators including disabling/enabling decorators and decorator ordering.
Custom component models with CDI stereotypes
CDI stereotypes essentially allow you to define your own custom component model by grouping together meta-data. This is a very powerful way of formalizing the recurring bean roles that often arise as a result of application architectural patterns. For example, in a tiered server-side application, you can imagine component definitions for the service, DAO or presentation-tier model (the ‘M’ in MVC). A stereotype consists of a default component scope and one or more interceptor bindings. A stereotype may also indicate that a bean will have a default name (essentially indirectly decorating it with @Named) or that a bean is an alternative (indirectly decorated with @Alternative). A stereotype may also include other stereotypes.
 
Alternatives
An alternative is anything marked with the @Alternative annotation. Unlike regular beans, an alternative must be explicitly enabled in beans.xml. Alternatives are useful as mock objects in unit tests as well as deployment-specific components. Alternatives take precedence over regular beans for injection when they are available.
We won’t discuss alternatives beyond this here, but we encourage you to explore them on your own.

A stereotype defined for the DAO layer in our example bidding application could look like the following:
@Profiled
@Dependent
@Stereotype
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Dao {
}

As you can see, the @Stereotype annotation denotes a stereotype. Our stereotype is declared to have the dependent scope by default. This makes sense since DAOs are likely injected into EJBs in the service tier. The interceptor binding @Profiled is also included in the stereotype. This means that any bean annotated with the @Dao stereotype may be profiled for performance via an interceptor bound to @Profiled. The stereotype would be applied to a DAO like this:
@Dao
public class DefaultBidDao implements BidDao {
    @PersistenceContext
    private EntityManager entityManager;
    ...
}

To solidify the idea of stereotypes a little more, let’s take a look at another example. CDI actually has a built-in stereotype - @Model. Here is how it is defined:
@Named
@RequestScoped
@Stereotype
@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface Model {}
The @Model annotation is intended for beans used as JSF model components. This is why they have the request scope by default so that they are bound to the life-cycle of a page and are named so that they can be resolved from EL. This is how @Model might be applied:
@Model
public class Login {
Note it is possible to override the default scope of a stereotype. For example, you can turn the Login bean into a session scoped component like this:
@SessionScoped @Model
public class Login {

It is also possible to place more than one stereotype on a given class, as well as apply additional interceptors, decorators, etc. As we mentioned earlier, stereotypes can also be cumulative, meaning that a stereotype can include other stereotypes in its definition.

 
The EJB Component Model as Stereotypes
It is an interesting question to ask whether the EJB component model (@Stateless, @Stateful, etc) can be modeled simply as a set of highly specialized stereotypes for the business/service tier. This is a logical next step from redefining EJBs as managed beans with additional services as was done in Java EE 6 and could open up some very powerful possibilities for the Java EE component model going forward.
This is one possibility we are actively exploring for the Resin EJB 3.1 Lite container.

Lightweight type-safe events with CDI
Events are useful whenever you need to loosely couple one or more invokers from one or more invocation targets. In enterprise applications events can be used to communicate between logically separated tiers, synchronize application state across loosely related components or to serve as application extension points (think about Servlet context listeners, for example). Naturally CDI events are lightweight, type-safe, concise and intuitive. Let’s look at this via a brief example to see how events in CDI work.
Let’s assume that various components in the bidding system can detect and generate fraud alerts. Similarly, various components in the system need to know about and process the fraud alerts. CDI events are a perfect fit for such a scenario because the producers and consumers are so decoupled in this case. The code to generate a fraud alert event would look like this:
@Inject
private Event fraudEvent;

Fraud fraud = new Fraud();

fraudEvent.fire(fraud);

CDI events are triggered using injected Event objects. The generic type of the Event is the actual event being generated. Like the Fraud object, events are simple Java classes. In our example, we would construct the fraud object and populate it as needed. As you can see, events are triggered by invoking the fire method of Event. When the event is triggered, CDI looks for any matching observer methods that are listening for the event and invokes them, passing in the event as an argument. Here is how an observer method for our fraud alert would look like:
public void processFraud(@Observes Fraud fraud) { ... }
An observer method is simply a method that has a parameter annotated with the @Observes annotation. The type of the annotated parameter must match the event being triggered. The name Observer mirrors the Observer OO design pattern. You can use qualifiers to filter observed events as needed. For example, if we were only interested in seller fraud, we could place a qualifier on the observer method like this:
public void processSellerFraud(@Observes @Seller Fraud fraud) { ... }
On the producer side, there are a couple of ways to attach qualifiers to trigged events. The most simple (and common) way would be to declaratively place a qualifier on the injected event like this:
@Inject @Seller
private Event sellerFraudEvent;
It is also possible to attach qualifiers programmatically using the Event.select method like this:
if (sellerFraud) {
    fraudEvent.select(new Seller()).fire(fraudEvent);
}

There is a lot more to events than this like injecting parameters into observer methods, transactional observers and the like that you should investigate on your own.

 
Events and Messages
There are a lot of obvious parallels between events and traditional messaging with JMS. This is one of the avenues we are exploring further in Resin to see if these models could be merged in a simple and intuitive way – namely if the Event object can be used to send JMS messages and/or if @Observer could listen for JMS messages.

More to come
In the next part of the series we will be focusing on CDI as it relates to JSF developers at the presentation tier (many of you have expressed specific interest in this topic). We will cover using the new conversation scope as well as CDI’s interaction with JSF using EL binding, scoping, producers, qualifiers and the like.
In the meanwhile, for comments on CDI, you are welcome to send an email to jsr-299-comments@jcp.org. You can also send general comments on Java EE 6 to jsr-316-comments@jcp.org. For comments on the article series, Resin or CanDI, our JSR 299 implementation, feel free to email us at reza@caucho.com or ferg@caucho.com. Adios Amigos!
References
1.      JSR 299: Contexts and Dependency Injection for Java EE
2.      JSR 299 Specification Final Release
3.      Weld, the JBoss reference implementation for JSR 299
4.      Weld Reference Guide
5.      CanDI, the JSR 299 implementation for Caucho Resin
6.      OpenWebBeans, Apache implementation of JSR 299
About the Authors
Reza Rahman is a Resin team member focusing on its EJB 3.1 Lite container. Reza is the author of EJB 3 in Action from Manning Publishing and is an independent member of the Java EE 6 and EJB 3.1 expert groups. He is a frequent speaker at seminars, conferences and Java user groups, including JavaOne and TSSJS.
Scott Ferguson is the chief architect of Resin and President of Caucho Technology. Scott is a member of the JSR 299 EG. Besides creating Resin and Hessian, his work includes leading JavaSoft'stable WebTop server as well as creating Java servers for NFS, DHCP and DNS. He lead performance for Sun Web Server 1.0, the fastest web server on Solaris.

Tuesday, May 18, 2010

Memory leaks where the classloader cannot be garbage collected

http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

Short description of the problem

When an application is loaded in a container environment, it gets its own ClassLoader. In tomcat this will be a WebAppClassLoader. When the application is undeployed, the container in theory drops all references to that class loader, and expects normal garbage collection to take care of the rest. However, if any object that is loaded by the system or container classloader (StandardClassLoader in tomcat) still has a reference to the application class loader or any object loaded by it, the class loader will not be garbage collected. In that case, all the class objects and every object referenced by a static field in any of the classes will not be garbage collected.
I've run into this problem in the context of a spring/hibernate application running on tomcat, but it's really general to any situation where you have classloaders with a lifecycle.

Problems

There are two main patterns that cause this situation. The first one is where a library loaded by the container has a cache that keeps strong references to objects or classes in the application. The second one is where the application has ThreadLocal data that is attached to a container thread. In tomcat this thread will be part of the thread pool, so it will never be garbage collected.

Known offenders

Bean introspection
The bean introspection code will keep a strong cache, but this can easily be cleared with a call to java.beans.Introspector.flushCaches(). There is a listener in the spring library that will take care of this: org.springframework.web.util.IntrospectorCleanupListener.
IntrospectionUtils
org.apache.tomcat.util.IntrospectionUtils has a cache of objects and their methods that it has been used against. This is a Hashtable called objectMethods that is never cleaned up. It will be used to inspect any exceptions that your application throws. In this table, the class is the key and the method the value. Note that a WeakHashMap will not help here as the value has a reference to the key. I haven't found any good way of getting around this, short of removing the cache and making your own version of the jar.
There is also a copy of IntrospectionUtils in org.apache.commons.modeler.util. It seems to have the same problem.
DriverManager
Any JDBC driver loaded in the application (from the WEB-INF/lib directory) will be registered in the system-wide DriverManager. It will not be unloaded unless you add a listener similar to the example below (written by Guillaume Poirier).
CleanupListener.java
public class CleanupListener implements ServletContextListener { 
  public void contextInitialized(ServletContextEvent event) { 
  } 
  public void contextDestroyed(ServletContextEvent event) { 
    try { 
      Introspector.flushCaches(); 
      for (Enumeration e = DriverManager.getDrivers(); e.hasMoreElements();) { 
        Driver driver = (Driver) e.nextElement(); 
        if (driver.getClass().getClassLoader() == getClass().getClassLoader()) { 
          DriverManager.deregisterDriver(driver);          
        } 
      } 
    } catch (Throwable e) { 
      System.err.println("Failled to cleanup ClassLoader for webapp"); 
      e.printStackTrace(); 
    } 
  } 
}
DOM4J
There used be some data saved in ThreadLocals by DOM4J, but this has been fixed in a later version. 1.6.1 seems to work fine for me.
Mozilla Rhino
See Bugzilla: ThreadLocal in Context prevents class unloading.
KeepAliveCache
sun.net.www.http.KeepAliveCache will keep HTTP 1.1 persisent connections open for reuse. It launches a thread that will close the connection after a timeout. This thread has a strong reference to your classloader (through a ProtectionDomain). The thread will eventually die, but if you are doing rapid redeployment, it could still be a problem. The only known solution is to add "Connection: close" to your HTTP responses.
IdleEvictor
If you are using the commons-dbcp connection pooler, you may be activating the idle evictor thread. Because of a bug, this will sometimes keep running even if your application is unloaded. It can be deactivated by calling the setTimeBetweenEvictionRunsMillis(long) method of the org.apache.commons.pool.impl.GenericObjectPool object with a negative parameter.
Jasper
There is a bug in how Jasper (a JSP compiler) pools taglibs. This has been seen to cause memory leaks when used with hibernate, there is more information here: Bugzilla: The forEach JSTL tag doesn't release items
Sun's -server VM
In some cases (see JDK bug 4957990 below) the VM will not free your class loader even if there are no references to it. Try running with -client.

Suspected offenders

CGLIB
CGLIB used to have some memory leaks problems in its proxy code, but they are supposedly fixed in later versions.
commons-logging
If you load commons-logging in your container, it can cause leaks. See Logging/UndeployMemoryLeak for more information. There is also some information about this in the guide: Classloader and Memory Management

How to find your offenders

As for your application, there are two ways to go. Either start with a minimal test application and add stuff until it doesn't unload properly, or start with a complete applications and fix offenders until it unloads. Either way, a profiler will be essential. There are several alternatives, free and commercial, listed below.
Unfortunately I haven't found a profiler that will make it trivial to find these problems. In most cases I have to go through all the classes that are loaded by my class loader, and look for references to them by Objects loaded by the container class loader. This is very time-consuming work and can be quite frustrating - it's quite common to see that your application loads several thousand classes.
According to baliukas: If you run the JVM in debug note, or you use -Xprof, class objects will not be unloaded.
JProfiler
Commercial profiler that gives you a very good graphical representation of your references, but handles any static field in a class object as a garbage collection root.
YourKit Java Profiler
Commercial profiler. In some cases it is able to automatically find references to your ClassLoader. In other cases, your ClassLoader is annotated as a "Other GC" object, whatever that means.
Eclipse Profiler
Free. I've seen this recommended. http://eclipsecolorer.sourceforge.net/
JConsole
Included with the JDK (in 1.5 at least). Gives you some basic information about memory usage etc.
NetBeans Profiler
Free. I've seen this recommended.
HAT
HAT is used to parse the binary output from HPROF (a small profiler that is included with the JDK). Attila submitted a patch to make HAT work better for problems with classloaders. Hat can be found here: http://hat.dev.java.net/, and the patch at https://hat.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1.

Other discussions

Spring forum: Memory Leak
Spring forum: Memory leaks when redeploying web applications
Spring forum: Memory Leak: Spring does not release my objects
Hibernate forum: OutofMemoryError on webapp redeploy (10 pages)
dom4j-Bugs-1070309: ThreadLocal cache
web app using log4j not garbage collected when shutdown with tomcat manager
(commons-logging) j2ee unit tests added: memory leak demonstrated
spring-devel: Further Investigations into OOM Exceptions on Redeploy

Related bugs

JDK
ResourceBundle holds ClassLoader references using SoftReference (not weak) (Closed, fixed)
ObjectOutputStream.subclassAudits SoftCache prevents ClassLoader GC (Closed, fixed)
ClassLoaders do not get released by GC, causing OutOfMemory in Perm Space (Closed, fixed)
PermHeap overflow problem in and only in server VM (In progress, bug)
Apache
IntrospectionUtils caches application classes (Resolved)
(modeler) IntrospectionUtils memory leak (New)
Hibernate
Memory Leak: Objects are not released during hot deploy (Rejected)

Articles

A day in the life of a memory leak hunter
Logging/UndeployMemoryLeak
Memory leaks, be gone