Question

Not terribly experienced using EJB, and I ran into the following problem with which I hope one of you guys can help out.

Suppose the following situation: a set of @Local beans have been defined to provide access to a database. These beans are very simple, and are deployed on application server A (Weblogic 10.3.3). We want to provide access to these local beans via remote, and since we already have a “services” module set-up for providing external access to our services, our idea was to create a new @Remote service that uses the local beans described above (injected via @EJB). These service beans are also deployed on application server A. For example:

@Local
public interface DatabaseBeanLocal { doStuff(); }

@Stateless(name = "ejb/DatabaseBean", mappedName = "DatabaseBean")
public class DatabaseBean implements DatabaseBeanLocal { doStuff() { ... } ; }

@Remote
public interface ServiceBean { doSomeOtherStuff(); }

@Stateless
public class ServiceBeanImpl implements ServiceBean
{
    @EJB(name = "ejb/DatabaseBean", mappedName = "DatabaseBean")
    private DatabaseBeanLocal myDatabaseBean;

    ... methods etc. ...

}

The client that will actually use these remote beans is actually run on a different application server; application server B (also Weblogic 10.3.3). When we look-up the ServiceBean bean from our client, that works fine. When we call a method on it that needs access to DatabaseBean however, the call fails. The Weblogic server says it cannot find a bean for the DatabaseBean interface.

My questions: is this set-up even possible? In other words: will Weblogic (or another container) inject the local bean into the remote bean so that the client gets an instance of the remote bean that is capable of calling actions on the local bean (I assume not, but I’m asking anyway to be sure)?

If not, the I guess we’ll have no other choice than to skip the service layer and provide direct access to the DatabaseBean example above via @Remote.

Update 1

After doing some tests, simply defining DatabaseBean above as @Remote rather than @Local “fixes” this issue. Ofcourse, this is not really a fix since this will call the DatabaseBean remotely, which is ridiculous because it’s in the same module as the service. I’m starting to suspect that wrapping a local EJB with a remote EJB is simply not possible.

Update 2

What we’ve found so far:

• We’ve not been able to manually inject the local EJB so far, because we cannot actually find it at runtime.
• Weblogic apparently does not include local EJBs in the JNDI tree.
• Calling the ServiceBean from outside the AS on which it is deployed still does not work, because the dependency on the local EJB is never resolved, or resolved client-side which means it’s not found.

Answer 1

Managed to get this issue resolved. the following configuration works for Weblogic 10.3.3 and allows for a remote EJB to use a local EJB, where the remote EJB can be called from anywhere.

Ultimately — after a lot of testing — the trick was apparently specifying a beanName value for the @EJB annotation used to mark the local bean as a dependency of the remote bean. Doh!

Deployment

• @Local EJB is deployed on AS-A in EAR-1 (in its own module/JAR)
• @Remote EJB is deployed on AS-A in EAR-1 (in its own module/JAR)
• Client code that calls the remote service is deployed on AS-B in its own EAR archive

Annotations

The local EJB is a very simple and straightforward EJB bean, with the following interface and implementation:

@Local
public interface LocalBeanLocal {
    // Implementation omitted
}

@Stateless(name = "LocalBean")
public class LocalBean implements LocalBeanLocal {
    // Implementation omitted
}

The remote EJB is again a relatively simple EJB bean, except that it has a dependency on LocalBean. This dependency is expressed through the @EJB annotation; but it would seem that the beanName attribute is required for Weblogic to resolve this dependency correctly. Without the beanName attribute, calling the remote EJB would not work for us (in the sense that there would always be some kind of error when the local bean was involved)!

@Remote
public interface RemoteBeanRemote {
    // Implementation omitted
}

@Stateless(name = "RemoteBean")
public class RemoteBean implements RemoteBeanRemote {

    @EJB(beanName = "LocalBean")
    private LocalBeanLocal localBean;

    // Implementation omitted
}

What is apparently important here is that the beanName attribute in the remote service dependency declaration (@EJB(beanName = "LocalBean")) should have the same value as the bean name defined in the local bean implementation (@Stateless(name = "LocalBean")).

Lookup

Getting a reference to your remote EJB is done the traditional way, there doesn’t seem to be a specific requirement. In our case, we look-up the remote service via JNDI.