• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

stubs on the client

 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

Can anybody explain how the stub is delivered?
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).

cheers,
Kathy
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 498
Eclipse IDE Firefox Browser Fedora
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just put your jar or ear in the client's classpath, this should solve your problem.

Regards,
 
Trajan Walker
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic