|
Didn't you read the message of Erez? He fully
described what you have to put on the client. Or did he left out the
homes?
For sure, you need the homes. You are using it in
your source code e. g. to do "home.findByPrimaryKey", so your client has to know
this class.
Here is a list of what you need AT LEAST. Remark: I
am just about to write a tool that will create a client.jar, consisting of all
what is needed to run the client. Maybe you can wait two weeks, then you'll get
it (I'll post it on the mailing list since it is of global interest). But since
I did not receive all information I need from JOnAS team (by the way, can you
please send me a list of all out of the *_jonas.jar what I have to include
in the client.jar?) I am not ready with it - and I'm on holidays at the
moment... :-)
1) You need some classes that ship with Java 2
Enterprise Edition. For simplicity, include *_jonas.jar into your classpath,
since this jar includes that classes.
2) You need some classes that are specific to
JOnAS. For simplicity, include *_jonas.jar into your classpath, since I do not
have a list of them (I hope I'll get this list, because it's quite hard to get
it by trial and error ;-) ).
3) You need the home and remote interfaces of
your class, since your client uses them directly.
4) You need all the *_stub (client side proxy)
classes that GenIC generates when you deploy your beans to the server, since the
client uses them to talk to the *_skel (server side proxy) classes on the
server.
5) You need all that classes and interfaces that
are used as parameters or results in remote calls, e. g. if you have a new class
MyClass, that is used as a result of a business method, the client needs to have
this class since you would access this class. That class is not needed on the
client if the client doesn't access the result.
HTH
Markus
----- Original Message -----
Sent: Thursday, August 09, 2001 4:41
AM
Subject: Re: Still have problem with not
using config_env
Arrgh! I'm still getting a problem, but now a
diff. error. If I put the Jonas..._stub.class files in the class path of the
client, I get the error: NoClassDefFoundError:
com/titan/cabin/CabinHome
Do I also need the CabinHome.class on the client
side? So on the Client I need a copy of:
1. The Stubs (here I have two: Home stub, Remote
stub)
2. The Home and Remote classes
themselves
Is that right? That seems kinda wrong to me. It
seems that if you're gonna have the stubs over there, what's the point of the
regular classes? (And vice-versa)
Do I need all of these on the
client?
Thanks again for all your help!
----- Original Message -----
Sent: Wednesday, August 08, 2001 6:00
AM
Subject: Re: Still have problem with
not using config_env
That's just what I meant with "client jar". You
have to deploy parts of your application - see erez' mail below - with your
client software so that the client can talk to the server. Yes, RMI can do
this automatically, but I am not an RMI specialist, too. Maybe there is some
RMI specialist in the JOnAS team that can give you a hint how to do this
automatically. But since J2EE comes with JavaWebStart in the near future,
the question will be if you will need this. The other question is, how often
you think that you want to change your server application? And even if you
change it often, why not putting that client jar onto a single common server
file share, that will be accessed by the client? Then you do not have the
replicate it. Another way is that e. g. WindowsNT has internal Server to
Client broadcast file replication mechanism, there you have to put it into
one directory on the server once, and NT deploys the file automatically. So
this should not a big problem, as I think.
Markus
----- Original Message -----
Sent: Wednesday, August 08, 2001 8:24
AM
Subject: Re: Still have problem with
not using config_env
Wow, are you serious? I actually need the
stubs on my client's computer? I thought RMI could send the stubs across
the network? (I am new to RMI) I may be completely missing this though.
So, then are you saying that everytime I deploy a bean, I have to give the
stubs to a client? (Whether that be JSP, another EJB server on another
comp. or some other company's app)
Thanks for the reply. If there is no way to
send the stub across RMI, then this solves alot of questions but not
problems. (What about dynamic class loading with RMI? Is there a way for
the client to try the call, and then if it doesn't have the stub, to ask
the RMI Registry to send the stub?)
|
