<?xml version="1.0"?>
<document url="./status.xml">

<!--
// ======================================================================== 78
-->

<properties>
    <title>Status - The Apache Struts Web Application Framework</title>
    <author>Craig R. McClanahan</author>
    <author>Ted Husted</author>
    <author>Steve Byrne</author>
</properties>

<body>
    <section name="Status" href="status">

    <p>
        The <strong>stable production release</strong> is
        <a href="http://www.apache.org/dist/jakarta/struts/binaries/">Struts 1.1.0</a> (29 June 2003).
    </p>

    <hr/>

    <ul>
    <li>
      See the <a href="../status.html">Development Roadmap</a> for an overview of future plans.
    </li>
    <li>
        See the <a href="http://jakarta.apache.org/site/bugs.html">Apache Bug Database</a> for outstanding issues and
        enhancement requests.
      </li>
    <li>
        See the <a href="http://jakarta.apache.org/builds/jakarta-struts/nightly/">Struts Nightly Build</a> for the
        latest development distribution.
    </li>
    <li>
        See the <a href="http://jakarta.apache.org/site/mail.html">Struts-Dev list</a> for current development
        communications.
    </li>
    <li>
        See the <a href="http://cvs.apache.org/viewcvs/jakarta-struts/">Struts CVS</a> for the current development
        codebase.
      </li>
    <li>
       See the <a href="../releases.html">Release Guides</a> for our release process and coding conventions.
    </li>
    </ul>

</section>

<section href="roadmap" name="Development Roadmap">

    <p class="version">
    $Id: status.xml 51200 2003-11-29 07:27:33Z sraeburn $
    </p>

    <p>
    This document outlines some of changes we expect to
    see in future releases of Struts.
    </p>

    <p>
    This document is provided for discussion purposes only.
    All releases and changes to the codebase are subject to
    <a href="http://jakarta.apache.org/site/decisions.html">a vote</a> of the
    <a href="volunteers.html#committers">Struts Committers</a>.
    </p>

    </section>

    <section href="Bugzilla" name="Bugzilla Queries">

        <p>
            The Struts development teams uses the <a href="http://jakarta.apache.org/site/bugs.html">Apache Bug Database</a> (Bugzilla)
            to manage problem reports and enhancement requests.
            For your convenience, here are some common Bugzilla queries:
        </p>

        <ul>
            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;order=%27Importance%27">Open reports</a></li>
            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_severity=Blocker&amp;bug_severity=Critical&amp;bug_severity=Major&amp;bug_severity=Normal&amp;bug_severity=Minor&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=%27Importance%27">Open problem reports</a>
                <ul>
                <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;bug_severity=Blocker&amp;bug_severity=Critical&amp;bug_severity=Major&amp;order=%27Importance%27">major problem reports</a></li>
                <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;bug_severity=Blocker&amp;bug_severity=Normal&amp;bug_severity=Minor&amp;order=%27Importance%27">minor problem reports</a></li>
                </ul>
                </li>
            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;bug_severity=Enhancement&amp;order=%27Importance%27">Open enhancement reports</a></li>
            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=LATER&amp;resolution=REMIND&amp;product=Struts&amp;order=%27Importance%27">Reports to be handled "LATER"</a></li>
        </ul>


    </section>

