javajndiejb-3.0jboss-4.2.xdeployment-descriptor

Lookup for EJB subclass by superclass EJB name


I have a parent and child EJB

@Stateless
@Local(MyCoreLocal.class)
@Remote(MyCore.class)
public class MyCoreEjb implements MyCoreLocal, MyCore {
...
}
@Stateless
@Local(MyCustomizationLocal.class)
@Remote(MyCustomization.class)
public class MyCustomizationEjb extends MyCoreEjb implements MyCustomizationLocal, MyCustomization{
...
}

for architecural reasons at my company, I can't change MyCore project. But both it's all packed together in the same jar and deployed to JBOSS 4.2.3.

The problem is, I have to use MyCustomizationEjb whenever someone calls for MyCoreEjb. How can I override the JNDI entry for MyCoreEjb to point to MyCustomizationEjb in order to redirect all calls for MyCoreEjb transparently to MyCustomizationEjb?

ps: I have full control over ejb-jar.xml of the project, but can't change annotations.


Solution

  • I figured out a way how i could overpass the problem. In reality i didn't need to redirect all call for MyCustomizationEjb. I needed it just for a particular method (at this time).

    So my solution was to make a Method Interceptor on the specific method I wanted and just "redirect" the execution to MyCustomizationEjb like this:

    public class SpecificMethodInterceptor{
    
    @EJB
    MyCustomization myCustomization;
    
    @AroundInvoke
    public Object intercept(InvocationContext ctx) throws Exception {
    
        Object result = myCustomization.specificMethod((Param1Type)ctx.getParameters()[0], (Param2Type) ctx.getParameters()[1]);
        return result;
    }
    

    This way I could now call the extended specificMethod transparently.

    I know this is not the most maintainable or scalable solution (since I'll need one interceptor for each method I want to override), but giving this particular project limitations I believe it was the best choice.

    Note: There is no problem for not continue the execution (with ctx.proceed()) because this Interceptor is the last one called before the execution reaches the EJB. The only way it could go wrong is if someone make a method interceptor at the EJB, which would be skipped in the execution. But it's not a problem in this particular project.