WebLogic Server Frequently Asked Questions

FAQs: J2EE Connector Architecture

• Why do I get the following exception when viewing the JNDI tree?
• Is it possible to use the Oracle database rather than PointBase with the current implementation of the WebLogic J2EE Connector Architecture?
• When deploying a resource adapter (.rar) to WebLogic Server, are its classes placed in the WebLogic classpath?
• Why does WebLogic Server invoke the ManagedConnection.addConnectionEventListener() function whenever the sample EJB calls ConnectionFactory.getConnection() to connect to the EIS?
• Why do I get an exception when I compile my EJB to use a Resource Adapter that supports CCI?
• The BEA com.bea.adapter.dbms.cci.ConnectionImpl does not directly implement javax.resource.cci.Connection. Is there a work-around for this?

Q. Why do I get the following exception when viewing the JNDI tree?

isSerializable(class.javax.naming.Binding) 
java.io.NotSerializableException:
java.io.PrintWriter at 
java.io.ObjectOutputStream.OutputObject 

A. The Weblogic Server JNDI implementation requires objects to be serializable, not referencable. A PrintWriter cannot be serialized and therefore should be declared transient.

Q. Is it possible to use the Oracle database rather than PointBase with the current implementation of the WebLogic J2EE Connector Architecture?

A. The sample provided contains a resource adapter that represents any database system. By default, configurations are set to use PointBase. In particular, the configuration properties in the weblogic-ra.xml file set a PointBase datasource. This can be replaced with Oracle settings.

Also, the resource adapter (in particular the ManagedConnectionFactory) must be implemented to support Oracle. The resource adapter provided in this sample makes use of the JDBC and therefore can support any database system which the resource adapter is configured to represent.

Q. When deploying a resource adapter (.rar) to WebLogic Server, are its classes placed in the WebLogic classpath?

For instance, I am deploying an EJB and a resource adapter (.rar), the EJB has no dependencies on the .rar because the EJB is writing to the common client interface (CCI). The EJB client application has sends/marshals as parameter classes that are defined in the .rar. For some reason the EJB's class loader hierarchy cannot find the definition of this .rar-specific class, even though the .rar is deploying successfully. I receive the following error on the EJB client:

java.rmi.UnmarshalException: error unmarshalling arguments; nested exception 
is: 
java.lang.ClassNotFoundException: 
com.mycompany.InteractionSpecImpl

A. When you pass an instance of com.myclientcompany.server.eai.InteractionSpecImpl as an argument to your EJB, the appServer needs to de-serialize (unmarshal) the object under the EJB context, and it needs the required class for unmarshalling, inside the ejb-jar(raTester.jar). So if you include the interactionspecimpl class in your ejb-jar file, then you do not need to include those classes in your server's classpath.

Q. Why does WebLogic Server invoke the ManagedConnection.addConnectionEventListener() function whenever the sample EJB calls ConnectionFactory.getConnection() to connect to the EIS?

A. This is a requirement and is part of the contract between the Resource Adapter and the application server.

Q. Why do I get an exception when I compile my EJB to use a Resource Adapter that supports CCI?

I specify javax.resource.cci.ConnectionFactory in the resource-ref but I get the following exception when I attempt to compile my EJB:

weblogic.xml.process.SAXValidationException: 
ejb-jar.enterprise-beans.session.resource-ref.res-type.
must be one of the values:
javax.sql.DataSource,javax.jms.QueueConnectionFactory,
javax.jms.TopicConnectionFactory,
java.net.URL,
javax.mail.Session
at
weblogic.ejb20.dd.xml.EjbJarLoader_EJB11.__post_84

A. Make sure your ejb-jar.xml is referencing the EJB2.0 DTD instead of the EJB1.1 DTD. The ConnectionFactory resource ref is only supported in the EJB 2.0 DTD.

Q. The BEA com.bea.adapter.dbms.cci.ConnectionImpl does not directly implement javax.resource.cci.Connection. Is there a work-around for this?

A. Yes. The BEA com.bea.adapter.dbms.cci.ConnectionImpl extends com.bea.adapter.cci.AbstractConnection; this in turn implements the Connection interface. The Proxy is constructed using the interfaces from the most-derived class (ConnectionImpl). The dumpFamilyTree printout shows that the getInterfaces call on the ConnectionImpl class does NOT include the Connection interface. However, the getInterfaces call on AbstractConnection does include the Connection interface.

The work-around is that the ConnectionImpl class must directly implement the interface class specified in the ra.xml file. (This might be a redundant statement in the code, particularly if it extends a class that has already implemented the class.) Then rebuild the adapter and try your test again.