Why Upgrade Tool is Necessary for Deployed Applications

Introduction

Java EE Application deployment/running to/on the GlassFish Application Server creates generated code. This creates some confusion when the server runtime is upgraded and the generated code is now incompatible. This forces the upgrade tool to actually redeploy the applications and that is a time-consuming process.

This page is created as a placeholder so that various teams handling different parts of Java EE applications/modules can write down if the generated folder can be completely deleted by upgrade process and thus the generated code can be generated on demand.

ID	Type of Application/Module	Generated code	Notes
0	Web applications with JSP pages that are bundled in the archive	The JSP pages are compiled to servlets in the generated folder.	For these, the generated folder can just be deleted so that after the runtime is upgraded, the generated code is regenerated. One caveat: The JSP sources should be available with the deployed applications. In other words, if the user has deployed the application using JSP precompilation and thrown away the JSP source, we can't do much.
1	CMP beans that are bundled in the archive	The generated code includes: concrete CMP classes, JDOState classes, and JDOHelper classes (both, .java, and .class files), with the corresponding .mapping files; (ii) .jdbc files to be executed to drop and/or create the tables; (iii) .dbschema file for java2db or auto-capture-schema, and (iv) changes to the existing sun-ejb-jar.xml or sun-cmp-mappings.xml in case of java2db or auto-capture-schema.	The generated folder can not be removed if there are CMP beans in the archive. Any further details are still under investigation.