Connecting to EJ bean in Sun App Server 8

Question

I am working my way through the j2eetutorial14, and have successfully built the Converter app. However, I need to run the stand-alone client, connecting to the bean, in a server-independent way. So, as part of my exercise, I copied the client code in Eclipse, and made the following changes to the code:
from the original example:
Context initial = new InitialContext();
Context myEnv = (Context) initial.lookup("java:comp/env");
Object objref = myEnv.lookup("ejb/SimpleConverter");
ConverterHome home = (ConverterHome) PortableRemoteObject.narrow(objref, ConverterHome.class);to this:
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
properties.put(Context.PROVIDER_URL, "corbaloc:iiop:localhost:3700");
Context initial = new InitialContext(properties);
Object objref = initial.lookup("ConverterBean");
ConverterHome home = (ConverterHome) PortableRemoteObject.narrow(objref, ConverterHome.class);Now I am getting this exception in the narrow() method:
java.lang.ClassCastException
     at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
     at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
     at ConverterClient.main(ConverterClient.java:27)When I run the client from the script:
appclient -client ConverterAppClient.jarit works as expected. I am obviously missing something in my Eclipse runtime environment, but the manual was of no help so far. (But j2ee.jar library from C:\Sun\AppServer\lib is in the classpath.)
If anyone successfully connected to the Sun App Server 8 EJB from a stand-alone client and can share their wisdom, I will appreciate it.
On a more general note, what are the pitfalls to watch for when writing, packaging and distributing an EJB app (bean and stand-alone client) in a server-independent way? Any pointers?
Thanks for any help.
Alex.

Answer 1

Did you have the EJB client JAR in your classpath? Yes, and I spent all day searching the Forums for the clues. I found the answer, and was going to post it here. The client JAR was missing the RMI stubs. The process of generating the stubs is quite cumbersome - at least, the one that I discovered. It involves deploying the EAR first, then going to the Admin Console and manually setting a number of options, then collecting the sought-for JAR from the Sun App Server's applications directory. The generated file will contain the stubs, and also the Home and Remote interface files, as well as the bean class (something that the client will never need). So, I may have to write a script to strip off the needless baggage from the client JAR.
I have been working with JBoss and its plugin for Eclipse for some time now, and grew spoiled by the ease of deployment there, including the fact that the JBoss/Eclipse combo took care of the RMI stubs and many other things that Sun's server exposes to the developer.
Anyway, here is my cookbook that I made as I was working through the process of generating the stubs:
====================================
Creating a stand-alone Client:
The stand-alone client need RMI stubs to communicate with the EJ bean on the server side. To create the stubs:
1. Start the Admin Console web page (Start > All Programs > Sun Microsystems > Application Server PE > Admin Console). In the left-hand frame select: Applications > Enterprise Applications.
2 In the right-hand frame, press Deploy button.
3 Select file to upoad (navigate to the application EAR). Press Next.
4. Set Application Name field (it should be preset), and check the Generate: RMIStubs checkbox. If this procedure was done before, check the Redeploy box to force generation of the file.
5. Press OK button.
The JAR file with stubs will be placed into C:\Sun\AppServer\domains\domain1\applications\j2ee-apps directory.
The stubs have format _name_Stub.class and _nameHome_Stub.class (e.g. for Converter app the files are ConverterStub.class and ConverterHomeStub.class). These files must be extracted and placed into the client's classpath. Alternatively, the entire JAR file can be made part of the client's classpath.
====================================
Thank you for the quick reply.
Alex.