Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: 2.1
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      499

      Description

      The ProjectStage currently only allows web.xml + JNDI.
      It would be really great if it allows system props.

      http://matthiaswessendorf.wordpress.com/2008/10/29/jsf-2-projectstage-only-half-baked/

        Activity

        Hide
        Ed Burns added a comment -

        Move to unscheduled target milestone

        Show
        Ed Burns added a comment - Move to unscheduled target milestone
        Hide
        Ed Burns added a comment -

        Prepare to delete api subcomponent

        Show
        Ed Burns added a comment - Prepare to delete api subcomponent
        Hide
        lincolnbaxter added a comment -

        Updated to use new subcomponent / milestone options - This should be revisited
        for 2.1

        Show
        lincolnbaxter added a comment - Updated to use new subcomponent / milestone options - This should be revisited for 2.1
        Hide
        lincolnbaxter added a comment -
        {copied from JSR-314-OPEN}

        Project stage is something that needs to be configurable without
        modifying the underlying WAR (and while JNDI support is provided, it
        requires container configuration, admittedly not a huge downside.)
        However, for those who do not primarily use JNDI for configuration, a
        -D system property makes a lot of sense.

        I'd also like to propose one other enhancement, which is runtime
        configuration of the PROJECT_STAGE through an exposed API. This is
        something that I think should be able to turn on and off while the
        server is running (For the same reason it must be possible to enable
        or disable debug logging or auditing at runtime.)

        A simple API on javax.faces.application.Application to grant
        functionality of setting PROJECT_STAGE. This is something that is very
        easy for us to do, but also grants extreme flexibility, allowing
        people to use it how they please.

        public void setProjectStage(ProjectStage)

        { ... }
        Show
        lincolnbaxter added a comment - {copied from JSR-314-OPEN} Project stage is something that needs to be configurable without modifying the underlying WAR (and while JNDI support is provided, it requires container configuration, admittedly not a huge downside.) However, for those who do not primarily use JNDI for configuration, a -D system property makes a lot of sense. I'd also like to propose one other enhancement, which is runtime configuration of the PROJECT_STAGE through an exposed API. This is something that I think should be able to turn on and off while the server is running (For the same reason it must be possible to enable or disable debug logging or auditing at runtime.) A simple API on javax.faces.application.Application to grant functionality of setting PROJECT_STAGE. This is something that is very easy for us to do, but also grants extreme flexibility, allowing people to use it how they please. public void setProjectStage(ProjectStage) { ... }
        Hide
        mwessendorf added a comment -

        I am not really sure on the setProjectStage() API, as you may not want to mess
        around this setting during runtime.

        The System properties has already been implemented in MyFaces2:
        https://issues.apache.org/jira/browse/MYFACES-2235

        (sure, we currently use a "custom" org.apache.***** parameter)

        Show
        mwessendorf added a comment - I am not really sure on the setProjectStage() API, as you may not want to mess around this setting during runtime. The System properties has already been implemented in MyFaces2: https://issues.apache.org/jira/browse/MYFACES-2235 (sure, we currently use a "custom" org.apache.***** parameter)
        Hide
        Ed Burns added a comment -

        I brought this issue to the Sun JavaEE Architecture meeting on Tuesday
        19 January 2010. This meeting happens mostly weekly and is where the
        Sun EE Spec leads coordinate efforts to drive JavaEE spec efforts to
        completion. The technical leadership at this meeting includes Bill
        Shannon, Sun Distinguised Engineer and past JavaEE spec lead, and
        Roberto Chinnici JavaEE 6 spec lead.

        I brought up two issues regarding ProjectStage

        1. revive the drive to expose ProjectStage to lower level technologies
        in EE.

        2. have a System property to set the ProjectStage.

        For 1), the following questions were raised:

        • What specific use-cases exist for having ProjectStage at the servlet
          level? If the Servlet EG reviewed the proposal and ultimately
          rejected it, why bring it up again?
        • What about Gavin King's "alternatives" proposal?

        Pete Muir has clarified at this meeting that the "alternatives"
        proposal from Gavin did not make it into CDI in such a way as to be
        appropriate for our needs in the ProjectStage feature.

        For 2), the following points were raised:

        • There are no other System Properties in all of EE. Why do we need one
          now?
        • Why, specifically, does this system property need to be a part of the
          portable programming model?

        I voiced that it's useful in cases like mvn jetty run, or mvn tomcat
        run. Bill countered that such usages are already container specific,
        so it would best be addressed with a container specific configuration.

        In conclusion, I think we should close this spec issue and handle the
        System Property at the impl level. I have opened issue 1539 for this
        case.

        Ed

        Show
        Ed Burns added a comment - I brought this issue to the Sun JavaEE Architecture meeting on Tuesday 19 January 2010. This meeting happens mostly weekly and is where the Sun EE Spec leads coordinate efforts to drive JavaEE spec efforts to completion. The technical leadership at this meeting includes Bill Shannon, Sun Distinguised Engineer and past JavaEE spec lead, and Roberto Chinnici JavaEE 6 spec lead. I brought up two issues regarding ProjectStage 1. revive the drive to expose ProjectStage to lower level technologies in EE. 2. have a System property to set the ProjectStage. For 1), the following questions were raised: What specific use-cases exist for having ProjectStage at the servlet level? If the Servlet EG reviewed the proposal and ultimately rejected it, why bring it up again? What about Gavin King's "alternatives" proposal? Pete Muir has clarified at this meeting that the "alternatives" proposal from Gavin did not make it into CDI in such a way as to be appropriate for our needs in the ProjectStage feature. For 2), the following points were raised: There are no other System Properties in all of EE. Why do we need one now? Why, specifically, does this system property need to be a part of the portable programming model? I voiced that it's useful in cases like mvn jetty run, or mvn tomcat run. Bill countered that such usages are already container specific, so it would best be addressed with a container specific configuration. In conclusion, I think we should close this spec issue and handle the System Property at the impl level. I have opened issue 1539 for this case. Ed
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            javaserverfowner
            Reporter:
            mwessendorf
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: