• 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

SCBCD: Stubs Question

 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings,

I have a question regarding stubs. If I create a bean, it's component interface and it's remote interface, and use deploytool to build the EAR, it gives me back a client JAR. In the client JAR are the stubs to my home and component interfaces.

When I build a client, I obviously need the component and home interfaces on the classpath. This is convenient considering the client JAR resulting from deploytool contains these. However, I also need the stub classes for the client as well.

My question is: does RI handle stubs differently than most other containers out there (e.g. JBOSS)? Do I need to somehow generate my component and home interface stubs on JBOSS and include them in the classpath of my client, or does JBOSS use that "dynamic proxy" thingy HFEJB refers to?

HFEJB was explicit, stating that the client needs to have access to the stub class files. Does this mean I have to know which server implementation my EJBs are running on so that I can get the "specific" client JAR so that my program will have access to the classes that server uses as it's stub implementation? Furthermore, is RI a "special case" when you absolutely need to create the stubs in the client JAR and include it with your test client?

TIA for any info!

Cheers,
Jason
[ March 08, 2005: Message edited by: Jason Mowat ]
 
Jason Mowat
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just browsing the EJB spec and thought I'd add some pertinent info:


Stubs for invoking on EJBHome and EJBObject references must be provided by the referencing container, for example, by generating stub classes at deployment time for the EJBHome and EJBObject interfaces of the referenced beans that are packaged with the referencing component�s application. Stub classes may or may not follow the standard RMI-IIOP portable stub architecture.

Containers may optionally support run-time downloading of stub and value classes needed by the referencing container. The CORBA 2.3.1 specification and the Java Language to IDL Mapping specify how stub and value type implementations are to be downloaded: using codebase URLs that are either embedded in the EJBObject or EJBHome�s IOR, or sent in the IIOP message service context, or marshalled with the value type. The URLs for downloading may optionally include an HTTPS URL for secure downloading.



And...


The Application Assembler must not package the stubs of the EJBHome and EJBObject interfaces in the ejb-jar file. This includes the stubs for the enterprise beans whose implementations are provided in the ejb-jar file as well as the referenced enterprise beans. Generating the stubs is the responsibility of the Container. The stubs are typically generated by the Container Provider�s deployment tools for each class that extends the EJBHome or EJBObject interfaces, or they may be generated by the Container at runtime.



My question still remains, however :-)

Cheers,
Jason

[ March 08, 2005: Message edited by: Jason Mowat ]
[ March 08, 2005: Message edited by: Jason Mowat ]
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

does RI handle stubs differently than most other containers out there (e.g. JBOSS)?


Yes. The stubs are container specific. You cannot use the RI stubs to invoke methods on the same bean deployed on adifferent container.

Do I need to somehow generate my component and home interface stubs on JBOSS and include them in the classpath of my client, or does JBOSS use that "dynamic proxy" thingy HFEJB refers to?


You do NOT need to generate the stubs for JBOSS. It uses dynamic proxies.

HFEJB was explicit, stating that the client needs to have access to the stub class files. Does this mean I have to know which server implementation my EJBs are running on so that I can get the "specific" client JAR so that my program will have access to the classes that server uses as it's stub implementation?


Yes. Not only your EJB client should include container-specific client-JARs but also the InitialContext properties. Different containers use different values for the Context.INITIAL_CONTEXT_FACTORY, Context.PROVIDER_URL, etc context properties. These must be set specific to the container before you do lookup on the naming service.

Furthermore, is RI a "special case" when you absolutely need to create the stubs in the client JAR and include it with your test client?


Not really. Most containers that work by stubs require this step. Some servers like JBOSS do not need stubs to be generated(dynamic proxy!). IBM Websphere is another vendor that generates stubs.
 
Jason Mowat
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the clarification Keerthi. It was what I needed :-)

Cheers,
Jason
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic