Wie und wer sollte PersistenceContext injizieren, wenn Tests durch Jersey / Grizzly läuft?

Question

ich diese Klasse haben (Mischungs von JAX-RS / Jersey und JPA / Hibernate):

public class Factory {
  @PersistenceContext(unitName = "abc")
  EntityManager em;
  @Path("/{id}")
  @GET
  public String read(@PathParam("id") int i) {
    return em.find(Employee.class, i).getName();
  }
}

Dies ist das Gerät zu testen:

public class FactoryTest extends JerseyTest {
  public FactoryTest() throws Exception {
    super("com.XXX");
  }
  @Test
  public void testReadingWorks() {
    String name = resource().path("/1").get(String.class);
    assert(name.length() > 0);
  }
}

Alles ist in Ordnung hier außer einem dieses: em ist NULL innen read(). Sieht aus wie Grizzly (Ich verwende diesen Server zusammen mit Jersey Test Framework) nicht injizierenden PersistenceContext. Was mache ich falsch hier?

Answer 1

  

Alles ist in Ordnung hier außer einem dieses: em ist NULL innerhalb read (). Sieht aus wie Grizzly (Ich verwende diesen Server zusammen mit Jersey Test Framework) ist PersistenceContext nicht injiziert werden. Was mache ich falsch hier?

1. Ich bin nicht sicher, Grizzly Angebote Injektion.
2. Ich bin mir nicht sicher Injektion ohnehin in "jeder" Jersey Ressource unterstützt (Paul Sandoz scheint es in dieses Thema aber ich kann nicht eindeutige Beweise für diese Behauptung) finden.

So meines Wissens wäre die einfachste Lösung sein, die EntityManager in eine EJB zu injizieren 3.1 Stateless Session Bean (SLSB) direkt als REST-Ressourcen freigelegt werden kann (indem sie sie mit JAX- Anmerkungen versehen RS Anmerkungen).

Eine andere Möglichkeit wäre die JAX-RS Ressource eine Managed Bean machen und CDI verwenden zur Injektion. Das ist der Ansatz von der TOTD # 124: Mit CDI + JPA mit JAX-RS und JAX-WS .

In beiden Fällen denke ich, werden Sie auf den integrierten Behälter Glassfish als Container für Ihre Jersey Tests verwenden müssen.

Ressourcen

• Jersey Test Framework macht es einfach!
• Jersey Test Framework wieder besucht!
• RESTful-Rechner mit JavaScript und ... EJB 3.1
• TOTD # 124: Mit CDI + JPA mit JAX-RS und JAX-WS

Answer 2

fand ich eine Lösung für com.sun.jersey / Jersey-grizzly2 Version 1.x . Ich implementiert eine benutzerdefinierte InjectableProvider . Der folgende Code wird genommen von einem Oracle Artikeln :

import javax.ejb.EJB;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.ws.rs.ext.Provider;

import com.sun.jersey.core.spi.component.ComponentContext;
import com.sun.jersey.core.spi.component.ComponentScope;
import com.sun.jersey.spi.inject.Injectable;
import com.sun.jersey.spi.inject.InjectableProvider;

@Provider
public class EJBProvider implements InjectableProvider<EJB, Type> {

    public Scope getScope() {
        return Scope.Singleton;
    }

    public Injectable getInjectable(ComponentContext cc, EJB ejb, Type t) {
        if (!(t instanceof Class)) return null;

        try {
            Class c = (Class)t;        
            Context ic = new InitialContext();

            final Object o = ic.lookup(c.getName());

            return new Injectable<Object>() {
                public Object getValue(HttpContext c) {
                    return o;
                }                    
            };            
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
}

Ich hatte etwas daran anzupassen meine Umgebung zu passen. Beachten Sie auch, dass sich der Anbieter im selben Paket wie Ihre Serviceklasse sein muss, sonst wird es nicht abgeholt werden (es nicht sagen, dass im Artikel).