Deploying from an EAR, JAR, or WAR If you have trouble deploying from an EAR, JAR, or WAR, use the verifier tool to verify that it is valid. For details, see Verifier Tool.
If you are having trouble deploying a Web application, check the J2EE requirements. If an application does not adhere to the J2EE rules, you may not be able to deploy it. For example, because they require local access, entity beans that participate in a container-managed relationship must all reside in the same EJB-JAR.
On Solaris and Linux, deploying a JAR file may fail if the class path includes “$JAGUAR,” an environment variable that was used in versions of EAServer earlier than 6.0, and which therefore may include some 5.x classes in the class path.
Static variables in Java Static variables must be final or primitive, and cannot be larger than 32 bits. They can lead to potential race conditions: a variable is defined at the class level rather than the instance level; two threads try to modify a variable simultaneously. Race conditions are difficult to troubleshoot, and cause intermittent problems. You can use synchronization to prevent race conditions, but synchronization can cause performance bottlenecks.
Synchronizing component skeletons A skeleton class interprets component invocation requests and calls the corresponding method in your component with the parameter values supplied by the client. When a client sends an invocation request, the skeleton reads the parameter data and calls the Java method. When the method returns, the skeleton sends output parameter values, return values, and exception status to the client.
Problems can arise if component skeletons get out of sync. Generate a new skeleton class if you do any of the following:
Install the component in a different EAServer package
Change the name of the implementation class or move it to a different Java package
Add a method to the component interface
Delete a method from the component interface
Change the signature of an existing method in the component interface
