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.
Joined: Oct 19, 2000
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