This brief blog entry explains the Mojarra bug triage process, and shares some tips for maximizing the chances your bug will be quickly fixed and find its way into a release. Mojarra is the JSF implementation in several app servers and is the source code from which the reference implementation of the JSF specification is derived.

Mojarra has had a publically accessable issue tracker since 2004, and was the first part of the Java platform to do so. Oracle uses Atlassian JIRA as the issue tracking software for its JavaEE technologies, and the Mojarra JIRA is at <https://java.net/jira/browse/JAVASERVERFACES>. You need to get a java.net id to be able to file bugs on any such JIRAs. You can get one at <https://java.net/people/new>.

How to speed your way though the bug fixing process

The first question on your mind when you find a bug in Mojarra is, "how quickly can I see this fixed?" The first thing to check is whether or not it has been fixed already. It happens! The Mojarra team puts out regular releases of the most recent two revisions of the JSF spec. Currently these are 2.1 and 2.2. Follow the steps in this entry in the JSF FAQ at <http://jsf.java.net/faq/> to update the Mojarra implementation in GlassFish. The steps for other containers are beyond the scope of this blog entry.

If your bug still manifests itself in the most recent version of Mojarra for the JSF spec version you're using, the next step is to build a short, self-contained (compilable) executable (SSCCE) showing the bug. This is the single most important thing to speed your way through the bug fixing process. In fact, most of the time in fixing a bug is reproducing it and writing the regression test for it. Neither of these things require access to the Mojarra source code. The Mojarra team has published maven archetypes to make this easy. Follow the steps in the entry in the JSF FAQ at <http://jsf.java.net/faq/> for instructions on how to use the maven archetypes to quickly create as SSCCE.

Once you are sure the bug still reproduces on the most recent code and you have an SSCCE, you are ready to file a JIRA for it. You will quickly run into the problem of attachments. For security purposes, the uploading of attachments was disabled except for individuals that have the Developer role in JIRA. To work around this limitation, send the SSCCE as an email attachment toissues AT javaserverfaces DOT java DOT net. To subscribe to this list, visit <http://jsf.java.net/mailinglists.html>. Once it's in the JIRA, if you really want to ensure fast action, try to get others to vote for the issue. Issues that have ten or more votes will receive top priority attention, as evidenced by this JIRA query showing all such issues. To vote for an issue, just click on the "Vote for it" link on the main page for the issue.

How the Mojarra team triages bugs

(This text is taken directly from the JSF FAQ).

Bugs filed in the Mojarra Issue Tracker are triaged by the Mojarra team with the goal of maximizing the number of bugs resolved and minimizing the effort taken to resolve them.  The most important ingredient to achieve this goal is responsiveness: first on the part of the Mojarra team and second on the part of the reporter.

The Mojarra team will do its best to respond to all bugs within four weeks of filing.

The remainder of this answer will describe the lifetime of a bug in two scenarios.  Both of these scenarios assume the Mojarra team is holding up its end of the responsiveness bargain.

  1. The fully responsive reporter. 
    1. Arrive at an SSCCE. 
    2. Work on the bug begins in earnest 
      1. Once an SSCCE for the bug is in hand, work on the fix can begin.  During    the bug fix, the Mojarra team may need more information to work toward a    resolution.  With a fully responsive reporter, this information is    provided within four weeks of its being requested by the Mojarra team.    As long as no more than four weeks go by without a response, the bug    will remain in the "fully responsive reporter" process.  In this case,    the Mojarra team works on the bug and makes regular progresses at least    once every four weeks.  Occasionally progress becomes blocked awaiting a    response from the reporter.  If four weeks go by without a response, the    bug will enter the "unresponsive reporter" process.
    3. Bug resolution 
      1. Once the bug has been resolved, it is committed to the appropriate    source code lines and made available for the next release of Mojarra.
  2. The unresponsive reporter. 
    1. Request for information 
      1. If the Mojarra team requests more information on a bug report, such as to arrive at an SSCCE, or to ask if the bug still exists when tried with the latest available appropriate mojarra release, but the reporter does not respond to the request within four weeks, the bug will be de-prioritized one level from its existing priority. 
        1. after four weeks of inactivity: Major is de-prioritized to Minor
        2. after eight weeks of inactivity: Minor is de-prioritized to Trivial
        3. In all cases, the "Major" JIRA priority is the maximim allowable    priority for bugs in the triage process.  The Mojarra team uses the    "Critical" and "Blocker" priorities to prioritize bugs on which work    has actively started.
        4. If a response is given by the reporter, the bug leaves the    "unresonsive reporter" process and returns to the "responsive    reporter" process.
    2. Bug resolution 
      1. After twelve weeks of inactivity, the trivial issue is closed as    Incomplete.
      2. This JIRA query contains issues closed as incomplete.

I hope this quick blog entry can help increase the quality of the Mojarra JSF implementation by helping the Mojarra team solve more issues quickly.

20130716-1558 UTC updated: made Mojarra team responsiveness commitment less specific.