EJB Client

Hi,
I am new to EJB, have deployed the EJBs on weblogiserver5.1(sessionbean,entitybean). And there are few standalone java classes incoporated in the ejb jar file. When i am trying to run the test client it is asking all the ejb classes(home&remote interface) including the java class. I am confused why i have to bring the EJB jar which is stored in the server to the classpath of the client? I may be wrong in doing this. Please advice me how to run the client(standalone java jndi lookup) without bringing the Actual EJB jar code into class path.
Thanks in Advance, BJ

Hi, you should package the home and remote interfaces within your client to avoid such thing.
regards.

Thanks for the reply, but i think it is redundant by storing the EJBs on the server side and client side. Also i think one need to bring the weblogic jars also into the client classpath.
1).Is there any way that without bringing home&remote(weblogic stuff too) interfaces into classpath,one can run the client to access EJBs?
Thanks in advance,

Originally posted by pushpa latha:
Thanks for the reply, but i think it is redundant by storing the EJBs on the server side and client side. Also i think one need to bring the weblogic jars also into the client classpath.
1).Is there any way that without bringing home&remote(weblogic stuff too) interfaces into classpath,one can run the client to access EJBs?
Thanks in advance,

No. Think about this. The home and remote interfaces are used in your client code. A client generally looks like:
// get initial context
Object anObj = initContext.lookup("someHome");
SomeHome aHome = (SomeHome) PortableRemoteObject.narrow(anObj, SomeHome.class);
SomeEJB anEJB = aHome.create();
Note that both the Home interface (SomeHome) and the remote interface (SomeEJB) are used in the client code. You MUST have these classes (and the client-side stubs) on the classpath to make the code run.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
[This message has been edited by Kyle Brown (edited November 08, 2001).]

No. Think about this. The home and remote interfaces are used in your client code. A client generally looks like:
// get initial context
Object anObj = initContext.lookup("someHome");
SomeHome aHome = (SomeHome) PortableRemoteObject.narrow(anObj, SomeHome.class);
SomeEJB anEJB = aHome.create();
Note that both the Home interface (SomeHome) and the remote interface (SomeEJB) are used in the client code. You MUST have these classes (and the client-side stubs) on the classpath to make the code run.
Kyle
Hi,
I understand that, how about wrapping a wrapper class for client and generate stubs. And make a straight RMI call with these stubs? By this we can avoid giving the Home&Remote Code to clients.
I am now making a RMI call to access the EJBs. Any ideas on this architecture?

But then you would have to deploy the RMI stubs to the clients. So what do you gain? Why are you so concerned about deploying the EJB stubs...? Is there some particular downside you are trying to avoid?
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

But then you would have to deploy the RMI stubs to the clients. So what do you gain? Why are you so concerned about deploying the EJB stubs...? Is there some particular downside you are trying to avoid?
Kyle

The disadvantage i am seeing by using home&remote interfaces along with client is that the client has to give the classpath of the weblogic packages. Where as for RMI call only standard jdk is enough. Kyle, by this the client won't have to worry about bringing the weblogic stuff into classpath.
Thanks,

I think you're missing part of the point of client-side calls to EJB's. Standard RMI isn't enough. The JVM has to be able to pass security information, transaction information and other bits of information along with the call that aren't in the standard RMI headers. That's why vendors developed special RMI based protocols (like Weblogics T3) and why the spec mandates RMI-IIOP.
I suggest that you download and read Greg Nyberg's companion book to Richard Monson-Haefel's EJB book. (available at http://www.oreilly.com/catalog/entjbeans3/workbooks/index.html) He explains a lot of the Weblogics specifics there...
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

Thanks for correcting me in the concept of EJB client side code. I have gone though the book which you suggested(EJB 2nd Edition by oreilly) but doesn't give useful information on how to access the EJB which are in Weblogic by general java clients.
Would you please give me some suggestions how to call EJBs without Weblogic stuff into the classpath(weblogic.rmi & weblogic.jndi). Are there any other Vendors(escpecially Javasoft) will provide RMI&JNDI which can be communicated to weblogic server?
Thanks in Advance,
BJ

I'll try this more clearly. YOU CAN'T. End of Story. There is NO WAY to call an EJB with RMI without using the generated EJB Stubs. THERE ARE NO OTHER WAYS TO DO THIS.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

Hello Kyle,
I think you misunderstood my question. What i mean was Can we communicate to EJB which is stored in Weblogic server with RMI and client side stubs without the weblogic.rmi classes?
RMIClient.java + Stubs(remoteinterface)+ weblogic stuff(weblogic.rmi) to communicate with EJB+remoteinterfaceImpl+EJB stubs and skeletons+remoteinterface stubs and skeletons classes stored in weblogic server.
I am communicating succesfully by the above scenario, my question was whether is there any substitue(alternative packages by javasoft or something?) for weblogic stuff(welogic.rmi)which is used in the client side classpath.
I am sorry if i annoyed you with my questions,
Sincerely,