Jersey CORS che lavora per GET ma non POST

Question

La mia richiesta di jersey CORS non funziona per il POST, ma funziona per richieste GET. Le intestazioni vengono mappate alle richieste di Jersey come mostrato nello screenshot sottostante di una richiesta GET alla stessa risorsa.

Tuttavia, facendo un POST per il metodo seguito mi fa finire con XMLHttpRequest cannot load http://production.local/api/workstation. Origin http://workstation.local:81 is not allowed by Access-Control-Allow-Origin.

Ecco uno screenshot di attività di rete:

Dettagli su richiesta POST fallito:

Ecco la mia risorsa:

@Path("/workstation") 
@Consumes({MediaType.APPLICATION_JSON}) 
@Produces({MediaType.APPLICATION_JSON}) 
public class WorkstationResource { 

    @InjectParam 
    WorkstationService workstationService; 

    @POST 
    public WorkstationEntity save (WorkstationEntity workstationEntity) { 
     workstationService.save(workstationEntity); 
     return workstationEntity; 
    } 

    @GET 
    @Path("/getAllActive") 
    public Collection<WorkflowEntity> getActive() { 
     List<WorkflowEntity> workflowEntities = new ArrayList<WorkflowEntity>(); 
     for(Workflow workflow : Production.getWorkflowList()) { 
      workflowEntities.add(workflow.getEntity()); 
     } 
     return workflowEntities; 
    } 
} 

mio filtro CORS:

public class ResponseCorsFilter implements ContainerResponseFilter { 

    @Override 
    public ContainerResponse filter(ContainerRequest request, ContainerResponse response) { 

     Response.ResponseBuilder responseBuilder = Response.fromResponse(response.getResponse()); 
     responseBuilder 
       .header("Access-Control-Allow-Origin", "*") 
       .header("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT, DELETE, HEAD"); 

     String reqHead = request.getHeaderValue("Access-Control-Request-Headers"); 

     if(null != reqHead && !reqHead.equals(null)){ 
      responseBuilder.header("Access-Control-Allow-Headers", reqHead); 
     } 

     response.setResponse(responseBuilder.build()); 

     return response; 
    } 
} 

configurazione

mia maglia nella mia classe principale:

//add jersey servlet support 
ServletRegistration jerseyServletRegistration = ctx.addServlet("JerseyServlet", new SpringServlet()); 
jerseyServletRegistration.setInitParameter("com.sun.jersey.config.property.packages", "com.production.resource"); 
jerseyServletRegistration.setInitParameter("com.sun.jersey.spi.container.ContainerResponseFilters", "com.production.resource.ResponseCorsFilter"); 
jerseyServletRegistration.setInitParameter("com.sun.jersey.api.json.POJOMappingFeature", Boolean.TRUE.toString()); 
jerseyServletRegistration.setInitParameter("com.sun.jersey.config.feature.DisableWADL", Boolean.TRUE.toString()); 
jerseyServletRegistration.setLoadOnStartup(1); 
jerseyServletRegistration.addMapping("/api/*"); 

Answer 1

Mentre pensavo questo era un problema CORS, scopre che era un problema di Jersey ...

org.glassfish.grizzly.servlet.ServletHandler on line 256 gestisce un'eccezione ...

FilterChainInvoker filterChain = getFilterChain(request); 
    if (filterChain != null) { 
     filterChain.invokeFilterChain(servletRequest, servletResponse); 
    } else { 
     servletInstance.service(servletRequest, servletResponse); 
    } 
} catch (Throwable ex) { 
    LOGGER.log(Level.SEVERE, "service exception:", ex); 
    customizeErrorPage(response, "Internal Error", 500); 
} 

Nel mio registro, tutto quello che ho vedere è service exception: con niente dopo di esso. Quando eseguo il debug di questa riga, finisco per vedere l'errore javax.servlet.ServletException: org.codehaus.jackson.map.JsonMappingException: Conflicting setter definitions for property "workflowProcess": com.production.model.entity.WorkstationEntity#setWorkflowProcess(1 params) vs com.production.model.entity.WorkstationEntity#setWorkflowProcess(1 params) che mi dà qualcosa con cui posso effettivamente lavorare.

Answer 2

E 'difficile da dire e difficile da eseguire il debug dal momento che è il del browser che produce quell'errore controllando la risposta (intestazione).

Anche dopo un'ispezione molto ravvicinata, il codice sembra buono e sano, tranne che Access-Control-Allow-Headers è o può essere impostato due volte in filter(). Mentre lo RFC 2616 (HTTP 1.1) Section 4.2 fondamentalmente lo consente, date certe condizioni sono soddisfatte, non scommetterei qui. Non hai il controllo su come browser X versione N gestisce questo.

Invece di impostare due volte la stessa intestazione con valori diversi, aggiungere il secondo set di valori all'intestazione esistente.