![]() |
![]() |
|
|
| |
FAQs: J2EE Connector Architecture
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
The Weblogic Server JNDI implementation requires objects to be serializable, not referencable. A PrintWriter cannot be serialized and therefore should be declared transient.
Is it possible to use the Oracle database rather than Cloudscape with the current implementation of the WebLogic J2EE Connector Architecture?
The sample provided contains a resource adapter that represents any database system. By default, configurations are set to use Cloudscape. In particular, the configuration properties in the weblogic-ra.xml file set a Cloudscape 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.
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
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.
Why does WebLogic Server invoke the ManagedConnection.addConnectionEventListener() function whenever the sample EJB calls ConnectionFactory.getConnection() to connect to the EIS?
This is a requirement and is part of the contract between the Resource Adapter and the application server.
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
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.
How is security handled in the WebLogic J2EE Connector Architecture?
Due to the fact that the current configuration and packaging requirements for resource adapters in WebLogic Server require the hand-editing of the weblogic-ra.xml file, any new passwords specified in the security-principal-map entries are done in clear-text.
BEA understands the importance of protecting security passwords. Hence, we provide a Converter Tool that allows for the encryption of all passwords present in the weblogic-ra.xml file. The Converter Tool is shipped in the standard weblogic.jar file. For more information about the Password Converter Tool, see Using the Password Converter Tool in the Configuration section of the Programming the WebLogic J2EE Connector Architecture Guide at ../jconnector/index.html.
The BEA com.bea.adapter.dbms.cci.ConnectionImpl does not directly implement javax.resource.cci.Connection. Is there a work-around for this?
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.
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|