Enterprise Application Deployment

Project deployment in MyEclipse is based on the WTP application server framework. You can install any WTP server connector into the MyEclipse workbench. However, MyEclipse provides a large set of popular WTP server connectors with special capabilities that allow deployed enterprise application projects to stay in sync with project resources during development.

MyEclipse Enterprise workbench enables deployment of Web, EJB, and Enterprise Application projects to any MyEclipse enabled application server in either exploded or packaged archive modes. The Java EE standard dictates the packaged file structure under which each application type is deployed. Typically, Java EE applications are deployed into production environments as archived versions of their respective Java EE dictated file structure, i.e., a packaged archive deployment. An exploded archive deployment consist of making the application’s raw folder and file structure directly available to an application server. No archive is involved.

MyEclipse is able to deploy a Java EE project to one or more application servers in either exploded or packaged archive forms. When a Java EE project is deployed in exploded archive, the MyEclipse Deployment Service, using “Sync-on-Demand” technology keeps the deployment synchronized with the project’s states. Note that exploded archive deployment is not a standard Java EE deployment form. Therefore, the Deployment Service restricts the deployment forms that a project may take on to those supported by the target deployment server.

Deployment service diagram

Deployment Model Trade-offs

Packaged archive deployment, unlike exploded deployment, does not support incremental or automatic archive update. Thus, a package deployment become out of sync with its source project as edits are made to the project. Sync-on-demand does not suffer from this synchronization problem as project deployments are continuously updated in real-time as edits are made to the source project. Both deployments have their strengths and weaknesses. For example packaged deployment is less efficient than exploded deployment. This is because to update a packaged deployment with incremental changes requires rebuilding of the entire archive. Thus, packaged deployment requires the same amount of work to reflect a change of one resource as it does in a case where an entire project is updated.

The benefit of the packaged deployment model is that it’s the Java EE deployment standard and the format for production deployment. Thus, all application servers support the packaged deployment model. Exploded deployment is fast and immediate. Incremental changes to your project are immediately reflected on the servers to which the project is deployed. Yet, exploded deployment is not supported in a standard manner across all Java EE application servers.

Deployment Management Facility

MyEclipse deployments are managed using the Deployment Manager. This window allows users to view existing deployments, add new deployments, and remove old deployments. The image below depicts projects deployed on a single server.

Manage Deployments window

Deployment Facts

• When a Java EE project is deployed, it remains deployed until it is removed, or undeployed.
• The undeployment process is initiated explicitly by a user undeployment request or implicitly as the result of a “deployment termination event” (see Undeployment Events below).
• Deployments persist across Eclipse sessions. Thus, you might exit MyEclipse and return at a later time to resume deployment management or Sync-on-Demand deployment.
• Exploded project deployment physically copies a project’s runtime resources to the auto-deployment location of the target application server.
• A web project’s deployments are named after the project’s context-root except for when the context-root is the default application, i.e., context-root = ‘/’. In such case, the deployment is named according to the application server’s default application name. For example, Tomcat’s default application is named “root”.
• Web module projects, i.e., modules of an enterprise project, are deployed under a separate context-root that is specified when the web project is added to the enterprise project.
• During the deployment process, if a resource exists on the server, you have the option to either delete the remote resource, back up the resource for later restoration when the principal deployment is undeployed, or cancel the deployment process.
• Undeployment involves physically removing the deployed resource(s) from an application server’s deployment area. If conflicting resources were backed up during the project’s deployment phase, as it is undeployed these resources are restored to their original form.
• The resource backup process renames the conflicting target resource by appending the suffix “.myeclipse.bak” to the resource’s base name.

Deployment Termination Events

To maintain a deployment’s integrity and relevance, the Deployment Service automatically undeploys Java EE projects who’s state changes in a significant manner. The following sections identify the undeployment events for each Java EE project type.

Web Project Termination Events

• Web project close + MyEclipse restart
• Web project delete
• Web project rename
• Web project context-root revision

EJB Project Termination Events

• EJB project close + MyEclipse restart
• EJB project delete
• EJB project rename
  
  

Enterprise Application Project Termination Events

• EAR project close + MyEclipse restart
• EAR project delete
• EAR project rename
• Add a module project
• Remove a module project
• Undeployment of a module project