Jersey CORS działa na żądanie GET, ale nie POST

Question

Moje żądanie dla domeny Jersey nie działa dla POST, ale działa dla żądań GET. Nagłówki są mapowane do żądań Jersey, jak pokazano na poniższym zrzucie ekranu żądania GET do tego samego zasobu.

jednak robi POST do poniższej metody sprawia mi skończyć z XMLHttpRequest cannot load http://production.local/api/workstation. Origin http://workstation.local:81 is not allowed by Access-Control-Allow-Origin.

Oto zrzut ekranu z aktywności sieciowej:

Szczegóły dotyczące nieudanej żądania POST:

Oto mój zasób:

@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; 
    } 
} 

Mój filtr 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; 
    } 
} 

konfiguracja

My Jersey w moich głównych zajęć:

//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

Choć myślałem, że to był CORS problem, okazuje się, że to kwestia Jersey ...

org.glassfish.grizzly.servlet.ServletHandler na linię 256 obsługuje wyjątek ...

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); 
} 

W moim dzienniku, wszystko co patrz: service exception: bez niczego po nim. Kiedy debuguję tę linię, widzę błąd 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), który daje mi coś, z czym mogę pracować.

Answer 2

Trudno powiedzieć i trudne do debugowania, ponieważ jest to przeglądarka że generuje ten błąd podczas sprawdzania odpowiedzi (nagłówek).

Nawet przy bardzo drobiazgowej kontroli Twój kod wygląda dobrze i normalnie, poza tym, że Access-Control-Allow-Headers jest lub może być ustawiony dwukrotnie w filter(). Podczas gdy RFC 2616 (HTTP 1.1) Section 4.2 zasadniczo pozwala na to, że przy spełnieniu pewnych warunków, nie uprawiałbym tutaj hazardu. Nie masz kontroli nad tym, w jaki sposób przeglądarka N w wersji X radzi sobie z tym.

Zamiast ustawiać dwa razy ten sam nagłówek z różnymi wartościami, raczej dołącz drugi zestaw wartości do istniejącego nagłówka.