Yes this is all possible, it is the way EJB
is intended to work.
Your bean does not implement the interfaces directly,
instead it implements the javax.ejb interfaces.
The implementation is created by the EJB container
which delegates to your bean as required.
JBoss will optimize any use of a remote interface
to local behaviour in the same JVM, you still need
local interfaces for CMR.
Ok, good to hear I am atleast in the right ballpark.
One of the goals I have is to be able to compile my different apps without having the other apps available.
For example, I have an app called someapp.jar, and it contains an EJB called SomeEJB. It uses an entity bean called AnotherEJB, that is contained in a different app called anotherapp.jar. I would like to be able to compile and package someapp.jar without having anotherapp.jar on my machine.
The solution I am thinking of would be to make a set of interfaces and put them in a package called common.jar. Common.jar would have an interface that describes all the shared functionality of AnotherEJB, and this interface is called Another. The remote interface of AnotherEJB would extend Another.
Then I could compile someapp having only common.jar in the classpath, and not having anotherapp.jar in the classpath. When someapp needs to use the shared bean it would get the remote interface through JNDI, but cast it as an object of the Another interface. Since the actual remote interface of AnotherEJB extends Another, I think that would work. And then somapp only needs common.jar to compile, but when it's actually running it ends up using AnotherEJB, which is contained in anotherapp.jar.
The reason I want to do this is so that if someone does not like my implementation of the Another interface (namely AnotherEJB), they can create a seperate implementation called YetAnotherEJB, whose remote interface also extends Another. Then using JBoss hot deploying, they could replace AnotherEJB with YetAnotherEJB, and SomeEJB would still work because it's only using the Another interface, and both remote interfaces extend Another.
Is there anything wrong with this? Would you experienced JBoss developers consider this an elegant solution, or is there a better way?
You will be ok provided you have
If you do this:
public interface YetAnother extends Another
The client would require the interfaces
YetAnotherHome.class and YetAnother.class
It is possible to configure the client to download
the classes from the server using the RMI codebase.
Ok, thanks for the example. It made me realize that I was misunderstanding something. I think I got it now.