¿Cómo puedo anular un método de bean de sesión EJB 3 con un argumento genérico, si es posible?[cerrado]

Question

Supongamos que tiene las siguientes interfaces/clases EJB 3:

public interface Repository<E>
{
   public void delete(E entity);
}

public abstract class AbstractRepository<E>  implements Repository<E>
{
   public void delete(E entity){
      //...
   }
}

public interface FooRepository<Foo>
{
   //other methods
}

@Local(FooRepository.class)
@Stateless
public class FooRepositoryImpl extends
    AbstractRepository<Foo> implements FooRepository
{
   @Override
   public void delete(Foo entity){
      //do something before deleting the entity
      super.delete(entity);
   }
   //other methods
}

Y luego otro bean que accede al FooRepository frijol :

//...
@EJB
private FooRepository fooRepository;

public void someMethod(Foo foo)
{
    fooRepository.delete(foo);
}
//...

Sin embargo, el método de anulación nunca se ejecuta cuando el método de eliminación del FooRepository se llama frijol.En cambio, sólo la implementación del método de eliminación que se define en AbstractRepository es ejecutado.

¿Qué estoy haciendo mal o es simplemente una limitación de Java/EJB 3 que los genéricos y la herencia aún no combinan bien?

Answer 1

Lo probé con un pojo y parece funcionar.Tuve que modificar un poco tu código.Creo que tus interfaces estaban un poco apagadas, pero no estoy seguro.

Supuse que "Foo" era un tipo concreto, pero si no, puedo hacer más pruebas por ti.

Acabo de escribir un método principal para probar esto.¡Espero que esto ayude!

public static void main(String[] args){
        FooRepository fooRepository = new FooRepositoryImpl();
        fooRepository.delete(new Foo("Bar"));
}

public class Foo
{
    private String value;

    public Foo(String inValue){
        super();
        value = inValue;
    }
    public String toString(){
        return value;
    }
}

public interface Repository<E>
{
    public void delete(E entity);
}

public interface FooRepository extends Repository<Foo>
{
    //other methods
}

public class AbstractRespository<E> implements Repository<E>
{
    public void delete(E entity){
        System.out.println("Delete-" + entity.toString());
    }
}

public class FooRepositoryImpl extends AbstractRespository<Foo> implements FooRepository
{
     @Override
       public void delete(Foo entity){
          //do something before deleting the entity
            System.out.println("something before");
          super.delete(entity);
       }
}

Answer 2

¿Puedes escribir una prueba unitaria contra tu clase FooRepository simplemente usándola como POJO?Si eso funciona como se esperaba, entonces no estoy familiarizado con ninguna razón por la cual funcionaría de manera diferente dentro de un contenedor.

Sospecho que está sucediendo algo más y probablemente será más fácil depurarlo si lo prueba como POJO.