Win a copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java this week in the Agile and Other Processes forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
Sheriffs:
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
Bartenders:
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

Local EJB calls between separate ear/jar possible ?

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I have several ejb modules deployed in WAS 6.1 ejb container.
And my simple question is:

"Is it possible to do local ejb calls between 2 ejbs from different ear/jar files deployed on the same WAS server running in the same JVM ?"

If so, how to achieve this? I can't find any way to configure it in RAD 7...
I can create ejb local references for ejbs from the same ear.

Using the wizard in RAD, when I select an EJB from another ear to create an ejb reference, it is created as a remote ejb reference. How to specify I still want to use local interface ?

Local EJB calls between separate ear/jar ? myth or reality ?
 
Chris Manson
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found a decent answer here: http://fixunix.com/websphere/344774-local-interfaces-same-jvm-but-different-ear-issue.html#post894504

Basically it says local calls between different ears are not recommended, instead use remote call and WAS will optimize them.

Here is the full text from Randy:

"The EJB spec itself is fairly silent on whether EJB local (pass-by-reference) interfaces may be used across Java EE applications (i.e. different EAR files). It says that the caller and callee must be in the same JVM, but is silent on the other aspects that factor into whether it will work or not. One aspect that Paul mentioned is that there's no spec-defined way to look up a local interface within the global JNDI namespace; this means that the only way to get ahold of a local interface is through an ejb-local-ref element in the calling application, along with using an ejb-link element to point the local-ref at the target local interface. The syntax for ejb-link only allows for pointing at EJBs within the same EAR file as the caller, not across EAR files. WAS allows you to set an external EJB binding in the calling EAR using a global JNDI name (seemingly for the remote interface), but under the covers WAS modifies the data from the binding to get the local interface inste
ad. This "modification" is hidden from the user and unfortunately has caused a fair amount of customer confusion when debugging.

After getting past the naming issue, the next issue that commonly comes up is the ClassCastException. It's not commonly understood that when two classloaders load the exact same Java .class file, objects created from the two classloaders are still NOT type-assignable to each other even though they implement the same class name (and even if they're based on the same .class file). In this case the generated test.ejb.EJBLocalStatelessProcessHome_6f83b3f2 class DOES implement test.ejb.ProcessorLocalHome, but it implements the test.ejb.ProcessorLocalHome that was loaded by the other application's classloader. Thus, when the calling app tries to assign the instance to a variable of test.ejb.ProcessorLocalHome, you get a ClassCastException.

One way to prevent this is to use a remote interface. As Paul mentioned, there is optimization that happens when the caller and callee are in the same JVM, so it's not as expensive as if they're in separate JVMs. The ORB has classloader machinery that ensures the classes for the caller and callee are loaded using classloaders compatible with each side of the call.

Option 2, including the ejb jar within the new ear, won't solve the problem. Even though the classes will be available in both classloaders, the object passed by-reference from callee back to caller will still be instanciated using the other application's classloader and will not be type-assignable. Same with Option 3.

The 2nd way to make it work is to place the classes used by caller and callee in a "WAS shared library" and configure both applications to use that shared library. The subject of shared libraries and how to configure them is described in the WAS InfoCenter documentation...search on "shared library."

The 3rd way to make it work, which is the least desirable of the three, is to change the WAS server classloader policy to "one classloader per server." The default, as I mentioned at the top, is "one classloader per application (EAR file)." Changing to one classloader per server ensures that everything gets loaded by the same classloader and is thus type-compatible, but deprives your applications of the isolation/security benefits that come from having each app in its own classloader."

[ April 14, 2008: Message edited by: Lucas Opara ]
[ April 14, 2008: Message edited by: Lucas Opara ]
 
author & internet detective
Posts: 39879
798
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lucas,
I'm glad you found an answer so quickly! Thanks for posting it here so others reading this question will benefit.
 
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great reply, thanks a lot for sharing it, it helps me too with a similar issue using jboss 4.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

My situation is as follows:

I have the Stateless mbean ServiceA which resides in the applicationA.ear

From the mbean ServiceB which resides in a seperate ear, say applicationB.ear, I am trying to access the above mbean (ServiceA) using the remote interface ServiceARemote (as previous post suggest) with this code:



The problem is that in deployment, I get a NoClassDefFound error for the ServiceARemote class.

What I am doing wrong?

Thanks for your time.
 
Emanuele Ghe
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, try enabling "EAR ISOLATION".
 
Blueberry pie is best when it is firm and you can hold in your hand. Smell it. And smell this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!