This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Five Lines of Code and have Christian Clausen on-line!
See this thread for details.
Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring 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 ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

classpath woes

Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • 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
  • 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
Live a little! The night is young! And we have umbrellas in our drinks! This umbrella has a tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic