glassfish
  1. glassfish
  2. GLASSFISH-3090

glassfish with ModJK config: Servlet 2.3 tests failed

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 9.1pe
    • Fix Version/s: not determined
    • Component/s: sqe-test
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: Linux

    • Issuezilla Id:
      3,090

      Description

      Hi,
      I used the glassfish 9.1 EE build 44 on redhat linux 4.0, and configured the
      Apache+mod_JK using the blog below:
      http://blogs.sun.com/dadelhardt/entry/loadbalancing_with_mod_jk_and_glassfish

      I executed the tomcat tests in the appserver-sqe workspace on this config.
      2 of the Servlet 2_3 tests failed in the mod_jk config which have passed in
      the regular runs... Here is the details of the testcase and how to reproduce.

      1) Deploy the below war file:
      /net/nimitz.red.iplanet.com/export2/mod_jk/BUGS/servlet2_3/product_test_servlet2_3.war

      Issue the below URLs':
      a) "Test the HttpServlet doTrace() method"
      URL: http://localhost:80/product_test_servlet2_3/Test17
      On a non-mod_jk setup, the HttpServlet.doTrace() returned its content as below

      <HTML>
      <HEAD>
      <TITLE>TestDoTraceMethodServlet : Test the HttpServlet doTrace() method </TITLE>
      </HEAD>
      <BODY BGCOLOR=white>
      <CENTER>
      <FONT COLOR=BLUE>
      <STRONG>Test Output</STRONG>
      </FONT>
      </CENTER>
      <HR>
      I am doTrace method of Test17. You are PASSED
      <HR>
      </BODY>
      </HTML>

      However, on a mod_jk setup, its content was just blank

      b) " Check the default behavior of ServletRequestWrapper methods"
      URL: http://localhost:80/product_test_servlet2_3/Test85?year=2003
      On a non-mod_jk setup, the HttpServletRequest.getContentLength() returned -1,
      however, on a mod_jk setup,
      HttpServletRequest.getContentLength() returned 0. The mismatch caused the test
      to fail since "-1" is the
      expected value

      -Shaline.

        Activity

        Hide
        gfbugbridge added a comment -

        <BT6563759>

        Show
        gfbugbridge added a comment - <BT6563759>
        Hide
        jfarcand added a comment -

        Re-assign to Amy to investigate. Shaline, can you run the same test on Tomcat
        and see if the test pass? If it doesn't pass in Tomcat, it means there is a
        configuration error somewhere. Also since we don't have control over mod_jk
        source, if the bug occurs also in Tomcat then we should file the bug in Tomcat,
        not in GlassFish to get help from the Tomcat community.

        Thanks!

        Show
        jfarcand added a comment - Re-assign to Amy to investigate. Shaline, can you run the same test on Tomcat and see if the test pass? If it doesn't pass in Tomcat, it means there is a configuration error somewhere. Also since we don't have control over mod_jk source, if the bug occurs also in Tomcat then we should file the bug in Tomcat, not in GlassFish to get help from the Tomcat community. Thanks!
        Hide
        Amy Roh added a comment -

        Lowering to P4 for further evaluation after discussing with the bug reporter.

        Show
        Amy Roh added a comment - Lowering to P4 for further evaluation after discussing with the bug reporter.
        Hide
        jluehe added a comment -

        I was able to reproduce the issue with TRACE. It looks like httpd intercepts any
        TRACE requests and responds to them directly, instead of forwarding the TRACE
        request to the servlet and invoking its implementation of doTrace().

        I have been unable to figure out if httpd can be configured to forward TRACE
        requests via AJP. I'll see if I can find an answer from the Apache folks.

        Show
        jluehe added a comment - I was able to reproduce the issue with TRACE. It looks like httpd intercepts any TRACE requests and responds to them directly, instead of forwarding the TRACE request to the servlet and invoking its implementation of doTrace(). I have been unable to figure out if httpd can be configured to forward TRACE requests via AJP. I'll see if I can find an answer from the Apache folks.
        Hide
        jluehe added a comment -

        The TRACE scenario, where the test case expects to see the output of the
        servlet's impl of doTrace() in the response, cannot be supported if GlassFish is
        front-ended by httpd, according to the following email exchange I've had on the
        httpd user forum:

        >----Original Message----
        >> From: Jan.Luehe@Sun.COM Jan.Luehe@Sun.COM
        >> Sent: Thursday, June 28, 2007 9:56 PM
        >> To: users@httpd.apache.org
        >> Subject: [users@httpd] Possible to configure httpd to forward
        >> TRACE requests to backend?
        >>
        >> Is it possible to configure httpd in such a way that, with TRACE being
        >> enabled, it forwards a TRACE request (via mod_jk) to a
        >> backend servlet?

        Apparently not... I was going to suggest that this might actually be a
        bona fide use-case for the <Limit> container, until I read the docs
        (http://httpd.apache.org/docs/2.2/mod/core.html#limit) where it
        specifically states: "The TRACE method cannot be limited."

        Rgds,
        Owen Boyle

        >>
        >> Right now, httpd seems to intercept any such request and reply to it
        >> directly.
        >>
        >> Thanks,
        >>
        >>
        >> Jan

        I'll investigate the "Check the default behavior of ServletRequestWrapper
        methods" test failure that was also reported as part of this issue next.

        Show
        jluehe added a comment - The TRACE scenario, where the test case expects to see the output of the servlet's impl of doTrace() in the response, cannot be supported if GlassFish is front-ended by httpd, according to the following email exchange I've had on the httpd user forum: >---- Original Message ---- >> From: Jan.Luehe@Sun.COM Jan.Luehe@Sun.COM >> Sent: Thursday, June 28, 2007 9:56 PM >> To: users@httpd.apache.org >> Subject: [users@httpd] Possible to configure httpd to forward >> TRACE requests to backend? >> >> Is it possible to configure httpd in such a way that, with TRACE being >> enabled, it forwards a TRACE request (via mod_jk) to a >> backend servlet? Apparently not... I was going to suggest that this might actually be a bona fide use-case for the <Limit> container, until I read the docs ( http://httpd.apache.org/docs/2.2/mod/core.html#limit ) where it specifically states: "The TRACE method cannot be limited." Rgds, Owen Boyle >> >> Right now, httpd seems to intercept any such request and reply to it >> directly. >> >> Thanks, >> >> >> Jan I'll investigate the "Check the default behavior of ServletRequestWrapper methods" test failure that was also reported as part of this issue next.
        Hide
        jluehe added a comment -

        I have an update on the 2nd aspect reported in this issue:

        > b) " Check the default behavior of ServletRequestWrapper methods"

        Turns out that Apache's httpd adds a Content-Length header with a value of "0"
        to the request. This explains why ServletRequest.getContentLength() returns "0"
        in this case.

        There is no such request header present when GlassFish is accessed directly,
        which means that ServletRequest.getContentLength() must (and does!) return "-1",
        according to the Servlet spec:

        Returns the length, in bytes, of the request body [...], or -1 if the
        length is not known.

        Please update the test so that it passes in either environment.

        Show
        jluehe added a comment - I have an update on the 2nd aspect reported in this issue: > b) " Check the default behavior of ServletRequestWrapper methods" Turns out that Apache's httpd adds a Content-Length header with a value of "0" to the request. This explains why ServletRequest.getContentLength() returns "0" in this case. There is no such request header present when GlassFish is accessed directly, which means that ServletRequest.getContentLength() must (and does!) return "-1", according to the Servlet spec: Returns the length, in bytes, of the request body [...] , or -1 if the length is not known. Please update the test so that it passes in either environment.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

          • Assignee:
            shaline
            Reporter:
            shaline
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: