[GLASSFISH-18095] Deployed app fails after updating/upgrading to GF 3.1.2 Created: 29/Dec/11  Updated: 20/Dec/16  Resolved: 05/Jan/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_dev
Fix Version/s: 3.1.2_dev

Type: Bug Priority: Critical
Reporter: Alex Pineda Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

System is running Oracle Enterprise Linux 5, JDK 1.6.0_30 along with GF 3.1.1 (build 12) release. Firefox 3.6.2 browser. Using internal repository located at http://bat-s10-1.us.oracle.com/sun_v3_release_test

Attachments: Text File server.log    
Tags: 3_1_2-approved


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)

Comment by Bobby Bissett [ 29/Dec/11 ]

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

Comment by Alex Pineda [ 29/Dec/11 ]

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.

Comment by Alex Pineda [ 29/Dec/11 ]

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

Comment by Alex Pineda [ 29/Dec/11 ]

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

Comment by scatari [ 29/Dec/11 ]

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

Comment by Shing Wai Chan [ 29/Dec/11 ]

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.

Comment by Sanjeeb Sahoo [ 30/Dec/11 ]

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?

Comment by Shing Wai Chan [ 30/Dec/11 ]

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.

Comment by Shing Wai Chan [ 04/Jan/12 ]
  • 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
Comment by Shing Wai Chan [ 05/Jan/12 ]

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.

Comment by Alex Pineda [ 17/Jan/12 ]

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.

Comment by Alex Pineda [ 19/Jan/12 ]

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

Generated at Mon Feb 27 15:56:24 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.