<section href="Struts_1_x" name="Struts 1.x">

    <p>
        The platform requirements throughout the Struts 1.x series will remain the same (Servlet 2.2 / JSP 1.1).
        Though, later platforms may be supported as an option.
    </p>
    <p>
        Releases in the 1.x series will focus on refactoring of existing functionality, with a
        continued emphasis on backward compatibility, as were seen in Struts 1.1.
        However, we expect there to releases to be incremental throughout the rest of the
        1.x series, so that improvements and fixes become available to production teams every few weeks.
    </p>

    <p>
        Any feature that can be implemented under Servlet 2.2/JSP 1.1 may be considered for the Struts 1.x series.
        This may include, but is not limited to, better support for alternate view technologies (like XLST),
        integrated unit testing, integrated support for HTTP/HTTPS mode switching, better workflow handling,
        support for alternative action types (e.g. BSF actions), a chainable request processor, support for an Action
        context, and so forth.
    </p>

    <p>
        Features most likely to be considered are those that have already been implemented as
        third-party extensions and are in active use by the Struts Community, such as
        those distributed through the
        <a href="http://sourceforge.net/projects/struts">Struts SourceForge</a> site.
    </p>

    <p>
        Throughout the 1.x series, there will be a continued emphasis on expanding unit test coverage for the
        framework.
        Bug reports should include a failing test case when possible.
        Proposals for new features should include a working test suite.
        (Creating features through Test Driven Development is strongly encouraged.)
    </p>

    <p>
        Enhancement requests are logged in Bugzilla they are suggested.
        <strong>The listing of an enhancement in Bugzilla does not imply that is being "planned"</strong>, merely that some
        member of the community has suggested it, and the idea hasn't been ruled out (yet).
    </p>

    <p>
        Future release milestones are provided for enhancements which are being actively planned or developed
        but may not be ready for the very next release.
        If a report has not been tagged for a specific milestone by a working developer, then <strong>it may never be
        resolved</strong>.
        When developers (including non-Committers) are actually working on an enhancement, they should re-tag it for a
        specific release milestone, such as "1.2.1" or "1.2.2".
    </p>

    <p>
        If an enhancement has not been tagged for a specific target, feel free to start working on it yourself.
        Many of our best features have been contributed by developers, just like you.
        If you would like to announce your active interest in an enhancement, please post a note on the ticket, and tag
        it to an appropriate release milestone.
    </p>

    </section>

    <section href="Struts_1_x_whiteboard" name="Struts 1.x Whiteboard">

        <p>
            These are some general ideas we have about what may happen in the Struts 1.x series.
            This is a <strong>whiteboard</strong> and everything here is <strong>subject to change</strong>.
        </p>

        <ul>

            <li>Struts 1.0.0 (complete) -
            Major refactoring of Struts internals to provide support for modules and a new "config" object series.
            Bundles Struts Tiles and Struts Validator into main distribution.
            The initial release of Struts EL is provided as an optional package.
            </li>

            <li>Struts 1.2.x -
            Continued refactorings of the Struts 1.x product series.
                <ul>
                    <li>Remove deprecations created in the 1.0 to 1.1 timeframe, and prior</li>
                    <li>Other minor enhancements and refactorings</li>
                </ul>
            </li>

            <li>Struts 1.3.x -
            More substantial enhancements to product base
                <ul>
                    <li>Move to Commons Resources</li>
                    <li>Move taglibs into separate JARs</li>
                    <li>Enhance all configs to extend one configuration element from another,
                        as is done with Tiles Definitions</li>
                </ul>
            </li>

            <li>Struts 1.4.x -
            More substantial enhancements to product base
                <ul>
                    <li>Consider new Request Processor, if available (which might be based on the Commons Chain
                        of Responsiblity package)</li>
                    <li>Consider migration to an Action context (which also might be based no the Commons Chain
                        of Responsiblity package)</li>
                    <li>Consider enhanced support for other platforms (2.3/1.2) if this can be accomplished by
                    specifying an alternate Request Processor</li>
                </ul>
            </li>

            <li>Other potential enhancements for the 1.x.x series
                <ul>
                    <li>Move to <a href="http://xml.apache.org/forrest/">Forrest</a> or
                        <a href="http://maven.apache.org/">Maven</a> for project management</li>
                    <li>Consider adopting several popular extensions, including:
                        <ul>
                            <li><a href="http://sslext.sourceforge.net/">SSL Ext</a></li>
                            <li><a href="http://strutstestcase.sourceforge.net/">TestCase</a></li>
                            <li><a href="http://stxx.sourceforge.net">Stxx</a> (XLST)</li>
                            <li><a href="http://www.livinglogic.de/Struts/">Workflow</a></li>
                            <li><a href="http://struts.sf.net/struts-cocoon/">Cocoon Plugin</a></li>
                            <li><a href="http://struts.sf.net/struts-bsf/">Scriptable Actions using BSF</a> (Bean Scripting
                                Framework)</li>
                        </ul>
                    </li>
                </ul>
            </li>

        </ul>

  <!--
    <p>
    Features under discussion include:
    </p>

    <ul>

        <li>
        Proposing ActionError/ActionErrors as generic Commons "message" components
        </li>

        <li>
        "Nested" or "hierarchical" and locale-sensitive modules
        </li>

        <li>
        Extending one configuration element from another, as is done with Tiles
        Definitions
        </li>

        <li>
        Enhanced interoperability with JSTL and JSF
        </li>

        <li>
        Making Tiles JSTL-aware and available to other presentation systems (XLST,
        Velocity)
        </li>

        <li>
        Encouraging the use of <a href="http://sourceforge.net/projects/xdoclet/">XDoclet</a> and other code generation technologies to streamline development.
        </li>

        <li>Moving to <a href="http://jakarta.apache.org/turbine/maven/index.html">
        Maven</a> for project management
        </li>

        <li>Regardless of whether a move to Maven happens or not, we need to
        refactor the source repositories and build scripts for less complexity
        and easier maintenance.</li>

    </ul>
    <p>
    More detail on work-in-progress may be found in
    <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=LATER&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=Unknown&amp;version=1.0+Beta+2&amp;version=1.0+Beta+1&amp;version=0.5+Final&amp;version=1.0.2+Final&amp;version=1.0.1+Final&amp;version=1.0+Final&amp;version=1.0+Beta+3&amp;version=1.1+Beta+2&amp;version=1.1+Beta+1&amp;version=Nightly+Build&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=Bug+Number">Bugzilla</a>.
    If any of these features are important to you, please don't hesitate to
    <a href="./faqs/helping.html">help with the development effort</a>.
    </p>
-->

</section>

<section href="Struts_2_0" name="Struts 2.0.x">

    <p>
    Struts 2.x (aka Struts "Next Generation") will include broader enhancements.
    We anticipate that the implementation will utilize the Servlet 2.4 / JSP 2.0
    platform, but may optionally support earlier platforms.
    </p>

    <p>
    We anticipate that Struts 2.x will rely on JSTL and the JavaServer Faces
    API as supporting technologies.
    However, the focus of the Struts framework will remain on the Controller aspect of a Model 2/MVC architecture.
    The core framework will continue to be both Model and View independent.
    </p>

    <p>
    Development of Struts 2.x will include taking a completely fresh look at
    the architecture.
    The goal for 2.x will be to incorporate everything we've learned in the past
    years of Struts usage, and create something even better.
    Development will follow current best practices, like Test Driven Development,
    and rely on technologies like Maven for project management.
    </p>

    <p>
    Of course, it is anticipated that the Struts team will continue to support
    the 1.x codebase for a long time with bugfixes and incremental enhancements.
    (Mainly because many of us will still be using it on our production sites!)
    Accordingly, it is anticipated that the development of the 2.x and 1.x
    series will occur in tandem.
    At some point, 2.x milestones may appear alongside new 1.x releases.
    </p>

    <p>
    Target features include:
    </p>

    <ul>

        <li>
        Comprehensive unit test coverage for all core features
        </li>

        <li>
        Enhanced support for using Struts in large team environments.
        </li>

        <li>
        Transparent support for a portlet environment (JSR 168), with minimal-to-no changes in your business logic
        and pages.
        </li>

        <li>
        Direct support for JSTL/JSF taglibs and the JSF API
        </li>

        <li>
        Enhanced support for other presentation layers, such as XLST
        </li>

        <li>
        Enhanced support for scriptable Actions, using technologies like BSF or Jelly
        </li>

        <li>
        Refactoring for new technologies available on the Servlet 2.4/ JSP 2.0 platform
        </li>

    </ul>

</section>

<section href="Portlets" name="Portlet (JSR-168) Whiteboard">
    <p>
        There are three major issues with supporting JSR-168 (and I'm sure a bunch of smaller ones as well):
    </p>

    <ul>

        <li>
            Struts APIs assume servlet API objects (ServletContext, ServletRequest, ServletResponse), whereas JSR-168
            talks aboutPortletContext, PortletRequest, and PortletResponse.
            We'd either need to change the calling sequence for Action.execute() -- problematic for backwards
            compatibility -- or fake it somehow in a portlet environment.
        </li>

        <li>
            The lifecycle of a portlet request is actually divided into two chunks -- processing and then rendering.
            From a Struts perspective, that means making sure that the first part of the request processor pipeline
            need to happen in the "process" part, and the forwarding to the resulting page needs to happen in the
            "render" part.
        </li>

        <li>
            Today, Struts owns the process of calculating URLs for pages and actions.
            Because it's in a webapp, it knows exactly what to do for the developer.
            However, in a portlet container it's actually the portal server that manages URLs, so a Struts-based
            portlet would need to interact with the portlet APIs for this purpose.
        </li>

    </ul>

    <p>
        A strong goal should be that a Struts application should be usable either as a webapp or as a portlet, with
        little (ideally no) changes.
        Therefore, we should build whatever it takes to support this into the standard Struts distribution, which would
        then be used in both environments.
    </p>

</section>

    <section href="jsf" name="JavaServer Faces">

        <p>
            The <a href="http://java.sun.com/j2ee/javaserverfaces/">JavaServer Faces</a> specification has not been
            finalized. However, Struts is already providing support for JSF through the Struts Faces taglib. Once JSF
            is finalized and comes into broad use, it is expected that Struts developers will continue to offer
            enhancements to make it even easier to use Struts with JSF.
        </p>

        <p>
            Right now, there is only one open source project working on a JavaServer Faces implementation,
            <a href="http://sf.net/projects/myfaces">MyFaces</a>. This work is being done under the
            <a href="http://www.gnu.org/copyleft/lesser.html">LGPL</a>, which some
            developers find unacceptable. (If you are interested in this project, we suggest you lobby the developers
            to adopt a more liberal license, like the <a href="http://apache.org/LICENSE">ASL</a>.)
        </p>

        <p>
           Thanks in large part to Apache's advocacy and influence, the <a href="http://jcp.org">Java Community
           Process</a>, which is responsible for the JavaServer Faces specification, process has been modified so that
           Apache Software Foundation projects, like Jakarta, can qualify for the certification scholarship (for
           nonprofits) and access to the TCKs and certify that our application is compliant.
        </p>

        <p>
            An certificated-complaint Apache implementation of JavaServer Faces would most definately be a Good Thing.
            It would not be the reference implementation, but we could treat it like one, and strictly follow the
            book, in the Apache Way. A strict, high-quality, open-source implementation would most likely become
            a popular option among containers.
        </p>

        <p>
            Work on such an implementation could be undertaken by Struts, either here at Jakarta or after our applying
            for status as a top-level Apache project. <b>Or</b>, "Apache Faces" could also be undertaken as a separate
            project, with Struts simply using the technology as we now use technologies from the Commons today.
        </p>

        <p>
            However, at this point, there is no "code on the table". Apache products leave decisions such as these to
            the people who create and maintain the codebase. So, lacking a codebase, no binding decision
            can be made. But, anyone wishing to pursue an "Apache Faces" implementation should be aware that the option
            certainly exists.
        </p>

        <p>
            Aside from offering a strict implementation of JavaServer Faces, there are many, many other JSF related
            tools and technologies Apache Faces could provide. These include composite view and validation
            frameworks (like Tiles and the Validator), frameworks for multi-request transactions, non-HTML markup
            languages (building on top of Faces for things like XUL or XForms or SVG is easy), non-JSP rendering
            technologies (pretty much anything that has a way to mark where dynamically created output goes can be
            adapted), libraries of prebuilt components above and beyond the built-in standard ones (such components
            work equally well in JSP and non-JSP environments), and all the non-human-UI things based on XML
            technologies.
        </p>

        <p>
            As always, the standard implementation is only the beginning.
        </p>

        <p>
            For more about Struts and JavaServer faces, see our <a href="faqs/kickstart.html#jsf">FAQ</a>.
            For more about JavaServer Faces generally, see also <a href="http://www.jamesholmes.com/JavaServerFaces/">
            Java Server Faces Resources at JamesHomes.com</a>.
        </p>
    </section>

<section href="Proposals" name="Relevant Proposals">

    <ul>

        <li>
        <a href="http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/">Commons Chain of Responsiblity
        package</a>
        </li>

        <li>
        <a href="http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/">CoRe Request Processor</a>
        </li>


        <li>
        <a href="proposals/release-plan_1_2_0.html">Release Plan 1.2.0</a> -- unratified DRAFT document
        </li>

        <li>
        <a href="proposals/struts-faces.html">struts-faces taglib</a>
        </li>

    </ul>

</section>

<section>
    <p class="right">
    Next: <a href="releases.html">Release Guidelines</a>
    </p>
</section>

<section>
    <p class="version">Website updated from CVS: 2003 NOV 26 by husted.</p>
    <p class="version">Javadocs updated from CVS: 2003 NOV 26 by husted.</p>
</section>

</body></document>
