This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm using the HeadFirst booking. I was curious to see what AdviceAppClient.jar (produced by the container) contained and unpacked it and got a number of class files, a META-INF directory with some xml files - presumably deployment descriptors. I also got 2 class files _AdviceHome_Stub.class and AdviceStub.class.
Presumably these are the clientside stubs for connection to the Home and Remote Component on the server. But when I looked later in the book in a sharpen your pen excercise (page 80) solution it talks about the server delivering the stub to the client initially - accross the wire?
One thing is having a client-jar created by the J2EE framework, another thing is having a client which it doesn't know yet about the beans. In the client jar you found the stubs because you've asked for them in the deploytool; but a client can be any plain java class in which you put some business logic. Before actually being able to invoke methods on a remote bean, you need the stub given to you by the container.
Howdy -- the server delivers the stub *object*, but it will fail to deserialize on the client unless the client has the stub *class* file. The stub *object* comes across the wire at runtime, but the class file must be available in advance *unless* the system is able to do some form of dynamic downloading of the stub/proxy class.
Usually the easiest way to get the class file to the client is by letting the server generate a client JAR file, and then sending it to the client in advance. The client must have the home and component interfaces as well, and those are often usually in the client JAR.
Of course, you might give the client the interfaces in advance, and then later deliver the stub classes, but regardless of how you get things to the client, the stub class file must be available somehow when the stub *object* comes back to the client as a result of a JNDI lookup or a call to a home object's create() or find() method (or a business method that returns a stub object).
I'm figuring that this has been my problem for the past few days. I've been trying to do the lookup, and I can't seem to get it to connect. The only persistent exception at this point is the classNotFound exception. I have to assume I don't have the stubs.
I'm using JBOSS 3.2.3, and I haven't seen any container generated .jar file with stubs. A quick search of my file system doesn't show anything approximating my Demo.jar file either.
How do I get the stub classes? How do I get JBOSS to generate them, or does it do so already?
Just put your jar or ear in the client's classpath, this should solve your problem.
Marcelo Sousa Ancelmo - Brazil
Joined: Sep 06, 2004
That's exactly what the problem was.
The class loader wants the class file to have the same directory structure as the package name for the class. You can't just have it in the local directory. The Jar file or a -classpath statement with that directory structure solves the problem.
It would be nice if that were spelled out in the texts.
Also, JBoss appends "Home" at the end of the JNDI name, even if you already have "Home" at the end. Hence, you may receive a <class>HomeHome file in response.