glassfish
  1. glassfish
  2. GLASSFISH-18095

Deployed app fails after updating/upgrading to GF 3.1.2

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1.2_b16
    • Fix Version/s: 3.1.2_b17
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      Description

      There are two ways to see this problem during update/upgrading of the system. Update can be defined as "in-place" upgrade. Upgrade as "side-by-side" upgrade. The simplest and more direct is in the side-by-side upgrade test scenario. The overall steps are:

      • Install GF 3.1.1 full distribution on a OEL5 system using default values (port numbers and no password) in $HOME/glassfish311
      • Deploy hello.war sample application (available at https://glassfish.dev.java.net/downloads/quickstart/hello.war)
      • Shutdown the GF 3.1.1 server
      • Install GF 3.1.2 (build15 or build16) using default values at $HOME/glassfish3.
      • Verify the installation is proper. Shutdown the server
      • invoke asupgrade. Point the tool to the location of the GF 3.1.1 domain ($HOME/glassfish311/domains/domain1).
      • When done, start the GF 3.1.2 server (asadmin start-domain domain1).
      • Go to the deployed URL location (localhost:8080/hello).
        At this point, the hello.war app fails to display and the URL displays HTTP Status 500. In the GF 3.1.2 server log (attached to this report) the following is noted:

      [#|2011-12-28T17:41:16.915-0800|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=22;_ThreadName=Thread-2;|StandardWrapperValve[jsp]: PWC1406: Servlet.service() for servlet jsp threw exception
      org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP

      PWC6197: An error occurred at line: 26 in the jsp file: /index.jsp
      PWC6199: Generated servlet error:
      string:///index_jsp.java:100: cannot access javax.servlet.jsp.jstl.core.ConditionalTagSupport
      class file for javax.servlet.jsp.jstl.core.ConditionalTagSupport not found

      PWC6197: An error occurred at line: 26 in the jsp file: /index.jsp
      PWC6199: Generated servlet error:
      string:///index_jsp.java:101: cannot find symbol
      symbol : method setPageContext(javax.servlet.jsp.PageContext)
      location: class org.apache.taglibs.standard.tag.rt.core.IfTag

      PWC6197: An error occurred at line: 26 in the jsp file: /index.jsp
      PWC6199: Generated servlet error:
      string:///index_jsp.java:102: cannot find symbol
      symbol : method setParent(<nulltype>)
      location: class org.apache.taglibs.standard.tag.rt.core.IfTag

      PWC6197: An error occurred at line: 26 in the jsp file: /index.jsp
      PWC6199: Generated servlet error:
      string:///index_jsp.java:104: cannot find symbol
      symbol : method doStartTag()
      location: class org.apache.taglibs.standard.tag.rt.core.IfTag

      PWC6199: Generated servlet error:
      string:///index_jsp.java:151: cannot find symbol
      symbol : method doAfterBody()
      location: class org.apache.taglibs.standard.tag.rt.core.IfTag

      PWC6199: Generated servlet error:
      string:///index_jsp.java:156: cannot find symbol
      symbol : method doEndTag()
      location: class org.apache.taglibs.standard.tag.rt.core.IfTag

      PWC6199: Generated servlet error:
      string:///index_jsp.java:157: reuse(javax.servlet.jsp.tagext.JspTag) in org.apache.jasper.runtime.TagHandlerPool cannot be applied to (org.apache.taglibs.standard.tag.rt.core.IfTag)

      PWC6199: Generated servlet error:
      string:///index_jsp.java:160: reuse(javax.servlet.jsp.tagext.JspTag) in org.apache.jasper.runtime.TagHandlerPool cannot be applied to (org.apache.taglibs.standard.tag.rt.core.IfTag)

      PWC6197: An error occurred at line: 18 in the jsp file: /index.jsp
      PWC6199: Generated servlet error:
      string:///index_jsp.java:225: package javax.servlet.jsp.jstl.fmt does not exist

      at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:129)
      at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:299)
      at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:392)
      at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453)
      at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
      at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
      at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
      at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
      at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
      at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
      at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
      at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
      at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
      at java.lang.Thread.run(Thread.java:662)

        Activity

        Hide
        Bobby Bissett added a comment -

        Am assigning to web container to check out the servlet package missing errors.

        A domain upgrade should not be required to move from 3.1.X to 3.1.Y. In other words, you should be able to simply copy the 3.1.1 domain to the 3.1.2 domains directory and just start the 3.1.2 server. If that doesn't work, it's a bug unless someone has decided otherwise.

        That being said, running a domain upgrade on any server shouldn't break that server, so "upgrading" should work in all of these cases:
        3.1.1 -> 3.1.1
        3.1.1 -> 3.1.2
        3.1.2 -> 3.1.2

        Show
        Bobby Bissett added a comment - Am assigning to web container to check out the servlet package missing errors. A domain upgrade should not be required to move from 3.1.X to 3.1.Y. In other words, you should be able to simply copy the 3.1.1 domain to the 3.1.2 domains directory and just start the 3.1.2 server. If that doesn't work, it's a bug unless someone has decided otherwise. That being said, running a domain upgrade on any server shouldn't break that server, so "upgrading" should work in all of these cases: 3.1.1 -> 3.1.1 3.1.1 -> 3.1.2 3.1.2 -> 3.1.2
        Hide
        Alex Pineda added a comment -

        I see the same problem if I do an Update (in-place upgrade)from 3.1.1 to 3.1.2 using the internal repository and if I execute an "image update". I just noted the simplest test scenario to help debug the issue.

        Show
        Alex Pineda added a comment - I see the same problem if I do an Update (in-place upgrade)from 3.1.1 to 3.1.2 using the internal repository and if I execute an "image update". I just noted the simplest test scenario to help debug the issue.
        Hide
        Alex Pineda added a comment -

        One more note. This test scenario passed with issues using GF3.1.2 build13.

        Show
        Alex Pineda added a comment - One more note. This test scenario passed with issues using GF3.1.2 build13.
        Hide
        Alex Pineda added a comment -

        Correction. Please disregard the previous comment. I meant to say the test scenario worked without problems using GF3.1.2 build 13.

        Show
        Alex Pineda added a comment - Correction. Please disregard the previous comment. I meant to say the test scenario worked without problems using GF3.1.2 build 13.
        Hide
        scatari added a comment -

        Please also see the related issue http://java.net/jira/browse/GLASSFISH-18093

        Show
        scatari added a comment - Please also see the related issue http://java.net/jira/browse/GLASSFISH-18093
        Hide
        Shing Wai Chan added a comment -

        In GlassFish, the jsp compilation classpath is from default-web.xml.
        Due to maven versioning change, some of the jar files are renamed. Hence some of the jars cannot be found.

        One can workaround the issue as follows:

        • create a dump jsp-impl.jar in modules dir with the following MANIFEST.MF

        Class-Path: javax.el-api.jar javax.el.jar javax.faces.jar javax.servlet-api.jar javax.servlet.jsp-api.jar javax.servlet.jsp.jstl-api.jar

        Note that there is no OSGi information there.

        Show
        Shing Wai Chan added a comment - In GlassFish, the jsp compilation classpath is from default-web.xml. Due to maven versioning change, some of the jar files are renamed. Hence some of the jars cannot be found. One can workaround the issue as follows: create a dump jsp-impl.jar in modules dir with the following MANIFEST.MF Class-Path: javax.el-api.jar javax.el.jar javax.faces.jar javax.servlet-api.jar javax.servlet.jsp-api.jar javax.servlet.jsp.jstl-api.jar Note that there is no OSGi information there.
        Hide
        Sanjeeb Sahoo added a comment -

        No, we can't have non-osgi modules in modules/.

        May I know why jspc does not use lib/javaee.jar to refer to all API jars?

        Show
        Sanjeeb Sahoo added a comment - No, we can't have non-osgi modules in modules/. May I know why jspc does not use lib/javaee.jar to refer to all API jars?
        Hide
        Shing Wai Chan added a comment -

        According to my understanding, we keep the set of API jars small for jspc for performance.
        Also, jspc need to have jasper implementation which is not path of claspath javaee.jar.

        Show
        Shing Wai Chan added a comment - According to my understanding, we keep the set of API jars small for jspc for performance. Also, jspc need to have jasper implementation which is not path of claspath javaee.jar.
        Hide
        Shing Wai Chan added a comment -
        • What is the impact on the customer of the bug?
          It impacts any customer who upgrade from 3.1.1 to 3.1.2.
        • What is the cost/risk of fixing the bug? Low. pom.xml changes to include the missing jars.

        How risky is the fix? How much work is the fix? Is the fix complicated?

        • Is there an impact on documentation or message strings? No
        • Which tests should QA (re)run to verify the fix did not destabilize GlassFish? jstl and jsf
        • Which is the targeted build of 3.1.2 for this fix? b18
        Show
        Shing Wai Chan added a comment - What is the impact on the customer of the bug? It impacts any customer who upgrade from 3.1.1 to 3.1.2. What is the cost/risk of fixing the bug? Low. pom.xml changes to include the missing jars. How risky is the fix? How much work is the fix? Is the fix complicated? Is there an impact on documentation or message strings? No Which tests should QA (re)run to verify the fix did not destabilize GlassFish? jstl and jsf Which is the targeted build of 3.1.2 for this fix? b18
        Hide
        Shing Wai Chan added a comment -

        Per discussion, we will put the additional class path information in one of the existing jar scanned by Jsp compiler. In our case, we will put it inside web-glue.jar

        Sending pom.xml
        Transmitting file data .
        Committed revision 51914.

        Show
        Shing Wai Chan added a comment - Per discussion, we will put the additional class path information in one of the existing jar scanned by Jsp compiler. In our case, we will put it inside web-glue.jar Sending pom.xml Transmitting file data . Committed revision 51914.
        Hide
        Alex Pineda added a comment -

        Which build is this issue fixed on. In the bug fix justification it says Build18, but in the "fixed version" element it says "build17". Can you please clarify.

        Show
        Alex Pineda added a comment - Which build is this issue fixed on. In the bug fix justification it says Build18, but in the "fixed version" element it says "build17". Can you please clarify.
        Hide
        Alex Pineda added a comment -

        Verified fix in build 18. The sample app is viewable after the Upgrade.

        Show
        Alex Pineda added a comment - Verified fix in build 18. The sample app is viewable after the Upgrade.

          People

          • Assignee:
            Shing Wai Chan
            Reporter:
            Alex Pineda
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: