glassfish
  1. glassfish
  2. GLASSFISH-13134

Allow to override javax.* packages on the web application level

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: v3.0.1
    • Fix Version/s: None
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Linux

    • Issuezilla Id:
      13,134

      Description

      While there is a good reason to disallow applications to override e.g. the
      standard Servlet API implementation in GlassFish, it could make perfect sense
      for other Java EE APIs. For instance there is already a custom tag in
      sun-web.xml to allow using custom JSF API classes bundled with a web application
      to override the default version bundled with GlassFish. I would like to make
      this possible also for JAX-RS API, and also at the application level.

      Currently, one could use the following command:
      asadmin create-jvm-options
      -Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext

      together with <class-loader delegate="false"> in the sun-web.xml

      This, however, works only at the application server level and does not allow
      control at the application level as in the JSF case. The drawbacks are obvious:
      if you do not control the whole container, you are out of luck. Also to change
      this just for one application, you would need to restart the whole server
      and interrupt also the other running applications.

      I am going to attach a patch to allow to specify a list of overriden
      Java packages in the GlassFish specific web application descriptor,
      sun-web.xml or glassfish-web.xml, so that the application could
      configure use of it's own bundled Java packages belonging to the protected
      javax.* space.

      Following is an excerpt of how the web application bundling it's own
      JAX-RS implementation should look like after the patch is applied:

      <class-loader delegate="false">
      <property name="overrideablePackages"
      value="javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext"/>
      </class-loader>

        Activity

        Hide
        Jakub Podlesak added a comment -

        Created an attachment (id=4745)
        patch

        Show
        Jakub Podlesak added a comment - Created an attachment (id=4745) patch
        Hide
        survivant added a comment -

        please check the Issue http://java.net/jira/browse/GLASSFISH-15741

        for a sample that doesn't work.

        Show
        survivant added a comment - please check the Issue http://java.net/jira/browse/GLASSFISH-15741 for a sample that doesn't work.
        Hide
        gfuser9999 added a comment -

        user comment
        ------------
        1) This issues is for http://java.net/jira/browse/GLASSFISH-15741
        is not differently related to this issue.
        The testcase in http://java.net/jira/browse/GLASSFISH-15741
        is due to classloading but this fix enhancement
        is neccesary to provide per-webapp isolation
        of Jersey and others.

        2) For example with adding "-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext" and where the sun-web.xml have
        delegate="false", the above same app will fail after
        a deploy <app>, undeploy <app>, deploy <app> cycle.
        and you will hit http://java.net/jira/browse/JERSEY-660

        3) The reason w/o the override seems to be that the JAXRS
        Single RuntimeDelegate will point to the undeployed
        WebappClassLoader. And By default GF31
        WebappClassLoader will clear internal references.

        If the above system property exists, then it should
        be working fine. In fact as the system property
        is global, it is not fine grain. It seems to me
        that the request to have the overridePackages in
        sun-web.xml would be Good as it is the same
        trick as useBundledJsf or useMyFaces switch tries
        to achieve.

        So +1 for this.


        Note:


        WebappClassLoader seem to have a coding bug:
        On GF311, Line 1886->1903, the "If statement" is
        wrongly done – triggering wrong condition to
        clear-reference. (It also does not check loadedByThisOrChild()).

        Show
        gfuser9999 added a comment - user comment ------------ 1) This issues is for http://java.net/jira/browse/GLASSFISH-15741 is not differently related to this issue. The testcase in http://java.net/jira/browse/GLASSFISH-15741 is due to classloading but this fix enhancement is neccesary to provide per-webapp isolation of Jersey and others. 2) For example with adding "-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext" and where the sun-web.xml have delegate="false", the above same app will fail after a deploy <app>, undeploy <app>, deploy <app> cycle. and you will hit http://java.net/jira/browse/JERSEY-660 3) The reason w/o the override seems to be that the JAXRS Single RuntimeDelegate will point to the undeployed WebappClassLoader. And By default GF31 WebappClassLoader will clear internal references. If the above system property exists, then it should be working fine. In fact as the system property is global, it is not fine grain. It seems to me that the request to have the overridePackages in sun-web.xml would be Good as it is the same trick as useBundledJsf or useMyFaces switch tries to achieve. So +1 for this. Note: WebappClassLoader seem to have a coding bug: On GF311, Line 1886->1903, the "If statement" is wrongly done – triggering wrong condition to clear-reference. (It also does not check loadedByThisOrChild()).

          People

          • Assignee:
            Shing Wai Chan
            Reporter:
            Jakub Podlesak
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: