2014-09-30 12 views
5

Attualmente sto affrontando un problema con Jersey e Jackson, dove non riesco a trovare una soluzione per: Quando sto cercando di ottenere un POJO serializzato da JSON come parametro POST in un Jersey-Endpoint, restituisce un errore se lo chiamo da un uberjar. Se uso la stessa wget-call dopo aver avviato il metodo principale di eclipse, tutto funziona correttamente e ottengo le risposte previste. Ho cercato altre persone che hanno problemi durante l'utilizzo di tipi di applicazione jersey e post-parametro, come Error 415 Unsupported Media Type: POST not reaching REST if JSON, but it does if XML e JAX-RS: How to automatically serialize a collection when returning a Response object?, ma gli errori principali in cui non hanno specificato le intestazioni nella chiamata o l'uso errato @ Consumi-tag, cosa che faccio non. Secondo la mia ricerca nessuno aveva problemi simili a quelli che la chiamata ha funzionato quando il server è stato avviato da Eclipse, ma non ha funzionato quando il server è stato avviato esternamente.Tipo di supporto non supportato quando si usa Jersey e Jackson da uberjar

La classe avvio del server è la seguente:

public class ServerStarter { 
    public static final String BASE_URI = "http://localhost:8282/test/"; 

    public static void main(String[] args) throws IOException { 
     final ResourceConfig rc = new ResourceConfig().packages("starter"); 
     HttpServer server = GrizzlyHttpServerFactory.createHttpServer(URI.create(BASE_URI), rc); 
     System.out.println(String.format("Drücke Enter um Server zu beenden.", BASE_URI)); 
     System.in.read(); 
     server.stop(); 
    } 
} 

E l'Endpoint assomiglia a questo:

@Path("testme") 
public class Endpoint { 

    @POST 
    @Consumes(MediaType.APPLICATION_JSON) 
    public String testMe(Parameters ep) { 
     return ep.toString(); 
    } 
} 

ed i parametri di classe, che dovrebbe essere il POJO, assomiglia a questo:

public class Parameters { 
    private int x; 

    public int getX() { 
     return x; 
    } 

    public void setX(int x) { 
     this.x = x; 
    } 
} 

Se eseguo l'assemblaggio del pacchetto mvn clean: singolo, avviare il server e quindi chiamare wget localhost:8282/test/testme --post-data='{"x": 10 }' --header="Content-Type: application/json", restituisce 415 Unsupported Media Type.

Le dipendenze nel pom.xml sono i seguenti:

<dependency> 
     <groupId>org.glassfish.jersey.containers</groupId> 
     <artifactId>jersey-container-grizzly2-http</artifactId> 
     <version>2.13</version> 
    </dependency> 
    <dependency> 
     <groupId>org.glassfish.jersey.media</groupId> 
     <artifactId>jersey-media-json-jackson</artifactId> 
     <version>2.13</version> 
    </dependency> 

Qualcuno sa come risolvere questo problema? Sono fuori di testa, per quanto pensassi, la chiamata da Eclipse dovrebbe essere simile alla chiamata in uberjar.

+0

Forse la sintassi è cambiata rispetto a JAX-RS 1.0, ma non dovrebbe essere una matrice di stringhe nel valore @Consumi, ad es. '@Consumi ({MediaType.APPLICATION_JSON})'? – nitind

+0

Sto facendo un problema simile a Jetty: http://stackoverflow.com/questions/27971384/jetty-jersey-jackson-different-behavior-in-eclipse-success-vs-command-lin – Whimusical

+0

ho avuto lo stesso problema e sono stato in grado di risolverlo usando http://stackoverflow.com/questions/27971384/jetty-jersey-jackson-different-behavior-in-eclipse-success-vs-command-lin/40843828#40843828 – gihan

risposta

0

Questo problema doveva essere causato dai servizi(), forniti dai barattoli. Mentre eclipse li combina correttamente, i plugin uberjar li fanno sovrascrivere l'un l'altro. Una possibile soluzione è quella di utilizzare il maven-assemblaggio-plugin invece, utilizzando il seguente assemblaggio Descrittore:

<assembly> 
    <id>production</id> 
    <formats> 
     <format>dir</format> 
    </formats> 
    <includeBaseDirectory>false</includeBaseDirectory>  
    <dependencySets> 
     <dependencySet> 
      <useProjectArtifact>false</useProjectArtifact> 
      <outputDirectory>lib</outputDirectory> 
      <unpack>false</unpack> 
     </dependencySet> 
    </dependencySets> 

    <fileSets> 
     <fileSet> 
      <directory>${project.build.directory}/classes</directory> 
      <outputDirectory>classes</outputDirectory> 
     </fileSet> 
    </fileSets> 
</assembly> 

Successivamente si può iniziare l'applicazione con java -cp lib/:classes/ MainClass.

+0

FYI puoi usare il plugin 'Maven Shade' invece di' maven-assembly-plugin' perché fornisce funzionalità di riposizionamento della classe, per evitare lo stesso conflitto di nome classe nel classpath. – gihan

Problemi correlati