aspose file tools*
The moose likes Websphere and the fly likes Class cast exception when grabbing remote EJB 3 interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Websphere
Bookmark "Class cast exception when grabbing remote EJB 3 interface" Watch "Class cast exception when grabbing remote EJB 3 interface" New topic
Author

Class cast exception when grabbing remote EJB 3 interface

Stu Quinn
Ranch Hand

Joined: Feb 27, 2009
Posts: 35
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.




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



Here is the remote interface



Any help for this WebSphere newbie would be appreciated.

Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
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
Ranch Hand

Joined: Feb 27, 2009
Posts: 35
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
Ranch Hand

Joined: Aug 20, 2010
Posts: 47
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?



Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
Is your EJB Client and the EJB running in same JVM or different JVM?
Sonx Nkuks
Ranch Hand

Joined: Aug 20, 2010
Posts: 47
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
Ranch Hand

Joined: Feb 13, 2004
Posts: 443

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
Ranch Hand

Joined: Aug 20, 2010
Posts: 47
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Class cast exception when grabbing remote EJB 3 interface