Class cast exception when grabbing remote EJB 3 interface

[Stu Quinn]

Good day,

I just installed RAD 8 over WebSphere 7.0 and want to knock out a simple example of an EJB 3.0 stateless session that is called from a java client. I have performed this over JBOSS and Glassfish in the past, but now seem to be tripping up on WebSphere. Must be doing something sideways. Port 2811 is the BOOTSTRAP_ADDRESS.

Here is the entry from the log on startup.
The server is binding the com.stu.sample.ejb.business.svc.CustomerSvcRemote interface of the CustomerSvc enterprise bean in the SampleEjbSvc.jar module of the SampleEjbEAR application. The binding location is: ejb/SampleEjbEAR/SampleEjbSvc.jar/CustomerSvc#com.stu.sample.ejb.business.svc.CustomerSvcRemote



Here is the jUnit test from a stand alone Java client.

	@Test
	public void testHello() {
		
		Context initialContext = null;

		try {
			Hashtable env = new Hashtable();  
			env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");  
			env.put(Context.PROVIDER_URL, "corbaloc:iiop:localhost:2811");  			
			
			System.out.println("Build the context");
			initialContext = new InitialContext(env);
			
			
			System.out.println("Fetch out object from the context");			
			CustomerSvcRemote svc = (CustomerSvcRemote) initialContext.lookup("ejb/SampleEjbEAR/SampleEjbSvc.jar/CustomerSvc#com.stu.sample.ejb.business.svc.CustomerSvcRemote");
			
			String result = svc.hello();
			
			assertEquals("Hi", result);
			
			System.out.println(result);
			
		} catch (NamingException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
	}

Here is the exception
java.lang.ClassCastException: org.omg.stub.java.rmi._Remote_Stub incompatible with com.stu.sample.ejb.business.svc.CustomerSvcRemote
at com.stu.sample.ejb.business.svc.CustomerSvcTest.testHello(CustomerSvcTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)





Here is the bean impl

@Stateless(mappedName = "ejb/CustomerSvc")
public class CustomerSvc implements CustomerSvcRemote {

    /**
     * Default constructor. 
     */
    public CustomerSvc() {
        // TODO Auto-generated constructor stub
    }

    public String hello() {
    	return "Hi";
    }
    
}

Here is the remote interface

@Remote
public interface CustomerSvcRemote {
    public String hello();
}

Any help for this WebSphere newbie would be appreciated.

[Deepak Pant]

Have you tried running createEJBStubs (cmd or sh based on OS) file on the EAR file that you are deploying to WebSphere? This file is present in the bin directory of your websphere profile. Run this file on the final EAR file. It will create another EAR file with Remote stub classes bundled in it. Deploy that EAR file to WebSphere and re-test your code.

[Stu Quinn]

Deepak,

Thanks for the suggestion, however per the IBM docs I did not think this was necessary. Using RAD 8 over WebSphere 7 a client stub project was auto-generated and the jar is contained within the EAR I deployed for the service.

Below is an excerpt from the IBM docs http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ejbfep.multiplatform.doc/info/ae/ae/rejb_3stubscmd.html

For many client-side scenarios, the WebSphere Application Server Just-In-Time (JIT) deployment feature dynamically generates the RMI-IIOP stub classes that are required for invocation of remote EJB 3.0 business interfaces. However, there are some scenarios where the JIT deploy environment is not available to dynamically generate these classes. In these scenarios, the createEJBStubs command must be used instead to generate and embed the client-side stub class files in your client application. If your client environment is one of the following, use the createEJBStubs command:

* "Bare" Java Standard Edition (SE) clients, where a Java SE Java Virtual Machine (JVM) is the client environment.
* A WebSphere Application Server container (web container, EJB container, or application client container) from a version earlier than version 7, or without the Feature Pack for EJB 3.0 applied.
* Non-WebSphere Application Server environments.


Perhaps I am missing something. I will follow up some more in the morning (USA PCT).

Stu

[Sonx Nkuks]

Hi i have the same problem. I ran createEjbStub and deployed that EAR. Am not quite sure where these stubs are created and what they look like so that i can confirm they were created. But i think two new jars were added on the root of my EAR project. My project is BatchOverrideEAR and these jars are BatchOverrideEJB.jar and BatchOverrideEJBClient.jar.. If these are the stubs why am i still geting this error?

Exception in thread "P=811667:O=0:CT" java.lang.ClassCastException: org.omg.stub.java.rmi._Remote_Stub incompatible with com.service.batchoverridemanager.ejb.BatchOverrideManagerRemote
	at com.test.BatchOverrideTester.main(BatchOverrideTester.java:65)

// Set system properties.
System.setProperty("com.ibm.CORBA.ConfigURL",
		configuration.getString("InvocationContext.corbaConfigURL"));
System.setProperty("java.security.auth.login.config",
		configuration.getString("InvocationContext.loginConfig"));

// Set initial context.
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY,i "iop://localhost:2809");
env.put(Context.PROVIDER_URL, "com.ibm.websphere.naming.WsnInitialContextFactory");
try {
	ic = new InitialContext(env);
} catch (NamingException namingException) {
	LOGGER.debug("NamingException caught."
			+ namingException.getMessage());
}

// EJB name look up.
try {
	ic.lookup("");
	if (ic != null) {				
		batchOverrideRemote = (BatchOverrideManagerRemote) ic
				.lookup("ejb/session/BatchOverrideManagerRemote");
	}
} catch (NamingException namingException) {
	throw new IllegalStateException("Failed to connect to remote bean"
			+ "Reason: " + namingException);
}

[Deepak Pant]

Is your EJB Client and the EJB running in same JVM or different JVM?

[Sonx Nkuks]

Deepak Pant wrote:Is your EJB Client and the EJB running in same JVM or different JVM?

They both on the same JMV... Am running Websphere locally if you like. By the way, do i need EJBRemote in this case?

[Deepak Pant]

1. If you are using EJB3 then you will need Remote interface file with annotation @Remote.

2. The bean class will need to implement the remote interface. It will have @Stateless annotation.

3. Under same JVM, the JNDI lookup code should be done using the full qualified remote interface class name.

4. Suggest you clear the websphere temp dir and see if anything changes.

[Sonx Nkuks]

Deepak Pant wrote:
1. If you are using EJB3 then you will need Remote interface file with annotation @Remote.

2. The bean class will need to implement the remote interface. It will have @Stateless annotation.

3. Under same JVM, the JNDI lookup code should be done using the full qualified remote interface class name.

4. Suggest you clear the websphere temp dir and see if anything changes.

Hi Deepak, my mistake was still using the server code not the stub created to declare the remote object. Both these are in the same workspace.. Its now working thanks