Cette question est une suite à partir d'une question précédente Spécifier le contexte de l'application personnalisé .
Nous migrons certains de nos services de données de Jersey 1.x à l'aide de Jersey-Spring vers Jersey 2.x à l'aide de Jersey-Spring3.
Nous avons quelques cours de test qui héritent de Jerseytest. Certaines de ces classes utilisent des fichiers ApplicationContext.xml personnalisé qui ne sont pas spécifiés dans le fichier web.xml.
à des fins de moqueur d'objet Nous nous motions de certains composants dans nos ressources de maillot.
Dans Jersey 1.x, nous pourrions faire une faimage d'objets dans le fichier de contexte d'application par et récupérer ces instances moquées comme suit J'ai peigné via le API DOCS , utilisateur Guides et une partie des Sources mais n'a pas pu trouver de réponse. merci. EDIT: Nous utiliserons les haricots moqués à l'intérieur de nos ressources JAX-RS. Nous avons des interfaces de service qui sont par exemple par exemple Nous voulons se moquer de l'établissement les attentes sur ces services. par exemple @autowired dans nos ressources.
4 Réponses :
Note: Strong> Je ne suis pas un expert de printemps et je considère que cela est plutôt un travail autour d'une approche recommandée. J'espère que quelqu'un va venir avec une meilleure solution. Em> Vous ne pouvez pas obtenir un Dans ce cas, vous devez utiliser un peu de travail autour d'obtenir un ApplicationContext CODE> instance en appelant ContexteLoader # GetCurrentWebApplicationContext () Code> Parce que Jersey 2. x Runtime est par défaut initialisé en dehors d'un conteneur de servlet lors de l'utilisation de la structure de test de jersey ( jerseytest code>) pour les tests de l'unité / E2E. P> ApplicationContext code> en implémentant un ApplicationContexTaware interface dans votre package de test: P> public class JerseySpringResourceTest extends JerseyTest {
// ... Configure ...
@Before
public void mockUp() throws Exception {
// ApplicationContext is ready in your @Before methods ...
assertThat(ApplicationContextUtils.getApplicationContext(), notNullValue());
}
@Test
public void testJerseyResource() {
// ... as well as in your test methods.
assertThat(ApplicationContextUtils.getApplicationContext(), notNullValue());
}
}
Merci pour votre retour. Je vais lui donner un test dès que je peux. Juste une question. Ne devrait pas this.applicationContext = ApplicationContext; in SetApplicationContext plutôt être ApplicationContexTilS.applicationContext = ApplicationContext; Voir comme ApplicationContext est un champ statique.
On pourrait également utiliser l'annotation «@Component» sur ApplicationContexutils (en veillant à ce qu'il s'agisse d'un package composant numérisée), laissant ainsi la nécessité de déclarer explicitement le haricot.
Pour les utilisateurs de Jersey 2.x, voici ce qui a fonctionné pour moi:
public class AccountResourceTest extends JerseyTest {
private ApplicationContext context;
private BeanA beanA;
private BeanB beanB;
public AccountResourceTest() throws TestContainerException {
super();
beanA = context.getBean(BeanA.class);
beanB = context.getBean(BeanB.class);
}
@Override
protected Application configure() {
context = new AnnotationConfigApplicationContext(SpringConfiguration.class);
final ResourceConfig config = new JerseyConfiguration().property("contextConfig", context);
return config;
}
@Override
protected void configureClient(final ClientConfig config) {
config.register(JacksonJsonProvider.class);
}
...
}
avec jersey version 2.4.x, la classe jerseyconfiguration code> n'existe plus et a été remplacée par ResourceConfig code> qui ne comprend pas le contextconfig em> biens. Voici ma solution: package ch.vd.test;
import java.net.URI;
import javax.ws.rs.core.Application;
import org.glassfish.hk2.api.ServiceLocator;
import org.glassfish.jersey.server.ApplicationHandler;
import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.test.JerseyTest;
import org.glassfish.jersey.test.grizzly.GrizzlyTestContainerFactory;
import org.glassfish.jersey.test.spi.TestContainer;
import org.glassfish.jersey.test.spi.TestContainerException;
import org.glassfish.jersey.test.spi.TestContainerFactory;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
public class ExampleTest extends JerseyTest {
private ServiceLocator serviceLocator;
@Override
public void setUp() throws Exception {
super.setUp();
final ApplicationContext context = serviceLocator.getService(ApplicationContext.class, "SpringContext");
final Object bean = context.getBean("someBean");
}
@Override
protected Application configure() {
final ResourceConfig config = new ResourceConfig(RestResources.class);
config.property("contextConfigLocation", "classpath:example-context.xml");
return config;
}
@Override
protected TestContainerFactory getTestContainerFactory() throws TestContainerException {
return new GrizzlyTestContainerFactory() {
@Override
public TestContainer create(URI uri, ApplicationHandler appHandler) throws IllegalArgumentException {
serviceLocator = appHandler.getServiceLocator();
return super.create(uri, appHandler);
}
};
}
@Test
public void testStuff() throws Exception {
...
}
}
Vous pouvez injecter votre classe de test dans le contexte de Jersey si vous n'avez aucune objection pour cela.
Par exemple: après que le @Autowired Annotation fonctionnera pour vous.
Ah, nous pouvons dire à Jersey quel fichier contextuel de printemps personnalisé rechercher via le nom "contextconfiglocation" au lieu du nom "ApplicationContext.xml" par défaut.
Pouvez-vous illustrer cela sur un exemple? (Comment / quand / Où utilisez-vous le haricot moqué? Est-ce à l'intérieur d'une ressource JAX-RS?) Avez-vous besoin exactement
webapplicationContext ApplicationContext suffit?webapplicationContext ouApplicationContext irait bien. Qui nous donnerait jamais un pointeur sur le haricot qui a été injecté dans les ressources JAX-RS.