test des services Web REST avec arquillian

Question

Nous souhaitons tester nos API REST à l'aide d'arquillian.

Nous utilisons glassfish pour la production et l'arquillian.

Nous avons déjà des tests arquilliens pour certaines files d'attente JMS que nous exposons, et cela fonctionne bien, donc nous avons au moins quelques notions de base. Lorsque nous avons commencé à utiliser cette configuration pour les tests de repos, à la première HTTP GET, nous avons envoyé sur le reste URLS, nous avons eu l'exception: com.sun.jersey.api.container.ContainerException: No WebApplication provider is present.

Voici notre configuration ShrinkWrap:

public static WebArchive createTestArchive() { 
    return ShrinkWrap.create(WebArchive.class, "test.war") // Create jar 
      .addPackages(true, "<our packages, plus some dependencies>") //, "com.ocpsoft.pretty") 
      .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml") // b 
      .setWebXML("WEB-INF/web.xml") 
      .addAsWebInfResource("WEB-INF/faces-config.xml") 
      //.addAsWebInfResource(new StringAsset("<faces-config version=\"2.0\"/>"), "faces-config.xml") 
      .addAsResource("META-INF/test-persistence.xml", "META-INF/persistence.xml"); 

} 

Je pense que notre web.xml est pertinente:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" 
    version="3.0"> 

    <servlet> 
     <servlet-name>Faces Servlet</servlet-name> 
     <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>  
    </servlet> 
    <servlet-mapping> 
     <servlet-name>Faces Servlet</servlet-name> 
     <url-pattern>*.xhtml</url-pattern> 
    </servlet-mapping> 
    <context-param> 
     <param-name>javax.faces.DEFAULT_SUFFIX</param-name> 
     <param-value>.xhtml</param-value> 
    </context-param> 


    <!-- Pretty faces config --> 

    <filter> 
     <filter-name>Pretty Filter</filter-name> 
     <filter-class>com.ocpsoft.pretty.PrettyFilter</filter-class> 
     <async-supported>true</async-supported> 
    </filter> 

    <filter-mapping> 
     <filter-name>Pretty Filter</filter-name> 
     <url-pattern>/*</url-pattern> 
     <dispatcher>FORWARD</dispatcher> 
     <dispatcher>REQUEST</dispatcher> 
     <dispatcher>ERROR</dispatcher> 
     <dispatcher>ASYNC</dispatcher> 
    </filter-mapping> 

    <!-- disable annotation scanning by the PrettyFaces module --> 
    <context-param> 
     <param-name>com.ocpsoft.pretty.BASE_PACKAGES</param-name> 
     <param-value>none</param-value> 
    </context-param> 

</web-app> 

EDIT: en raison de la question, je l'ai changé à GlassFish-intégré 3.1.1, et mis à jour les bas question ed sur le nouveau message d'erreur. Nous utilisons glassfish 3.1.2 pour l'opération principale.

Notez également que nous obtenons d'abord un avertissement:

WARNING: Could not instantiate service class org.glassfish.osgicdi.impl.OSGiServiceExtension 
java.lang.NoClassDefFoundError: org/osgi/framework/ServiceException 
    at java.lang.ClassLoader.defineClass1(Native Method) 
    at java.lang.ClassLoader.defineClass(ClassLoader.java:791) 
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

[..]

Caused by: java.lang.ClassNotFoundException: org.osgi.framework.ServiceException 
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366) 
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

(mais il semble qu'il est sûr d'ignorer cet avertissement, voir cela et le bug relie à : http://www.java.net/forum/topic/glassfish/glassfish/could-not-instantiate-service-class-orgglassfishosgicdiimplosgiserviceextension?force=217)

l'erreur:

SEVERE: WebModule[/test]StandardWrapper.Throwable 
com.sun.jersey.api.container.ContainerException: No WebApplication provider is present 
    at com.sun.jersey.spi.container.WebApplicationFactory.createWebApplication(WebApplicationFactory.java:69) 
    at com.sun.jersey.spi.container.servlet.ServletContainer.create(ServletContainer.java:391) 
    at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.create(ServletContainer.java:306) 

Answer 1

Ok, avec beaucoup d'aide du commentaire de Gab (ne le ferait jamais sans cet indice!), J'ai corrigé le problème. Ce commentaire m'a poussé à me concentrer sur les versions de paquets, et j'ai réalisé que glassfish 3.1.2, que nous utilisons pour la production, utilise le maillot 1.11, tandis que 3.1fish glassfish-embedded, que nous utilisons maintenant pour tester (car il n'y a pas de 3.1.2 à ce jour), utilise le maillot 1.8.

donc j'ai ajouté les dépendances suivantes à la section TEST de notre pom.xml:

<!-- glassfish 3.1 ships with jersey 1.8, hence the version here. --> 
<dependency> 
    <groupId>com.sun.jersey</groupId> 
    <artifactId>jersey-server</artifactId> 
    <version>1.8</version> 
    <scope>provided</scope> 
    </dependency> 
    <dependency> 
    <groupId>com.sun.jersey.contribs</groupId> 
    <artifactId>jersey-multipart</artifactId> 
    <version>1.8</version> 
    </dependency> 
    <dependency> 
    <groupId>com.sun.jersey</groupId> 
    <artifactId>jersey-json</artifactId> 
    <version>1.8</version> 
    </dependency> 

J'ai laissé les dépendances à Jersey dans la section principale de notre pom.xml pointant vers jersey 1.11.

Et maintenant le problème est résolu.

Je souhaite que nous pourrions obtenir un meilleur message d'erreur pour de tels problèmes!