Chapter 7 Application and Deployment Problems

This chapter addresses problems that you may encounter while deploying applications in the Application Server environment.

Application Problems

persistence.support.JDODataStoreException

A com.sun.jdo.api.persistence.support.JDODataStoreException is generated by an application, with a nested java.sql.SQLException indicating a duplicate primary key.

Even if the application is checking for a CreateException, it does not see one. The Enterprise JavaBeans specification requires a CreateException to be thrown only if two beans with the same primary key are created in the same transaction, so a CreateException is not thrown on transaction rollback if two entity beans with duplicate primary keys are created.

Solution

If an application might create an entity bean with a duplicate primary key, check to see if the primary key exists by calling findByPrimaryKey before calling create.

EJB Problems

Can’t set TRANSACTION_SERIALIZABLE level for a bean

Runtime exception from ejbCreate()

Can’t set TRANSACTION_SERIALIZABLE level for a bean

Since the Release Notes say that check-modified-at-commit flag is not implemented for this release, is there an equivalent of the Weblogic <transaction-isolation> element in Sun Java System Application Server?

Solution

First identify which resource is being used in that bean, then add the following attribute to the jdbc-connection-pool in the server.xml file:

This is an optional element and does not exist in the server.xml file by default. You must explicitly add it.

You can do this either using the Administration interface or using the command-line interface to modify the server.xml file, then running the asadmin reconfig command.

Runtime exception from ejbCreate()

An "Unable to create reference" runtime exception is generated by ejbCreate when it tries to create a instance for a composite primay key.

Explanation

Every entity bean must have unique primary key. The primary key class must obey the following rules:

The primary key class must be Serializable.
The client and server can then exchange keys using by-value semantics.

The primary key class must override the equals and hashCode methods.
The server uses these methods to see if a bean is already resident in memory, so proper implementation is crucial! If you get it wrong or forget to override the equals or hashCode methods( violation of the EJB 2.0 specification) the bean fails at runtime for a variety of seemingly bizarre reasons.

Solution

The Entity bean's primary key class must provide suitable implementation of the hashcode() and equals(Object other) methods to simplify the management of the primary keys by the client code. (The implementation of these methods is also mandated by the EJB 2.0 specification, in section 12.2.12.)

CMP Problems

Are you using a supported JDBC driver?

For a list of the supported JDBC drivers for the Application Server, refer to the Sun Java System Application Server Platform Summary.

Parser exceptions generated by verifier

This section discusses the SAX Parser exceptions generated by the verifier and how to interpret them. It covers the following exceptions:

Element type "sun-ejb-jar" is not declared.

Root element type is "sun-ejb-jar", but was declared to be "ejb-jar"

java.net.UnknownHostException: www.sun.com

Expected "</name>" to terminate element starting on line 8.

Element "ejb" does not allow "jndi-name" here.



Note	The parser exceptions generated for the sun-web.xml file have a different error statement owing to the fact that the Schema2Beans framework is used to create the XML graph. The error messages described here follow the "Cause By: " line when verifying that file.

Element type "sun-ejb-jar" is not declared.

Error: ** Error trying to process file: com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 5, Element type "sun-ejb-jar" is not declared.

com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 5, Element type "sun-ejb-jar" is not declared.

at com.iplanet.ias.deployment.EjbBundleXmlReader.load(EjbBundleXmlRead er.java:265)

at com.iplanet.ias.deployment.EjbBundleXmlReader.loadStdAloneModule(Ej bBundleXmlReader.java:162)

There are two probable causes of this exception. The exception usually points to the root element. The most notable cause is the fact that the DOCTYPE has not been declared. Hence in case of a validating parser, there is no DTD to validate against and the error message is spurted out. Another common problem is the PUBLIC id that is being specified. The validating parser looks for the DTD by resolving the path that is mapped to the string specified in the PUBLIC id. Hence if the string points to a different DTD you will get such an exception because the specified root elements will differ. Another inference of the error is the fact that the root tag for the XML does not match the one that is specified in the DTD.

Root element type is "sun-ejb-jar", but was declared to be "ejb-jar"

Error: ** Error trying to process file: com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 6, Root element type is "sun-ejb-jar", but was declared to be "ejb-jar".

com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 6, Root element type is "sun-ejb-jar", but was declared to be "ejb-jar".

at com.iplanet.ias.deployment.EjbBundleXmlReader.load(EjbBundleXmlRead er.java:265)

at com.iplanet.ias.deployment.EjbBundleXmlReader.loadStdAloneModule(Ej bBundleXmlReader.java:162)

