How can I override an EJB 3 session bean method with a generic argument - if possible at all? [closed]

Question!

Suppose you have the following EJB 3 interfaces/classes:

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
}

And then another bean that accesses the FooRepository bean :

//...
@EJB
private FooRepository fooRepository;

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

However, the overriding method is never executed when the delete method of the FooRepository bean is called. Instead, only the implementation of the delete method that is defined in AbstractRepository is executed.

What am I doing wrong or is it simply a limitation of Java/EJB 3 that generics and inheritance don't play well together yet ?



Answers

I tried it with a pojo and it seems to work. I had to modify your code a bit. I think your interfaces were a bit off, but I'm not sure.

I assumed "Foo" was a concrete type, but if not I can do some more testing for you.

I just wrote a main method to test this. I hope this helps!

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);
       }
}
By : ScArcher2


Can you write a unit test against your FooRepository class just using it as a POJO. If that works as expected then I'm not familiar with any reason why it would function differently inside a container.

I suspect there is something else going on and it will probably be easier to debug if you test it as a POJO.

By : Mike Deck


I've had to interview people for a few C# positions and this is my general advice for VB.Net developers interviewing for a C# position:

  • Make sure you are clear that you have been working VB.Net. This seems obvious but is something that apparently isn't (in my experience).
  • Try to give a code sample, if possible. I've seen some horrible VB.Net (and C#) written by VB programmers who didn't seem to learn much in the transition to .Net.
  • Be able to write in C# during the interview, if asked. I know there aren't many real differences between the two, but I don't want to pay you to learn the new syntax.

For your specific question: I've asked that type of question before and what I wanted to hear about was how the underlying system and framework were the same. If possible, talk about garbage collection, IDisposable, finalizers, the dangers of unsafe code blocks, stack vs heap, etc. All the kind of stuff to show that you really understand the intricacies of the .Net framework. Right or wrong, the heritage of VB brings with it an expectation of a lack of understand of lower level programming and windows in general (which, ironically enough, a c++ developer would have of a c# developer... and so on).

Lastly, how you frame your experience can make a world of difference. If you position yourself as a .Net developer, rather than VB.Net or C#, the stupid, pseudo-religious, banter may not enter the conversation. This of course requires that you actually know both VB.Net and C# at the time of the interview, but that's a good policy regardless.

The truth of the matter is that if you find that the person interviewing you writes you off simply because you've previously been developing in VB.Net, it's likely not going to be a place you want to work at anyway.

By : akmad


This video can help you solving your question :)
By: admin