Sun GlassFish Enterprise Server v3 Prelude Troubleshooting Guide

Issues Related to Applications

Error When Deploying EAR

Description

You tried to deploy a traditional EAR type of application in Enterprise Server but received an error message instead.

Solution

Enterprise Server v3 Prelude does not include a full EJB 3.0 implementation and does not support traditional EJB modules. Applications can be packaged for deployment in web archive (WAR) format only. You can download a partial implementation of a few EJB 3.1 features using Update Tool, but the bulk of EJB 3.0 (ejb-jar and .ear support) is not available . If you need a full Java EE 5 implementation, Sun Java System Application Server 9.1 (GlassFish v2) is a better choice for now. Web applications are the only Java EE application type supported by Enterprise Server v3 Prelude.

For related information, see the following:

Cannot Find SunDeploymentManager

Description

You cannot find SunDeploymentFactory.java.

Solution

Enterprise Server v3 Prelude does not include the JSR-88 API (SunDeploymentManager is the implementation of the JSR 88 API). The JSR 88 specification provides a complete description of the APIs required by the Java EE platform to enable development of platform-independent deployment tools.

Cannot Undeploy or Redeploy Application With Open Streams to jar Files (Windows Only)

Description

On Windows systems, after running an application, subsequent attempts to undeploy it or redeploy it throw exceptions about the server being unable to delete a file or rename a directory.

On Windows systems, an application may use getClass().getResource or getResourceAsStream methods to locate a resource inside the application, particularly in jar files that are in the application or accessible to it. If the streams remain open, subsequent attempts to redeploy or undeploy the application can fail. In addition, the Java runtime by default caches streams to jar files for performance reasons.

Solution

Be sure to close streams opened by your applications. Also, if an application needs to be redeployed or undeployed repeatedly, and also needs to obtain a resource from a jar file using getResource or getResourceAsStream, consider using getClass().getResource, which returns a URL object, then invoke the url.setUseCaches method to turn off caching for that jar file, and use url.getInputStream() to obtain the stream.

Although turning off caching for access to the jar file can slow performance, this approach does allow the application to be undeployed or redeployed. Note also that if the getClass().getResourceAsStream method is used instead, then the jar file in which the resource is located is cached (this is the default Java runtime setting) and remains open until the server is stopped.