This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have David & Dawn Griffiths on-line!
See this thread for details.
Win a copy of Head First Android this week in the Android 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

classpath woes

Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have an EJB that needs to access another EJB. I use a secondary class that performs all lookups for all clients and returns the home interface for that bean (ala the service locator design pattern). The service locator class does not reside in the .ear file as it is useful to any client, not just my particular EJB.
I placed the classpath to the service locator in the JVM settings tab on my appserver (using websphere 4.0), so the calling bean could find it. The calling bean has no problem finding the service locator. However, the service locator needs to know the classname of the home interface of the new bean.
Herein lies the problem. I get a noclassdeffound error when my service locator tries to cast (narrow) the new EJB to it's home class definition. If I skip using the service locator and just have the calling bean implement the lookup code, it works great.
So the question... why can't my service locator find the definition of the bean? Both beans are hosted in the same app server and container? Where would the class path need to be set for the service locator to find the new bean? Remember, the service locator code exists in a separate jar file not deployed with the 2 beans, only referenced by a classpath setting.
I hope this makes sense... it seems rather complicated to explain, but the code is rather simple.
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure about how WebSphere does it, but
I ran into a similar problem using WebLogic.
The application server creates a seperate classloader for each application(ear file). In the classloader hierarchy this application classloader is below the system one so any class loaded by the application classloader has access to the locator. However locator doesn't have access to any classes that are loaded by the application.
You could put the ejb interfaces on the system classpath, but I would suggest packaging the locator class with the ejb in the ear file. This would mean that you would end up with one locator per ear as opposed to one locator per application server.
Hope this helps
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic