The preferred way of installing J2EE into the deployed WSO2 SOA Enablement Server is to include J2EE in the installation process and run the J2eeIntegrate tool. However, the behavior of various application servers may affect J2EE components. The following are suggested ways to avoid known problems:
Problem: EJB Web service and JNDI connector components heavily use remote references as described in the chapters Application Integration and Remote References in the Developer's Guide.
By default, the serializer processes every interface of the serialized object. Every object instantiated as a result of JNDI lookup over JNDI connector and every remote interface of stateful or entity EJBs obtained using an EJB Web service is a remote reference.
WSO2 SOA Enablement Server tries to serialize the objects provided by the application server. Their classes usually implement a number of interfaces other than the required one. Furthermore, these classes do not always directly implement the remote or home interface. The result is that the remote reference tries to provide every interface of the remote object and it may cause class cast or class not found exceptions on the client.
Solutions:
Include all interfaces in the client classpath.
Use interfaceIntrospectorConfig, which allows you to prevent useless interfaces from being serialized.
Remap one interface to another.
If you deploy WSO2 SOA Enablement Server using the J2eeIntegrate tool, additional configuration files are included in the deployed WSO2 SOA Enablement Server configuration. These files are WASP_HOME/conf/porting/[as]/[as]-specific.xml. They contain the default interfaceIntrospectorConfig.
For more information, please see the interfaceIntrospectorConfig.xml for Bea Weblogic example.
Example 6. interfaceIntrospectorConfig for BEA WebLogic server
<?xml version="1.0" encoding="UTF-8"?> <config name="weblogic-specific"> <interfaceIntrospectorConfig name="weblogic"> <exclude class="weblogic.ejb20.replication.ReplicatedHome"/> <exclude class="weblogic.ejb20.interfaces.RemoteHome"/> <exclude class="weblogic.rmi.extensions.server.Stub"/> <exclude class="weblogic.rmi.extensions.server.RemoteWrapper"/> <exclude class="weblogic.rjvm.PeerGoneListener"/> <exclude class="weblogic.jms.extensions.WLSession"/> <exclude class="weblogic.utils.PlatformConstants"/> <exclude class="weblogic.jms.dispatcher.Invocable"/> <exclude class="weblogic.jdbc.rmi.RmiStatement"/> <exclude class="weblogic.rmi.internal.StubInfoIntf"/> <exclude class="weblogic.ejb20.interfaces.BaseEJBObjectIntf"/> <exclude class="weblogic.ejb20.interfaces.EntityEJBObjectIntf"/> <exclude class="weblogic.ejb20.interfaces.StatefulEJBObjectIntf"/> <remap fromClass="weblogic.jdbc.common.internal.RemoteDataSource" toClass="javax.sql.DataSource"/> <remap fromClass="weblogic.jdbc.vendor.oracle.OracleConnection" toClass="java.sql.Connection"/> <remap fromClass="weblogic.jdbc.vendor.oracle.OracleStatement" toClass="java.sql.Statement"/> <remap fromClass="weblogic.jms.extensions.WLQueueSession" toClass="javax.jms.QueueSession"/> <remap fromClass="weblogic.jms.extensions.WLTopicSession" toClass="javax.jms.TopicSession"/> </interfaceIntrospectorConfig> </config>
Problem: When you use the JMS transport component, it is preconfigured to use default destinations (queue or topic) and those connection factories that run within the application server by default, or in its "example" configuration. If you port WSO2 SOA Enablement Server with JMS transport into an application server where these objects are not accessible, JMS transport fails.
Solution: Edit the configuration in the deployment descriptor of the JMS transport package and redeploy it.