The most probable cause of this parser exception is the fact that the root element declared in the DOCTYPE for the XML does not match the root element in the DTD furnished. The root element is the starting tag of the xml. This is compared with the root element that is declared in the DOCTYPE. The DTD is got from the PUBLIC id which is resolved to point to the physical DTD.

java.net.UnknownHostException: www.sun.com

Error: ** Error trying to process file: com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 4, External entity not found: "http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0- 0.dtd".

com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 4, External entity not found: "http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0- 0.dtd".

at com.iplanet.ias.deployment.EjbBundleXmlReader.load(EjbBundleXmlRead er.java:265)

at com.iplanet.ias.deployment.EjbBundleXmlReader.loadStdAloneModule(Ej bBundleXmlReader.java:162)

Error: ** Error trying to process file: com.iplanet.ias.deployment.AppConfigException: Error creating sun-specific web xml graph

com.iplanet.ias.deployment.AppConfigException: Error creating sun-specific web xml graph

at com.iplanet.ias.deployment.WebBundleXmlReader.createIasWebDescripto rObj(WebBundleXmlReader.java:297)

at com.iplanet.ias.deployment.WebBundleXmlReader.load(WebBundleXmlRead er.java:257)

Another common problem that cuases the exception is the absence of the internet connection to connect to the URL The Application Server has a catalog mechanism whereby all the DTDs required for validating parsing are mapped to their physical locations present in the appserv-rt.jar. So you should never get this exception if you are validating a standard J2EE or a Sun specific deployment descriptor.

If you do get the exception, then the cause is a mismatch in the PUBLIC id that is specified in the file, and the one in the DTD. The String.equals() match is done for the mapping resolution, so the PUBLIC id must exactly match the PUBLIC id for the intended DTD. Even a tiny error like leaving out a comma can cause this exception.

Expected "</name>" to terminate element starting on line 8.

Error: ** Error trying to process file: com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 8, Expected "</name>" to terminate element starting on line 8.

com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 8, Expected "</name>" to terminate element starting on line 8.

at com.iplanet.ias.deployment.EjbBundleXmlReader.load(EjbBundleXmlRead er.java:265)

at com.iplanet.ias.deployment.EjbBundleXmlReader.loadStdAloneModule(Ej bBundleXmlReader.java:162)

This exception shows that line 8 is missing terminator name tag, which violates XML’s well-formedness constraints. Since XML is case sensitive., it is also possible to have a starting name tag and ending name tag that have the same letters, but which do no match in case as, for example, <name>... </NAME>. The exception can also be caused by not closing an empty tag with a "/" at the end, as in <img .. > instead of the correct <img ... />.

Element "ejb" does not allow "jndi-name" here.

Error: ** Error trying to process file: com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 10, Element "ejb" does not allow "jndi-name" here.

com.iplanet.ias.deployment.AppConfigException: Error parsing sun-specific ejb deployment descriptor, line 10, Element "ejb" does not allow "jndi-name" here.

at com.iplanet.ias.deployment.EjbBundleXmlReader.load(EjbBundleXmlRead er.java:265)

at com.iplanet.ias.deployment.EjbBundleXmlReader.loadStdAloneModule(Ej bBundleXmlReader.java:162)

There are two reasons for such an exception. The first reason is that the tag specified in the error statement, here jndi-name is not declared in the DTD or the tag specified has the wrong spelling or the case.

Another common and reason is the sequence of the tag specified in the DTD. If the DTD specifies that the tag ejb is defined as

then we cannot define jndi-name before the ejb-name tag. (Note: DTD validation checks case sensitivity as well as the sequence of the tags defined in the DTD.)

Ant Problems

Can’t run Ant remotely.

To run Ant from a remote machine, the Ant utility must be installed on that machine. You can deploy to the remote machine using the Administration interface, and you can use the asadmin command or the Sun ONE Studio for deployment on the remote machine.

Additionally, the default settings that are set up during Application Server installation assume the local instance to be the target for all administrator operations from asant (deployment, resource registration, and so on). This can be changed by editing the install_dir/samples/common.properties file. This file is referred to by all the samples that use common.xml, that is, most of the samples. A variety of settings can be customized: admin host, port, user, password, target instance, and so on.

Solution

Edit the file to set the values for the remote machine or instance and run the following command on the sample.

Previous Contents Index Next
Sun Java System Application Server 7 2004Q2 Update 1 Standard and Enterprise Edition Troubleshooting Guide